JQuery DatePicker in IE Security

Here's a quick tip.  I was recently trying to implement a JQuery UI Datepicker on a site and I couldn't get the events to fire in IE8 when selecting a date.  If you Google JQuery Datepicker IE, you'll find a ton of issues - it took me a long time to figure out my actual solution though.  I was working in a Win Server environment, and finally decided that if the JQuery example code page worked fine in my host laptop running Win7, it must be related to the server.  Sure enough, WinServer has tighter internet security than a your home Windows OS by default.  I finally found this bug report which led me to the solution.  Even though I was developing on an Intranet / Trusted site, the security settings that were being invoked by IE were from an Internet Site level.  You can follow the fix in the link above, or my fix was to simply open IE as an Admin and allow scripting on Internet Sites.  As soon as I did that, the datepicker started behaving like normal in IE.

Setting Cookies on Local Site

A quick tip for setting up cookies on a site you're running locally.  If you are going to explicitly set a domain property for your cookie, the domain should be ".[domain name].[domain extension]".  This means your local site needs to have a ".[domain extension]", or your cookie won't set in IE and Chrome (surprisingly, FF cookies seem to set OK on local sites without a domain extension).

An example.  If your local site address is "http://mylocalsite", you need to first adjust that to something like "http://mylocalsite.local".  Once this is done, the domain property on your cookie should be set to ".mylocalsite.local"

Setting up Security on Sitecore Workflows

Here's a blog post I just published about setting up security on workflows.  It can help fill in the gaps that the Sitecore Workflow Reference leaves!

Automatic Publishing in Sitecore

I wrote a post, Scheduling Futre Item Publishing in Sitecore, on scheduling Sitecore items to be published in the future.  It contains the relevant code necessary to set up automatic publishing as well.

Reusing Sitecore Sublayouts on a Single Item

Sometimes your site design may require that the same element be reused multiple times on a single page.  Great examples of this are ad slicks, or promotional callouts - it's very conceivable that you'd have multiple promotions on a single page.  To minimize development / maintenance efforts, the best way to accomplish this is to create a single sublayout and reuse it multiple times on the given page.  The challenge in reusing Sitecore Sublayouts becomes how to differentiate the data source for each of the instances of the sublayout.  One method of differentiating the data source is to let your users pick a data source dynamically through the page editor.  However, this action might be considered advanced depending on the skillset of your user.  This method is also dependent upon your code being set up properly so that the Sitecore page editor actually works.  In the case where the developer will not be able to always determine the data source for any of the given sublayouts, this dynamic data source picking is really your only option.  But in some cases, you as a developer may be able to pinpoint the source you need for each instance of your repeated sublayout.  In these cases, there is an easy way to set up your presentation layer, and add a few lines of code to help your sublayouts determine where to find the data they need.

Take the example of having a page that has two promotional callouts.  One callout will be at the top of the page, and the other callout will be at the bottom of the page.  If we design one "CalloutPromotion" sublayout, our intention is to re-use it twice on the same page.  For the sake of this post, we'll say that each of the callouts is a single line text field defined within the page template - one field is "TopCallout", the other is "BottomCallout".  When assigning your presentation layer to your page template's standard values, add your CalloutPromotion twice - most likely having to specify a different placeholder for each to fill in.  After you have added the sublayouts, if you click on each instance of your sublayout in the presentation details dialog and click the Edit button, you can now edit properties specific to each instance of that sublayout as it relates to your individual page template.

Scroll down to the bottom of these properties and you will see a Parameters section:

You can enter whatever parameters you like in these boxes - they serve like a Key-Value pairing.  For our example, we will create a Key of "FieldName", and then populate the value with either "TopCallout" or "BottomCallout" depending on which instance of your CalloutPromotion you're editing.  When we're done, the CalloutPromotion that is to be displayed on the top of the page will look like this:

Now that we have set the parameters through for our presentation details, we simply need to code our CalloutPromotion sublayout so that it reads from our FieldName parameter.  In your Sublayout cs (code-behind) file, this can be done with the following (assumes frCallout is a FieldRenderer):

//Determine if Callout is being used as top callout or bottom callout.
string rawParameters = Attributes["sc_parameters"];
NameValueCollection parameters = Sitecore.Web.WebUtil.ParseUrlParameters(rawParameters);
string fieldName = parameters["FieldName"];

//Populate FieldRenderer with appropriate data
frCallout.FieldName = fieldName;
frCallout.DataSource = Sitecore.Context.Item.Paths.FullPath;

You now have a single sublayout control that can be reused numerous times on the same page!

Sitecore WFM / Analytics Production Set Up

If you've ever developed a Sitecore site, or know anything about Sitecore, chances are you know that its documentation is lacking (and that's being kind). This can present some real challenges, the most obvious is the reaction: "I need to do X, and it seems like it's a reasonably straight-forward possibility, but I can't find any documentation on how to achieve it". Again, if you've worked with Sitecore, you've probably had that feeling at least once. The danger in that is actually two-fold though: not only can you not find what you're working on at that time, but after a while you start morphing into the opinion "I need to do Y, but I know Sitecore's documentation won't give me what I want, so I'll not even look into it". Now not only are you missing pieces of documentation that legitimately don't exist, but you're also missing documentation that is out there. The following is from documentation that really does exist, but can be easy to overlook.

If you're trying to implement Web Forms for Marketers in a production environment, it's easy to make the mistake of installing WFM on both your Content Delivery (CD) servers as well as your Content Management (CM) servers. After awhile you may realize that your CM servers aren't reporting WFM data that's being recorded on the CD (live, production site) DB. The solution to this is to actually only install WFM on the CM server. This SDN Post explains how to get this to work. Basically, you're creating a connection string on your CD server(s) that points to a web service established when WFM was installed on your CM server.

Looking at this code snippet, which again should be in your CD config and originates from the above post:

<add connectionstring="url=http://masterhost/sitecore%20modules/shell/Web%20Forms%20for%20Marketers/Staging/WfmService.asmx;user=[domain\username];password=[password];timeout=60000" name="remoteWfmService">

"masterhost" is to be substituted with the domain of your CM site.  The [domain\username] and [password] are credentials that can be used to log into the Sitecore desktop on your CM site. 

Basically, the above has the CD server pointing back to your CM's DB, so that the CM desktop can then report on data being populated through the CD environment.  Of course, the analytics DB works almost the exact opposite to the WFM database (who needs consistency right?).  If you're implementing OMS/DMS, you'll want to have your Analytics DB set up on the CD side, and then you use a connection string on the CM side (as explained on page 13 of this document) to point to your CD DB. 

Thus, a sample production Analytics conn string may look like:

<add name="analytics" connectionString="user id=[CM_DB_User];password=[CM_DB_Password];Data Source=[CM_DB_Server];Database=Sitecore_Analytics" />
<add name="reporting" connectionString="user id=[CD_DB_User];password=[CD_DB_User];Data Source=[CD_DB_Server];Database=Sitecore_Analytics" />

The above config will allow your CM environment to collect it's own statistics for testing, but the reports within the desktop will display data that is collected on the CD environment.

So, what's important to remember is that WFM should be installed on your Content Management server and your Content Delivery server should point backwards, while your Analytics needs to be on your Content Delivery server and your Content Management server uses config to point up to it and report live production data.  That, and of course, even if Sitecore documentation is often times lacking, it's always a good idea to look rather than to assume the answers aren't already out there.

Kaspersky Anti-Virus and the word Banner

This has bitten me twice now, so I'm documenting it to keep it from taking my time in the future. If you have Kaspersky Anti-Virus installed on your machine, it's very likely you're missing a lot of what the web has to offer. By default, Kasperksy seems to block any URL that contains the word "banner". So - if you were to try to go to www.banner.com, you see a blank page. If you have a website that has a (totally legitimate) "banners" directory where you store images, you may notice that you don't ever see those images show up on your website. In my opinion, the blanket treatment of the word banner as an evil object is inherently wrong and a very poor practice.

Anyway, if you run into this, here's 2 solutions to fix it. The first is of course to remove the word "banner" from your URL if you have the ability to - perhaps rename the folder to "bnr" or might I suggest "PleaseRenderThisContentSillyAntiVirusSoftware". The good part of this solution is that anyone else using Kaspersky will magically see your sites content without having to adjust their own machines. The downsize is - sometimes you can't adjust that folder named "Banners".

The other option is to open up Kaspersky, click on "Anti-Banner" and select settings. Next to the "Enable Anti-Banner" checkbox you'll see another "Settings" button - click this button. (It's ok to leave "Enable Anti-Banner" checked). On the next pop-up, on the "Additional" tab, check the box for "Do not use common banners list". Click OK to close this last pop-up, then click "Apply" on the pop-up that had the Settings button. You should now be able to see URLs that include the word "banner". The plus side of this is, you can see full content from any page now, no matter what website (go check out www.banner.com again). The downside is - you just fixed your machine, but what about random user X who's got Kaspersky running and can't see your pretty banner when they navigate to your website?