CSS rule that could break your Sitecore 8.2 Experience Editor

Today when I was using the Experience Editor on my Sitecore 8.2 Update 3 site and I found that nothing of the following works:

• Assigning renderings to placeholders
• Some of the buttons in the ribbon does nothing when clicked
• Etc, etc

I have checked Chrome console logs... no javascript errors, no 500 or 404 under network tab. Checked Sitecore logs... no exceptions were thrown.

What could it be? I have started scratching my head...

Checking here, checking there, asking my colleague and starting removing whatever is on the page one by one.

At the end we figured out that there is one CSS rule:

body > iframe { display: none;}

We removed it and the Experience Editor starts working again. Why?

This rule effectively hide any iframes that are directly under the body tag, whether they are created dynamically by external javascripts or by yourself. Unfortunately Sitecore Experience Editor also has an iframe directly under body for serving the modal dialog. Therefore when this rule is present, the functionality behind the buttons (that pop up a modal dialog) actually works but the dialog is not showing.

We have only tested this on Sitecore 8.2 so not sure if it affects earlier 8.x versions. The iframe used by Sitecore looks like:

  
  <iframe allowtransparency="true" 
         frameborder="0" 
         id="jqueryModalDialogsFrame" 
         src="/sitecore/shell/Controls/JqueryModalDialogs.html">
      ...
  </iframe>

So once we know this, we can get around this by excluding this from the CSS rule:

body > iframe:not(#jqueryModalDialogsFrame) { display: none;}

Hopefully this helps!

Sitecore Habitat and Fortis

If you don't know what is Habitat yet, please have a look at its Github: https://github.com/Sitecore/Habitat.

By default, Habitat does not use any mapping tool (such as Glass Mapper, Fortis, or the emerging Synthesis) so keep it simple however it does not mean that Sitecore doesn't prefer using one of those.

I have created a fork of the original Habitat solution and made it Fortis-enabled. A Fortis.Foundation module is added to the foundation layer which is responsible for the registration of Fortis and the code-generation of the Fortis model based on Unicorn.

You can find the repo here: https://github.com/codingdennis/Habitat/tree/feature/fortis-integration.

[Updated 2017-05-03] I have also updated this Habitat to support Sitecore 8.2 Update 3, check https://github.com/codingdennis/Habitat/tree/feature/fortis-integration-sc82u3 if required.

Happy Habitating!

Sitecore SIM 1.5

There were heaps of development work undergoing since the last release 1.4 Update-3 about a year ago. Alen is in the process of merging of everything from develop to master and we should expect version 1.5 to be released soon which I was lucky enough to also contribute a small portion to it, which allows prefixing the SQL database names so multiple databases could be created for different instances.

Keep an eye on the SIM's GitHub for any updates. You can also find it in Sitecore Marketplace.

Script to flush Sitecore xDB

Many people have been talking about how to flush current visit to xDB without playing around the session timeout. Here is just a script ready for use when I need it.

<%@ Page Language="C#" AutoEventWireup="true" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Flush xDB</title>
    <script runat="server">
        protected void Page_Load(object sender, EventArgs e)
        {
            if (Sitecore.Analytics.Tracker.Current != null)
            {
                Sitecore.Analytics.Tracker.Current.EndTracking();
                Session.Abandon();

                Response.Write("xDB flushed.");
            }
        }
    </script>
</head>
<body></body>
</html>

Save as a ASPX page and put it somewhere on the site and browse to it to flush current visit into xDB.

Sitecore ShowConfig on CD servers

I have to say that this is not recommended, not recommended, not recommended... and you are doing this on your own risk.

So, what is it? We have followed all the recommendation on disabling stuff on CD servers but I am sure sometimes we want to see the famous showconfig results on CD servers so we can investigate the configurations only for CD servers. Because CD should not have Sitecore client and the admin pages, so we have removed them. Then how?

Sounds evil? Yes it is so risk is yours :)

When Sitecore does this in CM server, the showconfig.aspx checks if you are logged in. We cannot do that on CD so we just need to create the same page with code that does not do the security checking and put this, say, EvilShowConfig.aspx somewhere on CD server and remove it as soon as you have collected the configurations.

Save the following content into a text file named EvilShowConfig.aspx and put the file on CD at the location of your choice and browser to it.

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import NameSpace="Sitecore.Configuration" %>
<%@ Import NameSpace="System.Xml" %>
<html>
    <head>
        <title>Very Evil ShowConfig</title>
        <script runat="server">
            protected void Page_Load(object sender, EventArgs e)
            {
                XmlDocument configuration = Factory.GetConfiguration();
                Response.Clear();
                Response.ContentType = "text/xml";
                Response.Write(configuration.OuterXml);
                Response.End();
            }
        </script>
    </head>
    <body></body>
</html>

Sitecore.ExperienceExplorer.Business.Pipelines.HttpRequest.EnableExperienceModePipeline.Process exception

When building a Sitecore site sometimes you might suddenly see the following exception thrown as soon as you browse to the site:

[NullReferenceException: Object reference not set to an instance of an object.]
   Sitecore.ExperienceExplorer.Business.Pipelines.HttpRequest.EnableExperienceModePipeline.Process(HttpRequestArgs args) +950
   (Object , Object[] ) +73
   Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) +483
   Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) +21
   Sitecore.Nexus.Web.HttpModule.’ (Object  , EventArgs  ) +531
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +141
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +91


I discovered this while playing around the Sitecore demo sites that are built on top of Habitat Demo. This issue should only happen on multisite scenario where the Sitecore setting Preview.DefaultSite is set to a site that does not exist.

In my case, I have removed the habitat site and by default the Habitat Demo sets the Preview.DefaultSite value to habitat. Since I do not have it anymore the exception is thrown.

To fix the issue, patch the value of the setting to one of your site's name (which one is up to you).

Hope this helps!

Salesforce Web2Lead Endpoint Change and TLS 1.0

One of my client has issue with utilizing the Salesforce Web2Lead service whether the code no longer creates lead in Salesforce. After looking into it further, there are actually couple of issues.

Firstly I guess most Salesforce solution provider should have already been notified by Salesforce that to provide better service, Salesforce is planning to change the service endpoints for Web-to-Case and Web-to-Lead, as mentioned in the following knowledge base article:

https://help.salesforce.com/articleView?eid=ss-tc&id=Updating-the-Web-to-Case-and-Web-to-Lead-Endpoint-URL&language=en_US&type=1

So all the code/configuration that refers to the old endpoints such as:

• https://www.salesforce.com/servlet/servlet.WebToLead, or
• https://www.salesforce.com/servlet/servlet.WebToCase

Will need to change to:

• https://webto.salesforce.com/servlet/servlet.WebToLead, or
• https://webto.salesforce.com/servlet/servlet.WebToCase

The old endpoints will no longer work after planned time from Jun 2017.

The second issue is that Salesforce has disabled support for TLS 1.0 (https://help.salesforce.com/articleView?id=000221207&type=1) therefore depending on how the integration is done, you will need to update the code or configurations accordingly.

As we are using backend .NET code (4.5.x) I have added the code to select the highest version when possible right before we call the Salesforce service using HttpClient:

    using (var client = new HttpClient())
    {
        System.Net.ServicePointManager.SecurityProtocol = 
            System.Net.SecurityProtocolType.Tls12 | 
            System.Net.SecurityProtocolType.Tls11 | 
            System.Net.SecurityProtocolType.Tls;
        // ...
    }
 

If the integration is done by using a static form on a web page (with form action) then the user's browser needs to have TLS 1.0+ support. Refer to the link above to know how to enable TLS 1.1+ on supported browsers.