5.1.1.9 Released

Version 5.1.1.9 was released yesterday on SDN. Haven't had time to look at it yet, but went through the changelog. First thing that springs to view, is this:

Important Note: it is not possible to upgrade from version 5.1.1.4 to 5.1.1.9. Nevertheless, you can use the common Sitecore package to transfer the data from 5.1.1.4 to a clear 5.1.1.9 installation.

Now this just makes very little sense to me. Especially considering the changes the patch implements (according to the change log):

• UI - Content editor - Bug - clicking Save multiple times results in all html fields being wiped out
• UI - HTML editor - Bug - Saving link and maps in HTML editor is incorrect
• UI - Content editor - Bug - onClick attribute is thrown out from html field when saving

Apparently, all of it Sheer UI fixes. No mention of the IDTable bug that surfaced in 5.1.1.8, so guess we're gonna be patient for a while longer on that one ;-)

Now I worry though... if upgrading from 5.1.1.4 to 5.1.1.9 isn't possible, and only difference between 5.1.1.8 and 5.1.1.9 is just a series of Sheer UI changes - what about the upgrade from 5.1.1.4 to 5.1.1.8 that I performed recently?

Anyhow. Gonna test out the 5.1.1.9, and take a closer look at things.

Proxy template curiosity when proxying across databases

When linking items from external data providers, the current Sitecore strategy is, that one uses Shadow Items (also known as Proxy items, actually not sure which term is the "official"). And it works quite nicely, although I came across something I found a bit peculiar. When adding a new item based on the "system/Proxy" template, one can fill in the Target Item and Target Database fields. Target Item is a reference field, and Target Database is a plain Text field. When clicking the Target Item field, a navigational tree appears, allowing you to select the node you want the Proxy Item to point to. This defaults to the Master database (I assume the currently selected database). However... If you fill out the name of another database in the Target Database field, this doesn't change. I tried in various ways to get the shell to point to this new database and give me a navigational tree from there, but without luck. In the end, I modified my template so that Target Item was now a plain Text field. In this way, I could just paste in the ID from my foreign database and this solved my problems. I doubt this is intended though. So if I am overlooking something obvious (like why isn't the database a dropdown showing available databases anyhow? :-P) - feel free to drop a comment.

IDTable (breaking) changes in 5.1.1.8

Having been using 5.1.1.4 for a while on a project, version 5.1.1.8 was a somewhat eagerly awaited release.

We rely heavily on the use of external data sources for this project (well any project), and the 5.1.1.4 release offered some very nifty options in this regard - specifically the IDTable class. But unfortunately, not everything regarding external datasources and IDTable mapping was quite "in place" in 5.1.1.4. We experienced issues of what looked to be endless recursion, template editor hanging and similar. To start with something positive - this is all fixed in 5.1.1.8 :-) Or atleast, I've experienced no such issues - and I used to get them more or less all the time.

On the downside - IDTable is broken at this time. Apparently part of the solution to the above problems was, to introduce a new layer of ID mapping (atleast that's the only answer I can come up with) - meaning that any external object would be mapped ONCE against Sitecore in general - then a multitude of times for each Shadow Copy made of the object. To do this, a new field "ItemID" was introduced in the Master database on the IDTable table. All of this is probably good and well, except noone can really have been putting this through extensive testing ;-) Because the IDTable code hasn't changed. It still works on the 5.1.1.4 fields ID, Prefix, Key, ParentID and CustomData. And since the new column ItemID doesn't allow nulls, you're going to run into an SqlException whenever you attempt to add new mappings using IDTable.Add(). Fortunately, there's a few options one can do to fix this. An obvious choice is to remove the column entirely. As far as I can tell, there's no place in Sitecore that uses this field yet - this option was also suggested from Sitecore Support.

Alternatively you could implement a default value for the field - or simply set it to allow NULLS. As I don't fully know what functionality this field is going to be supporting in the future, I cannot predict which of these 3 solutions will be best in the long run. I expect this issue to be resolved soon enough, anyhow :-) We're using SqlServer databases by the way, I don't know if the Firebird implementation has similar issues.