Sitecore FXM Page filters & matcher rules

Since the launch of Sitecore 8, Sitecore have enabled a neat feature that opens up some rather interesting possibilities in terms of how you can track user behaviour and personalize non-sitecore sites.

The federated experience manager (FXM) is now fully integrated into the product. To configure you need to specify the remote site domain, take the tracking beacon and install into markup on the remote site. The beacon is simply a script tag with its url pointing back to your Sitecore application e.g.:

<script src=”//”></script>

Within the experience editor you then have the ability to create virtual placeholders for the pages. Into these placeholders you can then add: sublayouts, renderings etc. Much like you would on regular Sitecore pages.

The itemsĀ you create that define the placeholders and filters for the external sites live in ‘/sitecore/system/Marketing Control Panel/FXM’

The scenario I was testing involved simply adding some text after my H2 tag in my external site, purely for some ‘hello world’ eqsue testing.

This was all done through the Experience Editor. The css selector is highlighted below. If you dig into the presentation details for the item you can see how it’s been configured with the sample rendering and datasource ‘/sitecore/content/Home/After’

Note, I ran into issue when editing the presentation details here as you were forced to select a layout. I’ve been in touch with Sitecore around this, if you select any layout the beacon didn’t appear to return the correct markup.


Great, I can now publish the site and see my after content showing on an mvc app:


However, if I visit any of the pages in my site the same text shows. In my scenario I only wanted the text to show on the contact page, not about, faq etc.

Within the experience editor you can create ‘page filters’. These allow you to build a bit more structure into the setup. Having created one of these, you then need to nest the ‘Element placeholder’ under it and publish:


Note, I couldn’t find a way to nest the placeholders under the matcher rules within the experience editor.

The matcher rules allow a good variety of options for restricting things, and as with Sitecore you can always add your own šŸ™‚


It’s only early days for FXM but I’m sure we can expect some pretty neat things to come!

Some follow on queries and next steps in testing things out:

  • How to scale FXM
    • Which boxes receive the most load
    • Could we have a specific FXM set of delivery boxes?
  • How can we pass custom data back through the beacon?

For more info seeĀ

Sitecore Azure web-role disk space

If you need to deploy your app to Azure cloud-services you’ll notice the installation drive will yo-yo between E: and F: each time you deploy. These drives are always created with rather limited capacity – roughly 1.5GB.

Certain Sitecore operations push a lot of data to disk, things like: logging, media caches, icons, installation history and lots more. As part of your deployment I’d suggest you setup the following changes:

  • Move the data folder to another location
    • This can be patched in with the sc.variable dataFolder
  • Move the media cache
    • This can be patched in with setting Media.CacheFolder
    • Remember to also update the cleanup agents which look to delete old file based media entries. These are referenced in the CleanupAgent.
  • Move the temp folder
    • Now, this isn’t quite so simple. The reason for noting this item is installing update files creates large __UpgradeHistory folders. Also, things like icons are cached in the /temp folder. For this reason /temp needs to live as /temp under the site root. With some help from support they concluded that rather than a virtual directory, a symlink was the best approach. For details on setting one up via powershell, seeĀ As part of our startup scripts we included calling the script to shift things around.
    • The clue a folder is a symlink is the icon will change ala:

Azure WAD Diagnostics – Sitecore counters

Azure allows you to pipe loads of stats and diagnostic information to blob and table storage. Google for “WAD Azure” and you’ll find a lot more information.
Its great for logging things like the event queue, performance counters and loads more over time.

If you want to push Sitecore counters through to this you are in luck. Make sure the counters are installed on the box – for web-roles this can be done via a startup task.

Then update your ‘diagnostics.wadcfg’ config to include the counters you want – make sure you include the (*)!

This caught me out for a while, I was missing the (*).

There is a handy cmd you can run to see all the counters available:

No Sitecore logs, no Event log entries and no working site?

It’s not a nice place to be I’m sure you’ll agree!

Before we go on, I can’t guarantee one size will fix all!! This worked (well, fixed) our setup – it’s by no means the only way to solve the scary place of no working site.

In our setup we make use of the IIS URL Rewrite module. Under the hood this maps some xml within the web.config to the rules it applies. If for any reason you’ve goofed up this config, easily done with rogue config transforms or general typo’s, then you may have broken this IIS feature. The giveaway, when you double click the featureĀ in IIS you receive an error message.

The reason for posting – this took me a while to track down the first time, now it’s my go-to verification if we don’t get any Sitecore logs or Event log entries.

The issue here isn’t really related to Sitecore, the lack of Sitecore logs is simply another symptom of the problem.

Migrating a sitecore DB to PAAS SQL Azure

Moving to the cloud offers many new opportunities for how you store and handle your data. One challenge we ran into was how to migrate a large Sitecore web db into a PAAS sql azure db.

There are quite a few tools for doing this, even SQL management studio can help. The problem we faced was the source db had several filegroups setup, SQL Azure doesn’t support this.

To get around it we first created the DB through the portal, then scripted in the db structure – follow the steps in this link:Ā

The second step was then the data. We used the Azure MW tool ( . When selecting what to migrate, select ‘data only’. This can take a while to run, several hours in our case, but at least got the data upto the cloud.

Slow Sitecore publishing within Azure

We’ve recently been migrating a large Sitecore 6.6 app to Azure. It’s not using the module, instead custom powershell to spin up web-roles and PAAS Dbs. As part of the migration we’ve been benchmarking how long publishes to take when you compare things like: on-premise -> on-premise; on-premise -> azure and azure -> azure.

The stats were taken by republishing the same set of items N times then analysing the logs to look for key entries relating to the publishes starting and finishing.Ā If anyone is interested in how this is done let me know, I have a console app for extracting data from the logs and writing to summaries or CSV’s.

During the initial testing we found the performance into Azure was noticeably slower than on-prem -> on-prem. After things had been tuned up the performance was pretty similar (on-prem to on-prem was roughly 10s benchmark, azure to azure roughly 15s benchmark).

What stumped me for a while was which components to scale up?

You’ve got a few options:

  • Core db
  • Master db
  • Web db
  • Webbox

It turns out a combination of all the above plays some part however the item that had the most noticeable effect was actually the core db!

Thinking about this more it kind of makes sense. The core db plays a bigger role in the application than you might realize: all the user details are held in core; the links db is held in core & the eventqueue is used within core. All these factors contribute to ‘chatty’ behavior outside of the master and web dbs.

Running sql queries from Powershell

Have you ever needed to test out the performance of sets of sql queries?

Recently we had some performance issues on a live infrastructure which needed diagnosing. Getting code released was slightly tricky so instead we concocted some scripts to allow us to run sql queries from Powershell. The advantage of these, we could run from different boxes in the farm to try and isolate where the issues arrived.

The key settings in this setup are:

The connection strings are much like your standard application connection strings.

To then run in bulk you can use the script shown below. Note, adjust the specific queries you want to execute:

Sitecore application pool crashes

Quick gotcha that caught me out. In an MVC project, previewing one page would cause the application pool to crash. After digging around (basically removing every component from the page) it turns out one of the controller renderings had no controller action set.

Easy to fix once found but took a while to track down as the logs and system event logs didn’t have many clues.

Sitecore prefetch cache

One area of Sitecore that doesn’t seem to get much attention is the Sitecore prefetch cache. Recently we’ve been investigating how to get the content editor working faster, especially with large content dbs. Under the hood Sitecore has prefetch caches for each database it uses. If you are tuning your site be sure to pay them some attention. The config files it uses live in /app_config/prefetch.

A word of caution before you begin, updating using the following approach can increase the app startup time dramatically. I’d recommend only applying within live environments as you don’t want to add minutes to app startup during dev. Another thing to be wary of is the cache sizes, during testing it wasn’t uncommon to reach 2000MB of data in the pre-fetch cache. If you tune up the capacities make sure you pay attention to other caches eg master[items] to ensure balance throughout the caching layer.

What does the prefetch cache give you out the box?

The ability to tune:

  • the size of the prefetch cache per database
  • the number of child items per children call
  • which items to cache
  • which items to load the children of
  • which items of template type to load

Depending on the setup of your Sitecore tree a combination of the above will need tuning.

Some tips

  • Speed up the CMS (master.config) media library by caching all the media folders:
  • Get a clear view of what is in all your caches with the more detailed admin page:

What else can you do?
In most of our builds we setup a file which contains all the template ids we use in the app. An example would be:

This allows quick access to all the templates when asserting on specific content types. The following code maps this kind of file to the notation required by the prefetch cache configuration. When you run the page it will generate all the <template name=’… entries for the master.config.

Front end:

Back end:

How to build on this?
How about generating the config file during app startup?

Other info.
There is a detailed video from Sitecore at about the caches. Alternatively read the Sitecore docs