So, what can I say? How do I go about adding a page programmatically in MURA CMS? Preferably version 6.1.
I am building a plugin that needs to create a couple of pages in the Site Manager. I want to add this routine in the 'install' method of the 'plugin/plugin.cfc' component.
I have been unable to find any pointers to this on line, which, perhaps, means this particular issue cannot be resolved. But, I live in hope.
Thanks people, in advance, for any help on this one.
When you add content to Mura, the key is that you'll need to know the parentid of where you wish the new content item(s) to live. Other than that, Mura offers an easy way perform CRUD operations on content items. You can read more about it at http://docs.getmura.com/v6/back-end/base-mura-objects-beans/loading-beans/ (based on the version you've specified). I'd also like to point out that the documentation has been greatly expanded in the latest version which can be found at http://docs.getmura.com/v7/mura-developers/mura-beans-objects/common-bean-objects/content-bean/. While the concepts and syntax still apply to older version, some newer methods for working with Mura content objects have been added since v6.1. I also highly recommend upgrading soon, as v7.1 is about to be released as well (as of Feb. 2018).
That said, the only two required fields/attributes are title and parentid. Here's the basic code for being able to do what you need:
// load the parent content item
parentBean = $.getBean('content').loadBy(title='Home');
// you may want to verify the `parentBean` actually exists before proceeding
if ( parentBean.getIsNew() ) {
Throw(message='parentBean does NOT exist!');
}
// v6.1 syntax
newBean = $.getBean('content')
.setValue('title', 'Some Title')
.setValue('parentid', parentBean.getContentID())
.save();
// v7.0+ syntax
newBean = $.getBean('content')
.set('title', 'Some Title')
.set('parentid', parentBean.get('contentid'))
.save();
// after saving, you can check for errors
if ( !StructIsEmpty(newBean.getErrors()) ) {
WriteDump(var=newBean.getErrors(), abort=true);
}
You could clearly set other attributes (as defined in the earlier links) as well, if desired.
Cheers!
Related
I'm using Sitecore 8.0 Update 5.
Each time I'm doing a "Smart" publish with languages other than English I can see that thousands of items being updated.
Job started: Publish to 'web'
Items created: 0
Items deleted: 0
Items updated: 56207
Items skipped: 13057
Job ended: Publish to 'web' (units processed: 69258)
I've enabled tracing and in the logs I can see that Sitecore updateds shared fields of those items
##Publish Item: Name=sitecore, Uri=sitecore://master/{11111111-1111-1111-1111-111111111111}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
##Publish Item: Name=templates, Uri=sitecore://master/{3C1715FE-6A13-4FCF-845F-DE308BA9741D}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
##Publish Item: Name=List Manager, Uri=sitecore://master/{D2833213-CB77-431A-9108-55E62E4E47FD}?lang=zh&ver=1, Operation=Updated, ChildAction=Allow, Explanation=Shared fields were published.
And the list goes on like that for pretty much every item in the tree.
Armed with dotPeek I was able to find a method in publishing pipeline that is responsible for determining publish action:
private void HandleSourceVersionNotFound(Item sourceItem, PublishItemContext context)
{
Assert.ArgumentNotNull((object) sourceItem, "sourceItem");
Item targetItem = context.PublishHelper.GetTargetItem(sourceItem.ID);
if (targetItem != null)
{
Item[] versions = targetItem.Versions.GetVersions(true);
if (versions.Length > 0 && versions.Any(v => v.Language != sourceItem.Language)) || Settings.Publishing.PublishEmptyItems)
context.Action = PublishAction.PublishSharedFields;
else
context.Action = PublishAction.DeleteTargetItem;
}
else if (Settings.Publishing.PublishEmptyItems)
context.Action = PublishAction.PublishSharedFields;
else
context.AbortPipeline(PublishOperation.Skipped, PublishChildAction.Skip, "No publishable source version exists (and there is no target item).");
}
Here we can see that it checks item versions and if there are versions on language other than English it sets action to PublishAction.PublishSharedFields.
Settings.Publishing.PublishEmptyItems is set to false in my case, so this should not trigger shared fields publish.
I thought that the only "system" items with non-English version in my solution were languages, but when I looked on one of the item from the logs I discovered a really interesting thing:
Sitecore default languages
These appears to be Sitecore "default" languages.
This behavior causes a performance problem with publishing when I enable Language Fallback module. (https://marketplace.sitecore.net/en/modules/language_fallback.aspx)
My questions are:
Is this an expected behavior for Sitecore to push shared fields each time when you publish?
Is this an expected behavior for Sitecore to push shared fields on system items when they have versions only on these default languages?
How can I disable those default languages and remove versions on these languages? (Powershell?)
What are the implications of removing these default languages?
Is there anything that I'm doing wrong that can cause this kind of behavior?
UPD. On a different environment where it goes over 100k items threshold and triggers full index rebuild, which is pretty expensive operation. (With or without language fallback)
Thanks in advance!
How can I disable those default languages and remove versions on these languages?
If the language is registered under /sitecore/system/Languages, Sitecore should remove all item version, for the language, if you remove the language.
If the language is not registered (or Sitecore, for some reason, fails to remove it when you remove it) under /sitecore/system/Languages, do a database cleanup (Control Panel > Database > Clean Up Databases). Sitecore will remove any version of items that are in a language that is not registered.
What are the implications of removing these default languages?
Unless you plan on using those languages in the future, no real implication.
Is this an expected behavior for Sitecore to push shared fields each time when you publish?
=> No but the code you've found isn't used for every item. That action occurs when the Source Version isn't found ea the item exists in web but not in master. That's why it's either publish shared fields (in case other versions do exist) or delete the item completely from web (because it no longer exists in master).
Is this an expected behavior for Sitecore to push shared fields on system items when they have versions only on these default languages?
=> I'm unable to answer this question as is without deeper investigation for which I do not have time at this point I'm sorry.
How can I disable those default languages and remove versions on these languages? (Powershell?)
=> These languages aren't registered, they're showing up because these items do have a version in those languages. So if you remove the versions of all system items in those languages they'll no longer show up. You can create a version in any language even a non-existing one through code.
What are the implications of removing these default languages?
=> Any content editors that are using that language might suddenly see english (or a leftover language) instead of their preferred set Sitecore Editing language. Beyond that it should not matter.
Is there anything that I'm doing wrong that can cause this kind of behavior?
=> Not that I can see from what you've presented thus far.
I am currently working with sitecore items that are in a draft workflow state. The following happens:
Create an item that will go into workflow draft state
Publish the item/publish the parent item (with sub items selected) to the web db from master db, ignore publish warning prompt
The item will appear in the web database but with no versions
This causes our controls to render the item but with standard values because there are no versions. Of course we could add a check for item.Versions.Count > 0 but my question is why this is happening?
Surely an item in draft workflow state should never appear in the web database in any way?
The workflow being used is pretty standard and has no customisation. The states and commands are:
Draft
Submit
Awaiting approval
Reject
Approve
Validation action
Approved
Auto publish
Thanks in advance.
I believe you can use the following property on each of your site nodes in the config.
<site name="website" filterItems="true" ... />
If setting this to true doesn't resolve the issue then you can add the following pipeline step, in addition to the above setting, before the Sitecore.Pipelines.FilterItem.EnsureFilteredItem step.
public class HideEmptyItem
{
public void Process(FilterItemPipelineArgs args)
{
if ((Context.Site != null && Context.Site.DisplayMode == DisplayMode.Normal) && args.Item.Paths.Path.StartsWith("/sitecore/content/"))
{
try
{
Context.Site.DisableFiltering = true;
if (args.Item.Database.GetItem(args.Item.ID, Context.Language).Versions.Count == 0)
{
args.FilteredItem = null;
}
}
finally
{
Context.Site.DisableFiltering = false;
}
}
}
}
Also ensure the following is set accordingly, the default is false;
<setting name="Publishing.PublishEmptyItems" value="false" />
I actually encountered this issue but in a different way. If you use publishing restrictions you can end up with an item that has no versions on it but can still be published. There are many ways for an item to end up with no versions, not just a new item with a single version that hasn't been pushed through a workflow. The above fix was actually provided by Sitecore support and worked for me.
If this doesn't work for you then I would suggest adding in check when items are published to see if they have any versions, although I believe that's what the fix above is supposed to do.
EDIT: Changed property from "hideEmptyItems" to "filterItems" and added further explanation.
My personal opinion is that you should be checking for version count. If you plan on ever supporting a multilingual site, it is entirely possible to have a version in one language, but not another (not approved yet in Spanish, for example). You would want your controls to handle that scenario (or execute fallback).
It is entirely valid that the current user in the current language may have no valid versions come back for them. I would expect that the business logic of the web controls should handle those scenarios.
To explicitly answer your question, this happens because the item is not null but it has no versions. A version is a dimension of an item and it happens to be "empty" if you have no version. So your code gets a valid non null item, but has no field values since there is no version and thus your controls don't fill with data.
This will only happen for new items. Example: create an item and you have v1 which is is in draft. You "publish" the item. The item goes out to the web DB but the v1 dimension of it does not, so you're left with a non null item with no versions.
As Jay said, the solution is to check for this when you query items.
First, the default workflow should set to the item's template "__Standard Values".
Second, workflow with "admin" account doesn't work. Try another account.
I am currently in the process of writing a custom DataProvider. Using the Intergrate External Data documentation.
I've managed to show the external data in the Sitecore back end. However whenever I try to view the data in the items I created, I am getting an error
Null ids are not allowed. <br> Parameter name: displayName
There seems to be precious little on the subject on how to create a custom DataProvider on the Sitecore Developer Network.
The example on their website seems to only show how to import a SINGLE item into a static database. However I am simply trying to merge some items into the hierarchy and I can't find any useful documentation.
It seems that one of your methods that should return an ID doesn't. It might be GetChildIds and/or GetParentId.
Nick Wesselman wrote a good article about it gathering all the information including an example on the Marketplace. I think that is your best start. You can read it here.
Turns out I needed to include at the very least, the Fields->Section->Template in the GetParent method. To be on the safe side I included the Fields/Sections/Templates into my implementations of
GetChildIDs
GetItemDefinition
GetParentID
It wasn't obvious that this was the case, since I had in fact implemented the GetTemplates method correctly, and I had expected that should be enough.
we are experiencing some very odd errors in our installation.
Some times out of nowhere Sitecore throws an error:
Assert: Value Cannot be null. Parameter: Item.
The closest i have come to identifying the problem is narrowing it down to either an index or the web database.
Anyway, if I log into sitecore the Item is just missing, i can fix it in 3 ways:
Rebuild the index.
Recycle app pool
iisreset
Does any of you have an idea why this might be happening? We are running Sitecore.NET 6.5.0 (rev. 120706). Any help will be deeply appreciated.
You are describing a system stability issue, so I recommend opening a ticket with Sitecore support (http://support.sitecore.net). This sort of issue is difficult to troubleshoot over Stack Overflow, since we do not have access to your logs and configuration.
When opening the ticket, I recommend using the Support Package Generator which bundles up all the information (Web.config, App_Config files, IIS settings, Sitecore log files) that Sitecore Support needs to troubleshoot the issue. It's a pretty nifty tool.
That said, from what you describe, it sounds like the issue is related to caching. The fact that restarting IIS resolves the issue indicates that the item is in the Web database, but the runtime doesn't see it. You can prove out whether this is the issue by clearing cache using the /sitecore/admin/cache.aspx screen. If your cache is not getting updated properly, you should review your configuration against the guidelines in the SDN Scaling Guide.
Based on knowing you're using the Advanced Database Crawler, your issue may be how you're converting a SkinnyItem to an Item. I've had this issue before. If you look at the SkinnyItem.cs class, there's a GetItem() method to convert it into an Item. You can see it uses the database to get the item by its ID, language, and version number. Its possible that when you publish from master to web, you are publishing a new version # of an existing item and thus the new version exists in the web DB, but the index is not updated and references the old version. So, this GetItem() call would use the previous version # and the item would be null. One way to fix this is instead of calling that GetItem() method, just use your own code to get the latest version of that item from Sitecore, e.g.
Item item = Sitecore.Context.Database.GetItem(someSkinnyItem.ItemID);
Instead of
Item item = someSkinnyItem.GetItem();
Here's an example flow:
Foo item created in master DB as version 1.
Publish Foo to web
Index will pick up version 1 in web DB and put in index.
Any querying code against index will convert the SkinnyItem to an Item via that GetItem() method and will pass 1 as the version #.
Page will load, no error in log
Back in master, create version 2 of Foo and publish.
Index may not get updated right away or even if configured wrong.
Code that looks against index will call GetItem() and still call with version 1 since that's in the index
But when you published, web no longer has version 1, it now has version 2, and thus that specific version of that item Foo is null
Error shows in log
On a similar note, here's a blog post by Alex Shyba (creator of the ADC) on how to sync HTML cache clearing with the index updates. That may help.
I've been trying to programmatically reproduce the behavior of editing a Content Type's field properties in the SharePoint site management screen and selecting the "Required" radio button with no sucess using the WSS 3.0 web service's Webs.asmx "UpdateContentType" method.
The first difficulty was the issue with the MSDN documentation that said fields should be of a FieldRef type when in fact they need to be of a Field type (reference). Adding fields and deleting fields works fine after the fix, but updating fields seems to not function at all. (It should also be noted that I followed the recommendation on the previous link to use Method="2" for updating fields but it changes nothing, and using Method values other than 1 for adding or other than 3 for deleting also function correctly).
Here's the web service call (slightly modified with strings instead of XmlNode objects for readability):
SharePointWebServices.Webs webService = new SharePointWebServices.Webs();
webService.Url = "http://mysharepointserver/site";
webService.UseDefaultCredentials = true;
webService.UpdateContentType(
#"0x01005A089D9EC8A382458FB1F6C72096D52A",
#"<ContentType />",
#"<Fields />",
#"<Fields><Method ID=""1""><Field Name=""SomeField"" ID=""{8a4803c4-6545-4a7a-804d-237eebff0ce3}"" Required=""TRUE"" Hidden=""FALSE"" ReadOnly=""FALSE"" PITarget="""" PIAttribute="""" PrimaryPIAttribute="""" Aggregation="""" Node="""" /></Method></Fields>",
#"<Fields />");
After the call, the field is still Required="FALSE".
A quick look into the stssoap.dll assembly indicates that the "Required" property is apparently ignored during the update process. Is this normal behavior? If so, what is the recommended method for programmatically changing the "Required" field from client code (not executing on the SharePoint server)?
Any help would be greatly appreciated.
I've investigated this and found the same thing. I also tried adding the attribute Cmd="Update" to the Method element without success. This example of how to use UpdateContentType was helpful too.
I don't believe you will be able to do this with the out-of-the-box SharePoint services. You've verified from looking at stssoap.dll that this doesn't appear to work correctly. Another 'client'-style option is to use RPC methods but none appear to provide functionality for content types at all.
The web services are particularly frustrating because this type of not-so-edge case regularly comes up. It is very rare that I consider using them because of the time wasting involved with their limitations.
Do you have any option of deploying custom code to the server? You could develop this functionality using the object model and wrap it in your own custom web service (there is a walkthrough here) quite easily.
Here is an example adapted from Gabe Wishnie that does what you require:
SPContentType myContentType = myWeb.ContentTypes["myContentType"];
string internalName = myContentType.Fields["fieldToUpdate"].InternalName;
myContentType.FieldLinks[internalName].Required = false;
myContentType.Update(true);
Sorry this isn't more helpful but it's a common story when using the WSS 3.0 / SharePoint 2007 web services.