Experience Sitecore !

A guy on StackOverflow recently asked about unfunctional Parent control on Federated Experience Manager in Siecore 8.0. Here is his original question:

"I am trying to use Federated Experience Manager with an external website. The static website has a JS beacon, so now I am able to open external page with Experience Editor.

The issue happens when I try to add a placeholder to that external static page (as per guide), parent dropbox do not present, so I am not able to create a placeholder and any other operations FXM allows."

I have met that issue before, so was happy to share my experience:

original StackOverflow link

Every good Sitecore developer is familiar with the principle of versioned and shared fields - an item can contain a mixture of both types. People often wrongly consider items are versioned (for simplicity), however in fact that is not quite true. Fields may have versions, not items. When user creates a new version of item in fact only new versions of versioned fields are created, and not the shared. This concept aims to address effectiveness of data storage and it works well and transparent to users. So far, so good.

Previously, we did not have similar feature for Presentation details - it was always shared. Saying Presentation I mean layout details for devices, renderings, placeholders etc. - everything that stored in Renderings field of Layout section of Standard Template every page should inherit from.

Final presentation for an item was merged from whatever stored in Standard values (for item's template) with Layout Delta (changes individually applied to item - a delta from those in Standard Values). Standard values were stored at Rendering field of Standard Values item for a template of that specific item, thus it was the chared for all the items of that particular template; Layout Delta was physically stored in Renderings (shared) field, but of that specific item, thus applied individually to that item.

Since Sitecore 8 - there is one more point for consideration - a version. Standard Template has been extended with one new field called Final Renderings, and what is principally important at that moment - Final Renderings is a versioned field. The point of introducing that new field was that now it becomes possible to have different presentation of a page for different languages and various versions. Also, now it is possible to have a specific version of page's presentation and have it published for a while (without creating duplicates and renaming the in real-time) - now all the information is stored withing same page item.

So, before, while building the presentation Sitecore had to consider only two Renderings fields - one from item's template's Standard values, another from item itself. As both parts were shared - resulting presentation was always the same across languages and versions. Previously if you wanted a page to look different for different laguages - you were limited to personalizing renderings by specifying languages and renderings in Rules Engine. No more personalisaion required since now!

At the moment we have following configuration, in that particular order on how final presentatin is calculated:

1. Standard Values - Renderinds field - shared.
2. Standard Values - Final Renderinds field - versioned.
3. Item - Renderinds field - shared.
4. Item - Final Renderinds field - versioned.

Here's the diagram (from official site) on how final presentation is calculated with the above bunch of sources of presentation:

Thus, important advice - do not use them four at the same time, as it may behave unpredictable. Before Sitecore 8 most popular combitaion user for presentation calculation was (1)-(3), less often just (1) or (3) solely by themselves. Now you may safely use combitations of (1)-(2)-(4) or (1)-(3)-(4), as they were tested and proved with time. Of course, previous (1)-(3) from migrated projects will work as before, until you modify and save it with Experince Editor. Experince Editor works with Final Renderings field and not with shared Renderings field.

These above were just brief notes about Versioned Layouts, I left that in blog mostly for myself to have quick access to. But if you may want to understand how Versioned Layouts work in details,I would highly recommend to read a series of articles called Version Layout - Mixed Feelings (part 1, part2 and part 3).

See also Sitecore item's extension methods for identifying version layouts (link).

Hope you find this post helpful!

Annoyed of the necessity of creating packages with recent items in order to share that with your colleagues? Tired of items' versioning? Why not to version those items in source control then?

My favorite tool for achieving that is Unicorn. It does exactly what it suppose to - syncs certain Sitecore items (recursively with children) within a directory, as configured, so that you are able to check-in the folder with all serialized items, so that your colleagues can sync that changes into their database; that means new features / fixes deliver items deltas simultaneously with their code counterparts.

Here is the example of configuration, whatever sits under mentioned paths (recursively) will be serialized:

The greatest thing I love about Unicorn is simplicity - as simple as the following:

• It installs as NuGet package.
  
• Consists of 2 DLLs and a config patch file.
• Just one control page at the web root to perform sync / revert
• Simple configuration file.

From limitations I would only mention recursiveness - specifying an item in config processes it will all child items and that cannot be overridden. Of course, this is not a problem in more advanced solution - TDS, but are we here about simplicity?

Installation from NuGet Package Manager Console:

PM> Install-Package Unicorn

See also: GitHub source code

Update: now version 3 has been released with great, even revolutionary, changes and it became more friendly. So, please read:

• Unicorn 3: What's new?
• Upgrading to Unicorn 3
• Rainbow - new serialization format and library (link on Github)
  

However Sitecore 8 login screen does not show this information by default anymore. To enable displaying licensing info, you need to change one configuration file switch:

<setting name=”Login.DisableLicenseInfo” value=”false” />

Then you'll get a button that reveals your licensing information, including the License key:

Sitecore button in the left top corner of Content Editor has now become "hamburger" button, but provides all the same functionality:

For me (being a developer), the quickest option to remind the license number is just looking up directly at License.xml file:

Hope this helps!

Sitecore 8.0 Update 5 is released

Now with Mongo 3!

• Support has been added for MongoDB 3.0.
• The MongoDB driver has been upgraded to 1.10.
• Generic security enhancements have been made.

It works fine with previous SIM (Sitecore Instance Manager) release revision 150618 as soon as you place webroot archive Sitecore 8.0 rev. 150812.zip into repository folder. To retrieve your repository folder with SIM navigate Settings -> Local Repository.

One more question from a developer startin with Sitecore, who had a point of confusion between templates, standard values and branch templates (link to the original question on StackOverflow).

When creating a data template: what is the difference between just filling in the values on the template, and adding standard values? Don't both become default values whenever you create an instance of that template? If I want to make sure each item of a template has a certain value, which should I use and why? When is it appropriate to just fill out the value on the template, as opposed to adding standard values?
Branch templates: I need to create a group of items whenever a single item is created, and it sounds like branch templates are perfect for this. However, I recently read that instantiated items from a branch template stop inheriting the moment they're created.

For example, I have a branch template called Store, and create an item based off of this called Walmart. I then add features to the Store by adding new items, but Walmart doesn't get those changes? If this is problematic to my situation. I really need to keep all instantiated items in line with the branch template, and give them the new features. If my understanding is correct, how can I get around this?

I decided to answer and it seems to be a pretty good explanation:

In this blog post I decided to cover all ways of managing duplicate content in Sitecore and overview possible ways of dealing with that with emphasis on SEO. So, we have the following options to consider:

1. Duplicates
2. Clones
3. Proxies
4. Aliases
5. IIS URL Rewrite module
6. Sitecore Redirect Module
7. External Reverse Proxy

1. Duplicates are commonly known and most straightforward way of creating duplicates (clones) of the items. The easiest way to perform that operation is to right click the item you'd want to copy, select Duplicate from context menu and specify new item's name.

This ends up with an entirely independent new item (and all its ancestors) located at the same level, including all field values, presentation details, permissions etc. Beware the locks and workflows - those also would be exact match of those original items have. After that, new item lives it own life and is no way synchronized to its original prototype (except Standard Values, for sure, as both new and duplicate items share the same template).

Also it's worth of mentioning Copy To - this brings similar behavior, but allows to create duplicates keeping same name but at other paths rather than original item. Copy To is available from the same context menu.

2. Clones are sort of similar to duplicates with the difference that no new item is created when using clones. To create a clone for a highlighted item from a Sitecore tree, select Configure tab, hit Clone and specify where you'd want to locate your clone.

Notice, that clones are displayed in content tree in a slightly light font color, I personally think that may create some future issues when business users may perform some actions on item without realizing that item is a clone. Why is that important to know? Let's view the way clones function on a lower level.

When you create a clone the item and the values are not physically copied. Instead, the inheritance similar to the one between Standard Values (that is sort of prototype item for a template) and real template item, is created (clone inherits not from s.v. but from original item). When you modify a filed value of original item, that would affect same field of cloned item. However the reverse process, when you modify a field value on cloned item, overrides that individual field value and it is no more tied to original item's field. Other fields of the same item will still keep the reference to their originals. Clones use the __Source field of the Advanced section from standard template to specify the cloned item:

Unlike duplicates, clones do not clone most of standard fields (those coming from standard template) like locks / workflows and statistics (created, updated, revision). But they do clone security settings, which, again, can be overridden for a clone item.

You also can do some crazy things like creating clones of clones - inheritances chain take place in this case; each field at each level can be overridden, for sure.

To get even more understanding on how clones work in Sitecore I recommend reading Cloning What Ifs article.

3. Proxies is another mechanism of creating and managing duplicate content in Sitecore. The are frequently used in cases similar when you have an item that you may want to be a child of multiple parent items. In order to use them you must ensure a config file setting called proxiesEnabled is true; then you create proxy items at /Sitecore/System/Proxies based on /System/Proxy template. However, proxies considered to be outdated in favor of Clones. Please do not use Proxies!

4. Aliases are the different beast. They are perfectly good for promos and campaigns as the normally specify a quick URL for campaign landing page. Aliases have out-of-box limitation that they are set only per root level and not multisite-friendly (however there is a link that explains how to implement that feature on your own).

There is just one field in alias template that allows to select target item.

There are two more overheads when working with aliases - sometimes you may need to identify if an item is alias:

bool isAlias = Context.Database.Aliases.Exists(path);

Also you may need to set canonical URLs on them to improve SEO. Good way of doing that is:

public class AliasResolver : Sitecore.Pipelines.HttpRequest.AliasResolver
{
    public override void Process(HttpRequestArgs args)
    {
        base.Process(args);

        if (Context.Item != null)
        {
            args.Context.Items["CanonicalUrl"] = Context.Item.GetFullUrl(args.Context.Request.Url);
        }
    }
}

Also, do not forget to publish your aliases to content delivery databases, as they won't work until published.

5. IIS URL Rewrite module is probably most functional option, it is external to Sitecore, that means it happens before routing and before pipelines.

For the drawbacks of using IIS URL Rewrite I would mention that you'd need to have access to IIS Manager or web.config write permission on each of content delivery servers. I previously wrote a blog post IIS URL Rewrite module - few SEO tricks that can demonstrate how powerful it is.

Also I would beware you of some specific Sitecore URLs and create appropriate extensions (ex. for WebResource.axd - take from real code).

6. Sitecore Redirect Module is another good choice as it does perfect server side 301 redirect for both URLs and items. It is almost as powerful as IIS URL Rewrite, but because it is configured in Sitecore - you do not need to have CD environments access at all - just create and publish redirect rules (as you normally do with generic content) - they will take effect immediately! Module is transparent to multi-site configuration, it can do redirects from one site's URL or item to another.

One more advantage of the module - availability of source code, so functionality can be extended to any bespoke requirement, also it becomes compatible with new Sitecore versions by just rebuilding it with appropriate Sitecore.Kernel.dll and replacing updated module DLL in webroot bin folder.

7. External Reverse Proxy can be another option. It can do not only rewrites to external websites, but also rewrite some requests to alternative internal URL and pass that to IIS as "given" and further down to Sitecore. I met such scenarios several times on projects I took part. By the way, did you know that IIS can also serve as reverse proxy?

Performing rewrites and URL resolving logic outside of Sitecore can be both advantageous and disadvantageous. What traps does it bring?

Well, imagine you are new developer who start working on a new working copy of source code. When you run locally you may have different URL patterns compared to those on production environment. Business users usually deal with external production URLs and do not know internal structure, so that is how they form tasks and change requests. If you are not enough lucky to have comprehensive documentation or senior colleagues who can explain how is that configured - you may end up in multiple puzzling hours of attempting to find and match URLs from different environments.

Also, SEO much relies on sitemaps, so if you are using dynamic sitemaps - you need to implement that custom URL resolving logic that you have on reverse proxy. Also Sitemap Module from the Market would not work for you in that case.

I hope this article helped you to understand you options are with their pros and cons and to pick up a proper implementation depending on exact scenario.

Recently, I came across a question on StackOverflow where a guy asked how he could edit Standard Values for a certain template using Sitecore Rocks (here is the original question with my answer). Rocks has so many features, that it is not as trivial to keep them all in one's mind. So how do I challenge that?

The document I have found (and even printed out) could not be over exaggerated and lists most of the features grouped by the way you access them just in one two-sided A4 paper.

You may download it by this link.

One more point to mention: in case you have some decent experience with Sitecore already but never used Rocks, please do give it a try. For the first moment you will not find it as convenient and the more you got used to classical Sitecore web interface - the harder you may find it to start using Rocks. But please, don't give up with that, just give Rock a bit more time and as soon as you start getting used to it - you'll start wondering how did you manage to work without it previously and why didn't you try it earlier!

I have recently came across a question on StackOverflow I couldn't pass by. Here's original question:

Is it possible to edit content property via sitecore rocks plugin for VS ? for example Item Buckets section?

I knew that is not quite obvious so would want to share the answer:

Sure, that is possible. As I understood you right, you have an item with its fields loaded right hand side in Sitecore Rocks, you you do see custom fields but do not see fields coming from Standard Template, including Bucketable.

In that case just do right mouse click somewhere on the right hand side part, where your fields are and select Standard Fields from context menu. This will show those fields.

original question on StackOverflow

One more question I could not pass by on StackOverflow (link to original question):

I am using sitecore 7.5 and I need to add new route in application_start in order to use it in ajax call but when I run the application it seems that sitecore deals with the route as content item any help please.

Below in my answer:

    protected void Application_Start()
    {
        RouteConfig.RegisterRoutes(RouteTable.Routes);
    }

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(
             name: "test",
             url: "mvc/Forms/{action}/{id}",
             defaults: new { controller = "Forms", action = "Test", id = UrlParameter.Optional }
           );
    }

/mvc/Forms/Test/{you_may_pass_some_optional_GUID_here}

public class Initialize
{
    public void Process(PipelineArgs args)
    {
        MapRoutes();
    }

    private void MapRoutes()
    {
        RouteTable.Routes.MapRoute(
                "Forms.Test", 
                "forms/test", 
                new
                {
                    controller = "FormsController",
                    action = "Test"
                },
                new[] { "Forms.Controller.Namespace" });
     }
}

<customHandlers>
    <handler trigger="~/mvc/" handler="sitecore_mvc.ashx" />