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.
Related
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!
I have following question
Item level Fallback is enabled in “Sitecore.LanguageFallback.config” and fallback/default language is “en”
Languages configured in site : en, de, el, es, fr, it, ja, pt, zh
Scenario: We try to access the site with Russian(ru) or any other language which we have not configured in sitecore . The site still loads without any error, but no contents are fetched, as the language is not configured the fallback to English language doesn’t working.
Does sitecore loads the page for all the valid languages available irrespective of languages we configure under system/languages. If Yes, then should we explicitly handle in our code to restrict this behavior or fallback to English? Or is there a way we can handle this through configuration.
This is the expected behaviour unfortunately, Sitecore will load for all languages regardless of whether you have them enabled/configured in the CMS.
You need to handle this yourself in code. On possible option is to use a similar processor to this by John West and override the StripLanguage processor.
public override void Process(PreprocessRequestArgs args)
{
if (args != null
&& args.Context != null
&& !string.IsNullOrWhiteSpace(args.Context.Request.FilePath))
{
string prefix = WebUtil.ExtractLanguageName(
args.Context.Request.FilePath);
if ((!string.IsNullOrWhiteSpace(prefix))
&& !this._validLanguages.Contains(prefix.ToLower()))
{
return;
}
}
base.Process(args);
}
By simply not stripping out the language code when interpreting request URLs, Sitecore will try resolve the item it will not find a matching ru item under your home and therefore throw as 404 as you would expect it to. (You could also redirect the user to the default language at this stage instead).
The slight down side to this is that the languages are specified in config and any changes would require a deployment. Depending on your exact requirements, you could read these in from an Item specified in the Sitecore tree if you require it to be more dynamic.
Your language fallback is not setup correctly. Read the manual at the Sitecore site.
To have a Russian version falling back to English, you need to create a Russian language (it will appear in the Languages list as in your screenshot). On that item, you can fill the Fallback Language field. Set that to English. This defines the fallback language.
In order to have your items use the item fallback (which is what you want if you don't want to create versions in Russian) you must enable that on your items. The easiest way to do so is set it in the standard values of the templates. The checkbox Enable Item Fallback must be checked for the fallback mechanism to work.
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'm building a web application on app engine.
In my case, that's built on django-nonrel, but the key point is that it's using Google's datastore.
I love the fact that I don't need to deal with replication, sharding, backups and such, but one thing that is always getting in my way is the eventual consistency, which seems to get in the way of implementing a common web app pattern which I'm calling "Add & Reflect".
Let's say I have a project management app. The Project is its central model.
Now there's a web page page where I see a list of all projects, can add a project, and then I'll reflect back the list of all projects, which should include the project I just added (assuming no errors).
So the pattern goes like this:
Get and display list of existing projects
User adds new project (using a form on that page)
New project is created
As a response, get and display list of existing projects (now includes the new project)
Now the thing is, that due to eventual consistency, there is no guarantee whatsoever that I will get that new project when I get a list of all projects right after adding a new project.
Now that would be fine if this momentary inconsistency happened when another request (e.g. another user: user B) requested the list of projects one second after the project was added by the first user (user A), but it's really a problem when user A performs an operation, and does not see the results of his action, therefore does not get feedback.
I have gotten used to doing something like this to work around this problem:
def create_project(request):
response_context = {}
new_project = Project(name=request.POST['name'])
project.save()
response_context['projects'] = Project.get_serialized_projects()
# on GAE, eventual consistency means we are not guaranteed to see the
# new projects while querying for all projects, therefore we might need
# to add it manually...
if project.serialize() not in response_context['projects']:
response_context['projects'].append(project.serialize())
return render('projects.html', response_context)
The problem is that this happens in many places in my code, so I'm thinking maybe I'm missing something there, since this pattern is such a basic web app pattern.
Any suggestions for other ways to handle this?
Yes its a common issue. No theres no magic fix.
From client-side once you know the commit succeeded you can save the item locally (globals or storage) and then when querying from datastore merge your saved data. Put an expiration on it so its temporary. Its not trivial to make it work in all cases (say added an item then removed/renamed it so also update cache etc).
From server-side its common to cache recent saves in memcache and also merge with your queries.
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.