5 years of Sitecore blogging

Without any fanfares, ticker-tape parades or national holidays, this blog’s 5th anniversary came and went just this last week

Now I can’t be certain, but I think that might just qualify as being the earliest Sitecore blog outside Sitecore itself. Certainly should qualify me for the Old Boys League, if nothing else *g*

I do remember people like Lars F. Nielsen was blogging back when I started (his archive stretches back to October 2005), and there was also various grassroots projects going on, on communities such as Yahoo and probably more.

I figured I’d use this post to do some sort of recap over the past 5 years of Sitecore blogging, at least from my own little narrow perspective of the world.

 

5 years ago

Apparently, it all started with some comments on the IDTable.

I remember we were working a lot with integration of external data and Sitecore. This was in part due to the song of the Sitecore Evangelists – this feature was being marketed back then as one of the key advantages to Sitecore CMS over its competition – and back then, putting too large quantities of data into a Sitecore solution wasn’t really a great hit in terms of performance either. So we used data sources and data providers.

It’s actually quite funny, but the key document we used to guide us - Integrating External Data Sources is still on the SDN today and as far as I can tell, completely unchanged.

Now if you’ve never had to work with custom data providers, you probably don’t know this. But it’s a matter of extending your Sitecore database’s capabilities and feeding it from multiple sources (other than just your scSolution_Master database, keeping track of the relations between the Sitecore ID and your external key, setting up Proxy items, enabling Virtual Item publishing…  all sorts of black magic in short, and while we did eventually get things working – it was never a happy marriage.

Ironically, Sitecore eventually cracked this problem. By means of a complete re-architecture – with the release of 6.3 (I believe it was, perhaps 6.4) and Item Cloning. I’m not sure this feature was specifically targeted at solving the same types of problems we were having back then, but it certainly seems to be a side effect.

All fine and well     Except I very rarely do these types of integration today. I import the data into Sitecore instead, since it just makes a lot of things a lot easier once you’re inside under the Sitecore Feature Umbrella to take care of “boring” issues such as Versioning, Language Versions, Workflows, and so on.

So anyway…

By no means was this blog ever meant to be a commentary on the workings of Sitecore Data Integration, even if there has been a lot of posts about that over the years. It so happens that this type of work fits my personal developer profile quite nicely, so I seem to end up doing those types of jobs quite a bit.

Looking back over the early posts, this blog partly came to be out of frustration. Back then, the Sitecore product was highly unstable in many areas, and each new release seemed to remove a couple of issues only to introduce a handful of new ones. And none of this was being documented, no release logs of any note, no real change logs, barely a “Known Issues” list. At least that’s how I saw it at the time, because the information COULD have been there – and just very hard to locate. SDN, while still looking almost like I remember it, wasn’t the same either – searching for content was near impossible – and that lead myself (and I suspect others) to start putting information out where Google (well… Yahoo! in my case) could find it. The thinking was; “If I can save some other developer the grief of spending 4 unscheduled project hours on combatting this problem by putting the information out there for him or her to find, it’ll be worth it”

Up through to today

Of course, most of this has changed today.

“Aah you young kids of today, you know nothing about the hardships us old folks had to endure”

I think it was probably best summarised in Showing Sitecore how to improve, where the number one grief about it all was the inability to find absolutely anything on SDN. Documentation was starting to come out at that time, and has now evolved even more – there’s a Sitecore Cookbook on how to do just about anything with the product – now it’s actually more become a problem of finding the right document your information is located in. *g*   Still, I’d much rather have that problem, than no information being available at all.

SDN search itself is better too. While it’s still not perfect, I think it is certainly good enough so as to silence the critique.

So over the years, the nature of posts in this blog started to change as well.

For one thing, I started becoming more proficient in the use of Sitecore. It could of course mean that I’ve learned to avoid the grey areas of Sitecore functionality efficiently and therefore don’t as often fall into a pit from which there can be no hope of returning. It could also mean that the product has stabilised, and there are in fact not as many pits to fall into any more.

I think both.

The core product has become very stable, with the only issues I really run into these days being related to only the newest of features and language handling. Releases are being well documented and there’s enough cookbooks out there now to probably even shut Gordon Ramsey up

So this blog turned, in part, from it’s original function into something else. I am still motivated by sharing information to save my fellow Sitecore developers some grief, but the posts are more informational these days. Of course, the entire scene has changed as well. There’s a virtual army of corporate Sitecore bloggers now (The Sitecore Corporation does seem to assimilate Sitecore professionals quicker than the Borg collective) and on my blogroll I get on average 6-8 blog posts a day related to everyday Sitecore usage. Most of these guys are being paid to blog, and I certainly won’t pretend to be able to keep up with the sheer volume of information they output on a monthly or yearly basis. I am worried though. Sitecore never liked public critique (despite what is being said in public), and now that 90% of all Sitecore related blogging is being moved and syndicated with Sitecore.net itself – how will this affect the public debate that they themselves have always encouraged (yet not truly sought)?

I wonder what will happen, if one was to start commenting critique on their posts on servers that is under corporate control…  

And onwards

I can’t predict what the future will bring. I’ve been working – without pause – with the Sitecore product since I started blogging about it. I think it’s a safe assumption that I will continue to blog about it for as long as I have something to say, add or comment about it. My target group will continue to be the Sitecore developer base, possibly shifting the focus slightly upwards towards the Solution Architects and Project Managers.

There’ll still be no post schedule. And English will still be my second language, not my first

To the next 5 years….

Sitecore Language Settings, what is your best practice?

After reading Alistair Deneys recent blog post about the Sitecore Dictionary, the whole issue about Sitecore and langguages started stirring in the back of my mind again. I’ve come across issues with it on a number of different occasions, and especially so in the past 2-3 years or so since my work as a Sitecore Consultant has taken me to many different environments across Europe.

To start with, just so we’re clear, there’s nothing inherently wrong with the way Sitecore handles multiple languages. Atleast not as far as I am aware. Various features have been discussed in the Sitecore Community in regards to feature requests and so on, and perhaps in summary this post could be interpreted as such as well.

My beef, if you will, is with how the language features are being used. And what best practices can be put in place, when implementing multi-lingual solutions.

As Alistair points out; “English” is not just english.   This becomes even more evident, when you pair the language with a flag (as Sitecore does, when selecting languages in the Content Editor for instance).

The issue isn’t just with English though. I am pretty sure regionalization is an issue in many places around the world. I recently worked with a German Sitecore Partner, and right from the word “go”, they were dealing with multiple variations of German (de-DE, de-AT (Austria) and so on… I might remember it wrong with the code for Austria, I don’t use it much personally).

Even a small country such as Denmark could have a similar issue; da-GL, da-FO and so on.

Now, to get to my point.

In most cases that I have worked on, regionalization is being used for geographically specific information, while the bulk of the solution runs on the root language. English sites run on English, and only rarely will it become an issue whether we’re dealing with British English, American English or Australian English for that matter. Rarely – except for the fact that you can be almost positively sure your clients/editors will complain if the flag isn’t what they expect ;-)

Ideally (in my book), this would be configured in Sitecore as “en” (without any regional specifier), the flag would be neutral, and that would be that. Whenever regional information was in play, this would be further qualified with en-GB, en-US or en-AU and so on. When the site was configured to display “en-GB”, it would grab content in that language, and “fall back” to the root (stem, perhaps?) language when specific content wasn’t available.

Sadly, this is not how Sitecore works at present.

What we do these days, is install new languages via the Control Panel, and then configure Sitecore (well the site) to exclusively run on this new language. No obvious fallback mechanisms are in place (although I will discuss a few options at the bottom of this post).

Given no fallback mechanism, I would argue that one should always explicitly declare Language and Region whenever configuring new languages in Sitecore. Fortunately, Sitecore seems to agree because this is the default behaviour as well.

And

Notice how, after selecting one of the (many) predefined languages, a full ISO code is generated. en-NZ in this example.

All good. This is also what I have been recommending my clients to follow, for as long as I can recall. Specify full languages, and then we’ll see if Sitecore in the future comes up with something new and clever in terms of language fallback and so on.

But to every exception, there is a rule… or is it the other way around? ;-))

While Sitecore will, by default, install for instance the Danish language as “da-DK” (fully regionalized), the actual content we get whenever Sitecore releases localized functionality will be only “da”. (just as “en” has always been just that, without regional information although with an American flag).

Here’s a view on a Conditional in the OMS. The Danish language has been installed using default Sitecore settings, and now we end up with this.

Which was, I’m betting, not entirely what one expected. It certainly wasn’t what I expected, this much is certain :-)

And this is where I now pass the ball on to you, readers of this blog. What are your own experiences in this area? What do you recommend?

In summary, personally, I would love to see a fallback mechanism. This would allow me to run my regional sites in en-GB, and fall back to “en” where required. I’ve implemented a similar mechanism on some sites I’ve worked, although this was sort of messy and hooking into field renderers and whatnot.

Today, I would probably go about it differently. Thinking something like a Condition/Action to the effect of “when no language version exists set item language to “en””. Maybe this could be a feature at some point?

(and yes, I’ll be happy to mock up something to this effect and Share Source it, if there’s enough interest)

Your thoughts?

So what’s your view?

In the meantime

Here’s a fix to the above language issue. It will work whether you prefer your Danish (or whatever language) as “da” or “da-DK”, just reverse the statements. Alistair has his Revolver, I only have my standard tools… :P

You do this at your own risk however.

• Backup your solution. Don’t tell me I didn’t warn you ;-)
• Do a full publish
• Stop your IIS
• Open up your Sql Management Studio (Express, if that’s what you have)
• Execute the following:

USE Sitecore_master
UPDATE UnversionedFields SET [Language]='da-DK' WHERE [Language]='da'
UPDATE VersionedFields SET [Language]='da-DK' WHERE [Language]='da'

After which, you are one step closer to avoiding language confusion later on. I’ve done exactly this on a solution I am working on, and have found no ill effects from this procedure. However, do keep in mind that directly working on the Sitecore database is not (and probably never will be) supported and you’re on your own.

Here’s the result, in my solution

Disabling Lucene indexes (programatically)

Over the past 18 months or so, my work has taken me around a great deal of integration jobs. As those of you who follow this blog will know, integration of external data into Sitecore is something that has often been explored (and still is).

Recently, while faced with the task of importing, cross-referencing, IDTable mapping – about 14.000 items on a regular (scheduled) basis, I began to look for even further ways of improving integration performance.

One thing I put my attention towards, was entries like these in the log files, while the import was running:

3796 10:34:59 INFO  'ImportCategories' Executing
ManagedPoolThread #2 10:35:13 INFO  Starting update of index for the database 'master' (7 pending).
ManagedPoolThread #2 10:35:13 INFO  Update of index for the database 'master' done.
ManagedPoolThread #5 10:35:13 INFO  Starting update of index for the database 'master' (8 pending).
ManagedPoolThread #5 10:35:13 INFO  Update of index for the database 'master' done.
ManagedPoolThread #4 10:35:13 INFO  Starting update of index for the database 'master' (9 pending).
ManagedPoolThread #4 10:35:14 INFO  Update of index for the database 'master' done.
ManagedPoolThread #4 10:35:14 INFO  Starting update of index for the database 'master' (10 pending).
ManagedPoolThread #4 10:35:14 INFO  Update of index for the database 'master' done.
ManagedPoolThread #4 10:35:14 INFO  Starting update of index for the database 'master' (1 pending).
ManagedPoolThread #4 10:35:14 INFO  Update of index for the database 'master' done.
ManagedPoolThread #4 10:35:14 INFO  Starting update of index for the database 'master' (1 pending).
ManagedPoolThread #4 10:35:14 INFO  Update of index for the database 'master' done.

So basically, as the items were being imported, the indexer ran along in the background desperately trying to catch up. Well maybe not desperately… ;-)

I started looking around for an official way to disable these indexes. The idea being, disable the indexes – run the integration – enable them again and let them catch up. Has to be more effective yea?  Kind of like harddisk trashing otherwise, for those of you who still remember that phenomenon ;-)

Alex Shyba came up on top of most searches I did, describing how to disable Lucene indexes. The post is minded towards how to improve performance in the production environments however, and not to mention it’s well over a year old by now. Sitecore has been doing a lot of work on the Lucene/Sitecore search API, and odds are that things may have changed in the year that passed.

Besides, I needed a way to do it programatically.

I started looking into ways of achieving this. Basically exploring APIs, configuration settings, even considering … patching-via-reflection into the Sitecore Patching Configuration API to comment out sections of Sitecore Configuration *grin*.  Fortunately, before exploring any of these options in great detail, I had the common sense to approach the excellent Sitecore Support team to get a better (and more importantly, supported) solution. And fortunately, as it turns out, there is one. Clean, and very very simple. Thanks guys :-)

Sitecore.Configuration.Settings.Indexing.Enabled = false;

Couldn’t be simpler :-)

And the configuration equivalent exists as well, even if it is not shown in the 6.3 default web.config.

<setting name="Indexing.Enabled" value="false" />

Sitecore 6.3, ComponentArt, WebForms For Marketers, and you

Apologies for the almost complete silence in this blog, but Real Life(tm) has been taking me for quite a spin these past months.

Just a quick heads-up, in case you run into the same issue that I just had.

After installing Sitecore 6.3 (100716), WebForms For Marketers 2.1 (100629), I ran into the following issue when attempting to edit values on a DropList Field.

“Could not load file or assembly ‘ComponentArt.Web.UI, Version=2007.1.1617.2,Culture=neutral,PublicKeyToken=9bc9f846553156bb’ or one of its dependencies. HRESULT: 0x80131040”

It seems, Sitecore 6.3 comes with an upgraded version of the ComponentArt library, and version information on this new assembly reads 2010.1.2637.35. Also seems that WFFM is compiled against the previously distributed version, and fails because of it.

The fix I applied is relatively straight forward, and should work for you as well. Add a new assembly dependency mapping in your web.config as

<dependentAssembly>
  <assemblyIdentity name="ComponentArt.Web.UI" publicKeyToken="9bc9f846553156bb" />
  <bindingRedirect oldVersion="2007.1.1617.2" newVersion="2010.1.2637.35" />
</dependentAssembly>

And the problem goes away. I don’t know if the assembly versions are fully compatible, so don’t come banging on my door if this fix doesn’t make all potential problems go away ;-)   It appears to work like a charm here, in our solution.

Issue has been raised with Sitecore Support (331878).