My employer’s current practice is an annual Sitecore upgrade. I recommend this as the maximum interval; we should do more frequent upgrades when important-to-us new features, fixes, or enhancements are released. It may be prudent to even consider twice-a-year upgrades given Sitecore’s rapid release schedule.

Here’s the specific benefits of frequent upgrades:

• Fast track putting UI enhancements and bug fixes into production.
• Puts new features front and center. Even if we don’t use these features right away, they are often the basis of near-term enhancements.
• Fast track putting enhanced modules into production. Many times, newer module versions require upgrades of the base product, too.
• Avoids bifurcated environments. Aggressive upgrade policies reduce the pressure to try out and do development on newer releases than what we have in production.
• Avoid cost of delaying implementing new features. We once delayed upgrading from 6.2 to 6.4. This contributed to not-aggressive-enough learning of 6.4’s enhancements, causing our old technology to get more deeply ingrained in our practices. This made our move to 6.4′s paradigm more complex.
• Reduced upgrade complexity. We and other customers experienced difficult upgrades when we failed to upgrade frequently. Frequent upgrades means each upgrade is more of a snack than a huge meal.
• Better supportability. While Sitecore has a generous support policy—they appear to support many versions going back—it is inevitable economic reality that dusty versions will have a harder support experience. The best companies are aggressively forward-looking.
• Cleaner install and better reliability due to reduced use of hotfixes. If we do a frequent upgrade regimen, we can often defer hotfixes to when problems get fixed in future releases. With infrequent upgrades, we will be under pressure to rely more heavily on hotfixes (customizations) that 1. must later be backed out, 2. may not be as well-tested, creating unintended consequences during use, and 3. when backed out, could cause unpredictable changes.

My employer has a legitimate fear of frequent upgrades due to its experience with our ERP. Indeed, upgrades to this ERP are monstrously complicated. A Sitecore upgrade is a fraction of the complexity of an upgrade or even a patch on our ERP.

Due to the way Sitecore is architected—it generally disallows spaghetti code or direct modification of vendor code or logic—and my disinclination to customize the base product, compared to our ERP, it is rare that we will run into code incompatibilities with newer versions. Our custom code will usually “just work”.

To conclude, I recommend frequent upgrades whenever possible. It has convincing benefits, and, really, it is just a sign of an engaged product owner that wants a relevant, competitive web marketing presence.

The scenario is as follows:

• We have a search based application delivered on top of Sitecore.
• The application supports business with entering articles, collecting feeds and otherwise getting content into Sitecore.
• The ingestion happens on the Content Management (CM) servers which are load balanced.
• From time to time articles edited on one of the servers don’t make their way into our Lucene indexes on the other machine.
• Editors assigned by Load Balancer to the other server sometimes can’t see the changes made on the other server.
• We have the History Engine enabled and set up to support the multi-server scenario.

My first two thoughts are:

• Race condition and timing issues between those two servers or…
• Content issue (I’ve ruled that out pretty quickly as this would result in not indexing the article on the other server either).

So what happens? How does the Sitecore History Engine synchronizes between servers?

How history entries are committed

When you dig into the HistoryEngine class you will see that the AddEntry method instantiates the entry as follows:

HistoryEntry entry = new HistoryEntry(category, action, item,
                                      oldParentId, additionalInfo)

and then the constructor assigns the Sitecore server date/time to the entry:

this.m_created = DateTime.UtcNow;

How history entries are consumed

The IndexingProvider initiates the history consumer in the following way:

public virtual void UpdateIndex(Database database)
{
  Assert.ArgumentNotNull((object) database, "database");
  lock (this._lockSet.GetLock((object) database.Name))
  {
    DateTime local = this.GetLastUpdateDate(database);
    this.UpdateIndex(database, local);
  }
}

which determines the Last index update time for the database – the value is pulled from the Properties table. But that date is saved in the Index class in the Rebuild method in the following way:

public virtual void Rebuild(Database database)
{
  // init code ..

  DateTime utcNow = DateTime.UtcNow;

  // reindexing code ...

  database.Properties[IndexingManager.LastUpdatePropertyKey] =
    DateUtil.ToIsoDate(utcNow);
}

You can probably start seeing the problem already… The code uses local server dates to determine entries to pickup. The good thing is that it takes the time from before the index rebuild, but this will still work only if your server times are synchronized to a time-period below the time it takes to rebuild your index.

Get the chronology straight…

How does the timeline looks like then for a following scenario:

• Two servers in farm synchronizing index,
• Server_1 has proper time – rebuilds the index based on the history table,
• Server_2 is 5 seconds late – the article is being saved right after the index was triggered for rebuild,
• Index rebuild trigger is set to update the index every 30 seconds.

So what is this all about?

Basically if you use Sitecore search/indexing in a distributed scenario and you’re going to rely on the index in your daily activities and  you’re going to rely on the History Engine – you need to make sure that your time is synchronized and your time zones are set properly or you might start seeing items not being picked up by your index.

This isn’t a huge release, but does have some important new features. Let’s take a look at each of these.

Support for Sitecore 6.6 (and Sitecore 7)

Sitecore 6.6 introduced some new security features to make the Sitecore client interfaces more secure. One such feature was to protect against cross site request forgery. Sitecore client UI forms now contain a field named __CSRFTOKEN which contains a token which must be posted to the server on each request.

Revolver 2.1 contains an update to submit this field when you execute a command in the Revolver script window. If you’ve tried using Revolver <= 2.0 with Sitecore 6.6 and received an error message mentioning something about missing a “CSRF” field, then make sure you upgrade to Revolver 2.1 to get the fix.

And although it’s not released yet, Sitecore 7 is on the horizon, so I’ve been testing Revolver with the Sitecore 7 release we lucky MVPs have. If you have access to Sitecore 7 and want to install Revolver on it, grab the current 2.1 release for Sitecore 6.6.

No spell check warning for script window

A small UI tweak in Revolver 2.1 is to add the spellcheck="false" attribute to the main script window text field to stop browsers from trying to run spell check on the contents of the script window. Most of what you enter in the script window is not plain English, so this tweak removes the sea of red you would have put up with in Revolver <= 2.0 in some browsers.

“Does not contain” operator for expressions

Expressions in Revolver are like predicates in XPath. They allow defining a condition when using the find command. There are a number of operators available in expressions such as comparing equality, starts with and ends with and check whether a string contains another. One scenario that couldn’t be implemented with those operators was to check the absence of a token from input. “Show me items where __renderings doesn’t contain this ID”.

The find command also supports testing field values against a regex. Regex is great at finding patterns in text, but not very good at finding the absence of a pattern in text. Hence why I added the “doesn’t contain” (written as !?) operator to expressions.

The scenario I gave above about trying to find items without a specific ID in their __renderings field is exactly why I added this operator. I was trying to locate all items in a Sitecore solution where the __renderings field was populated but didn’t contain a particular control. With the new operator I can now use a command similar to the following to locate these items:

find -r -e (@__renderings != () and 
  @__renderings !? {885B8314-7D8C-4CBB-8000-01421EA8F406}) pwd

The above Revolver command will show me the path to all descendant items (from the current context item) that has presentation defined but does not include the control given my the ID {885B8314-7D8C-4CBB-8000-01421EA8F406}.

Preserve ID when pasting from XML

Revolver has allowed you to create items from Sitecore item XML for a while now. And now you can select to keep the IDs in the input XML string. Previously Revolver was changing the IDs to ensure there were no item ID clashes. But what if the XML being pasted came from another Sitecore instance and the ID of the items are vital; perhaps they’re referenced from another XML blob you’re about to paste.

You can now tell Revolver to keep the IDs but using the -id flag when using the touch command to create the items as follows:

touch -id -x (item-xml)

where item-xml is actual Sitecore item XML (you can get that using the gi command).

Conclusion

Like I said, not a huge release, but now supporting Sitecore 6.6.

@kevinobee @kayeenl Btw, I was thinking that it shouldn’t be too hard to make a cmd line util that converts #Sitecore packages into #NuGet

— Robin Hermanussen (@knifecore) May 6, 2013

And it didn’t take me that long to actually implement it. Follow these steps to turn any Sitecore package into a NuGet package and share it with the world.

1. Download the CreateSitecoreNuGetPackage.exe file here or build it yourself with the code from GitHub.
2. Put the files “Sitecore.Kernel.dll” and “Sitecore.Zip.dll” in the same folder.
3. Create your package in the Package Manager and export the ZIP file.
4. Run the following command from the command line:
   CreateSitecoreNuGetPackage [PATH_TO_SITECORE_PACKAGE]
5. Use the NuGet Package Explorer to open the generated  .nuspec file and improve the metadata if needed.
6. Publish the package to a repository, like nuget.org.

Now, everyone will be able to install/uninstall your package through NuGet. Remember that you need to install Sitecore Rocks and attach your project before installing the package.

Some links to pages that helped me creating this:

• http://blog.velir.com/index.php/2012/12/04/create-and-deploy-sitecore-modules-with-nuget/
• http://vsplugins.sitecore.net/Sitecore-NuGet.ashx
• http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/06/Attach-a-Sitecore-Rocks-Connection-to-a-Visual-Studio-Project.aspx

I will be very interested to hear your feedback, as I haven’t been able to test this very well. If this utility catches on, I might make a version that you can use from the package manager directly.

Happy NuGetting

You have the dropdown to show you the five latest notifications and then there is the all notifications page to view your entire history.

There has of course also been contributed a lot of cool modules since and here are some of them.

The DMS gutter module allows you to see which items have personalization and tests assigned to them.

The module was contributed by Mark van Aalst who you can find blogging here.

The Enhanced Email Action gives you some new tokens for use with a workflow email action.

It was contributed by Dan Cruickshank from Fish tank consulting.

With the Export to Json module you can export the data in the Web forms for marketers module into Json. The current Web forms only allows to export into Excel and XML so a very nice feature to be added.

The module was contributed by Mrunal Brahmbhatt.

The Limited Text Field module does as the name suggests put a limiter on how many characters your text field can include.

The module was contributed by Ruud Falier who you can find blogging here.

With the Link List Field Type module you can have a list of links using . Internal, media  and external links.

The module was contributed by Andreas Bergström who blogged about the module here.

The Security Updater allows you to define your security rules in XML. This will allow you to more easily copy your roles to another environment.

The module was contributed by Dave Leigh.

The CDN Connector allows developers to route all media requests (dynamic and static) through a proxy CDN.

The module was contributed by Katherine Lee.

The Sitecore License Expiration Module 2.0 displays a warning in the content editor when your license is about to expire and can be configured to send the administrator an email. You can set how far in advance you want to be notified.

The module was contributed by Robbert Hock

The Sitecore Log Analyzer is used to parse Sitecore log files with an interface that gives you a better overview of large data.

Some of the features include:

• Analyzing, grouping and navigating through log entries of Sitecore instance.
• Analyzing Sitecore instance performance using Health Monitor counters.
• Investigating Sitecore instance lifetime using visual timeline.
• Reporting log entries to Sitecore.

The module was contributed by Roman Chernyk.

The Sitecore Metro Desktop gives you an interface like that of Windows 8 but for your Sitecore desktop.

As you can see from the screenshot below it looks pretty cool.

The module was contributed by Alen Pelin who you can find blogging on the module here.

The Sitecore Pull up fields module allows you easily create a new base template from an existing one if you for example don’t need all the fields in it or pull new fields into one.

The module was contributed by Michael Reynolds who has a blog here where he describes in full detail how the module came about and how to use it to its full extend.

Happy coding and sharing.

Exception: Sitecore.Security.AntiCsrf.Exceptions.PotentialCsrfException
Message: CSRF form field is missing.
Source: Sitecore.Security.AntiCsrf
at Sitecore.Security.AntiCsrf.SitecoreAntiCsrfModule.RaiseError(Exception ex, HttpContext context)
at Sitecore.Security.AntiCsrf.SitecoreAntiCsrfModule.PreRequestHandlerExecute(Object sender, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

The issue seemes to be related to an implementation of AntiCSRF, a Microsoft Public License library that prevents Cross Site Request Forgery.

HOW TO FIX IT:

The fix is easy. Clear your cookies, clear the browser cache, close the browser and try again.

UPDATE:

The clever guys at Sitecore Support have come up with this (untested) quick fix that you can try:

Please add these lines to the Sitecore.AntiCsrf.config file (website/app_config/include/Sitecore.AntiCsrf.config):

<ignore wildcard="/sitecore/shell/*Applications/Security/User*Manager*?*Cart_Users_Callback=yes"/>
<ignore wildcard="/sitecore/shell/*Applications/Security/Role*Manager*?*Cart_Roles_Callback=yes"/>
<ignore wildcard="/sitecore/shell/*Applications/Security/Domain*Manager*?*Cart_Domains_Callback=yes"/>
<ignore wildcard="/sitecore/shell/~/xaml/Sitecore.Shell.Applications.Security.SelectAccount*Cart_*_Roles_Callback=yes"/>
<ignore wildcard="/sitecore/shell/~/xaml/Sitecore.Shell.Applications.Security.SelectAccount*Cart_*_Users_Callback=yes"/>

UPDATE 2:

The tough guy could choose to disable AntiCSRF completely. Add the following line in the /App_Config/Include/Sitecore.AntiCSRF.config file:

<?xml version="1.0"?>
<configuration>
  <sitecore>
    <AntiCsrf>
      <rules>
        <rule name="shell">
          <!-- Ingore AntiCSRF completely -->
          <ignore wildcard="/sitecore/*"/>
        </rule>
      </rules>
    </AntiCsrf>
  </sitecore>
</configuration>

It is always fun when a client request comes 30 minutes before the end of your work day. Recently I was asked to release a new market, and after believing I could finish on time, I selected the option to include child pages, ensured the correct language was selected, hit the publish button and… I could not believe my eyes. The content looked like it had been perforated with a heavy machine gun. A few of the pages were published but all the rest were missing.

Join me on my journey from the Dark Ages of manual processing to the scripting enlightenment with Powershell!

What went wrong this time?

Good Morning workflows! Most of the pages were still in the ‘draft’ state, which means they could not be simply published before they were all approved. And there were a decent number of pages to approve. Having visions of hot dinner slipping slowly away, I started to explore my options. An approval of a page would take me half a minute. So for forty pages it would be twenty minutes of constant work. Constant, dull work for each market to be processed.

There has to be a better way

Luckily I was still sitting next to Adam who, whenever asked questions about how to perform a batch operation on Sitecore, has always the same answer: Powershell. But what is important is that this answer is always right!

I asked the client if I could approve all the pages and started writing the appropriate script. If I had decided to manually click on every page to approve it, I would have to wait for the response helplessly. Coding was a much funnier alternative. I found a nice and ready to use snippet by my colleague Kris who did similar things but in different conditions, though the idea was still the same. So by the time I was permitted to approve all pages, the result was only one script call away. And the next day, when I had to publish another market, it was still a matter of a single script. Oh, how I love batch processing!

Enough of cool stories

Let’s get to the meat. Here you can find the script I used with explanations.

As mentioned I based my solution on a script already created (thanks Kris!).

The first important part was a function to filter items. It would have been very easy to fall into a trap of putting the whole script into a huge single-monster-liner but I believed one had better not to go that way.

This routine is expected to filter out some items which do not meet the criteria but in my case I needed to actually add more items. More specifically I needed to include all language variations of the item.

function FilterItemsToProcess($item)
{
    Get-Item $item.ProviderPath -Language *
}

I was pretty sure this would not be very straightforward. The Sitecore API has an interesting approach when it comes to getting the item in different language versions. It turned out that with Powershell it was easier than it had ever been before with code. Basically all I had to do was to call cmdlet Get-Item, specify the original path and ask to include all versions. The asterisk there is an actual wildcard not just ALL_LANGUAGES_INDICATOR, which means you can safely use “en-*” for each variation of the English language.

Another nice piece of functionality (worth extracting into a separate function) was the routine for changing the workflow state. Thanks to Powershell, it does not require a beginning edit and committing your changes. All I had to do was to assign a correct ID to an appropriate field. I actually did even more and ensured that all the items were not only in a correct workflow state but also in a correct workflow!

function ProcessItem($item)
{
    $item.__Workflow = "{My-super-sweet-workflow-id}";
    $item."__Workflow state" = "{My-even-sweeter-approved-state-id}";
}

When I had all my helpers ready I could look if the rest of the script required to change. Now here comes another advantage of the approach with using functions. It turned out that all the varying functionality was abstracted into functions and all I had to do was to adjust them to my needs.

The following line gets the items which should be processed in the correct language version. The context is set by running the script in an appropriate market so that we are approving one branch only  (not the whole tree). It is quite important to remember about narrowing script execution.

$itemsToProcess = get-childitem . -recurse | foreach {FilterItemsToProcess($_)}

And finally the execution itself. Again not much to do here thanks to abstraction. Huge kudos for showing a nicely formatted state before and after the change. Somewhere in the middle, there is a small, inconspicuous but extremely powerful call to our process method for each filtered item.

if($itemsToProcess -ne $null)
{
    $itemsToProcess | format-table -auto -property `
        @{Expression={$_."__Updated by"};Label="Updated"},`
        @{Expression={$_.__Workflow};Label="Workflow"},`
        @{Expression={$_."__Workflow state"};Label="State"}, `
        Language, ItemPath

    $itemsToProcess | foreach {ProcessItem($_)}

    $itemsToProcess | format-table -auto -property `
        @{Expression={$_."__Updated by"};Label="Updated"},`
        @{Expression={$_.__Workflow};Label="Workflow"},`
        @{Expression={$_."__Workflow state"};Label="State"}, `
        Language, ItemPath
}
else
{
    Write-Host "No items to process"
}

This abstraction has also a great advantage when testing the script. All you need to do is to cut out this little bit of code and rather than show two similar lists of items, this script will do nothing unexpected. Brilliant!

Was it worth it?

With Powershell, I have been able to delegate all the dull and boring jobs to the mindless script. Now, not only have I saved myself from zombie-like tasks but I have also saved tons of time I can now spend playing table foot.. erm coding. It took me about half an hour to develop the script and I have used it three times so far. This means I have already saved half an hour. But now every following call will add to this number.

I have also shown you how Powershell can ease some of the tasks in Sitecore which are not so obvious to use with the API. Not to mention the fact that I did not have to release anything to do that. All you need is the console and then you are free to script!

This template can actually be used to do any kind of processing items in Sitecore (and with small changes in any other environment). It’s simple in terms of construction and usage, so feel free to take it and modify at your will. Feel the power of Powershell!

Remember: with great power comes great responsibility. Use the Sitecore Powershell with care. Always perform a database backup and test your scripts in a non-production environment. Cognifide will take no responsibility for any damage caused by the improper use of scripts.

Release 1.0.0.0:

• Added “Platform Mode”, that can be used if generated code needs to be in separate files (e.g. when there are multiple DLL’s where generated code is needed)
• NuGet support added

Platform Mode

This is a feature that has been requested by several people. If you have multiple projects or logic that is used in several DLL’s, then you need a way to divide the generated classes up into multiple files.

To make this possible, you should first check the “Platform Mode” checkbox on the settings item (/sitecore/system/Modules/CompiledDomainModel/Settings):

Note that the wrapper classes need to be resolved globally when using the platform mode. To make that possible, there is a dependency on the module itself. So you can’t use the “Remove dependencies” function when you want to use the platform mode.

If you generate the code now, you’ll see that a comment is generated:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// PLATFORM MODE IS ON - please check the CompiledDomainModel settings if this was unintentional
//
// Please use the following url and change it to your needs:
// http://sitecoredemo/sitecore/shell/Applications/CompiledDomainModel/CodeGenerator.aspx?platformsets=<PIPE_SEPARATED_SET_NAMES>
//
// Use one or more of the following names to generate for the part of the platform you need (exclude the brackets):
// [Core] (should be used in a project that all other projects have a dependency with)
// [PlatformTemplatesSet] (domain objects)
// [SomeProjectTemplatesSet] (domain objects)
// [PlatformFixedPaths] (fixed paths)
// [SomeProjectFixedPathsSet] (fixed paths)
//
// As a starting point, this is what the URL would look like if you would want to generate everything
// http://sitecoredemo/sitecore/shell/Applications/CompiledDomainModel/CodeGenerator.aspx?platformsets=Core|PlatformTemplatesSet|SomeProjectTemplatesSet|PlatformFixedPaths|SomeProjectFixedPathsSet

As is explained, you must now make url’s to generate code that is specific to your project. In this case, you could generate code for the platform project and the specific “SomeProject” project. Using the following url’s, you can do that:

1. http://sitecoredemo/sitecore/shell/Applications/CompiledDomainModel/CodeGenerator.aspx?platformsets=Core|PlatformTemplatesSet|PlatformFixedPaths
2. http://sitecoredemo/sitecore/shell/Applications/CompiledDomainModel/CodeGenerator.aspx?platformsets=SomeProjectTemplatesSet|SomeProjectFixedPathsSet

These url’s will only generate the code for the DomainObjectSets and FixedPathSets (check the documentation for an explanation about these sets) that are referenced in the url.

NuGet support

You can now install CompiledDomainModel through NuGet. I based the package on this excellent article.

Steps:

1. You need to have Sitecore Rocks installed in Visual Studio
2. You need to connect your project to your Sitecore website
3. Open the Package Manager Console and run Install-Package CompiledDomainModel

Of course you are not required to install CDM this way. You can still use the regular package on the Releases page.

Happy CDM-coding!

For all you, developers, techies, web analysts, designers, quality engineers and project managers in the internet industry. The following page is a real must read! As you can see on this picture, the marketing organizations are on loose ground. It’s time to help them, but before we can do that, we probably need to dive a bit into their world…

http://chiefmartec.com/2013/03/agile-marketing-for-a-world-of-constant-change/

Managing Multiple Sites in General

Sitecore supports multiple logical sites by having separate root paths in the content tree:

In addition to this, XML configuration in the <sites> section (preferably via the SiteDefinition.config patch) defines what sites map various host names to root content paths. Sites also define a context language, database, etc.

How Sitecore Resolves a Site

Sitecore resolves the correct site via a pipeline process in the httpRequestBegin pipeline. The SiteResolver sets the context site based on the following criteria:

• Hostname
• Virtual path
• Port number

Sitecore processes the XML in sequence to find the first site that matches the above criteria. Since each site has a hostName attribute defined, Sitecore first matches against this. Next comes the virtualFolder which by default is simply “/” but may be changed.

How to Configure a Sitecore Site with a Virtual Folder

To configure a site as a virtual folder, define the virtualFolder path AND physicalFolder path to match the expected path.

If you do no define the physicalFolder in addition to the virtualFolder Sitecore may either not resolve the site correctly or may throw a YSOD saying a path is null:

Note: if you have configured the Link Provider to use the Display Name for URLs, these virtual and physical paths must actually match the display name, not the item name.

Additionally, you must define virtual folder sites above any non-virtual folder sites that share the same hostName. This is because Sitecore resolves the sites in sequence based on the configuration so you need more specific combinations of criteria first (e.g. host and path).

Sitecore Managed Sites as Virtual Folders is a post from Fire Breaks Ice, published by Mark Ursino, Sitecore MVP