Item Name Length oddities

Was running some custom code that created lots and lots of items in the Master Database. Now nevermind the reasoning for now, but the code needs to create items in a "flat" structure (as opposed to a folder-based hierarchical one) and some of those names can turn out to be fairly long. Wasn't long before I encountered this one:

An item name can not be more than 100 characters in length at Sitecore.Data.Items.ItemUtil.AssertItemName(String name) at Sitecore.Data.DataManager.AssertItemName(String itemName) at Sitecore.Data.DataManager.AddFromMaster(String itemName, ID itemID, ID masterID, Item parent) at Sitecore.Data.Items.Item.Add(String name, MasterID masterID)

Now, ok... I can understand the fact that there HAS to be some sort of limit imposed on Item Name length. What eludes me though, is the "100 character" limit, when the database looks like this: I looked around, and this length isn't configurable anywhere I can locate (in Sitecore 5.1.x atleast).

5.1.1.12 released

Well bit late on this news, but had a few busy weeks. Changed employer, I now work at Codehouse and this is probably going to get me heavily involved in various Sitecore projects. Hopefully this also means, my activity level will go up a bit on this blog ;-) Anyhow, 5.1.1.12 provides a few minor changes:

• Fixed: Events for DataList controls (such as DataGrid, Repeater, etc.) do not work with Sitecore. Didn't encounter this one myself.
• Fixed: Performance Counters throw access denied errors on Windows 2000 Server and Windows 2003(IIS 5 /Isolated mode) when someone tries to access the back-end. Mentioned this one, after spending a couple of hours trying to figure out what was going on. Excellent that this is now fixed ;-)

Other than that, it looks to be a minor bugfix release with no other major changes.

Access is denied - Version 5.1.1.11

System.ComponentModel.Win32Exception: Access is denied exception in Sitecore 5.1.1.11 Right, it's about 3 hours past the time where I would have normally headed home. I was, however, stuck with trying to figure out why my fully working Sitecore 5.1.1.11 installation suddenly started failing with the above message after being deployed from my development environment to my operations environment. No fun, I tell ya :-P So here's the deal. Apparently 5.1.1.11 implements some (new, or for the first time - I don't know) Performance Counters. This is all good and well - I would have appreciated it a bit more though, if they in their update notes would have told me what might be needed to be done to avoid the above error. As it turns out, your ASPNET account needs access to a specific registry key for this error to go away. Specifically: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib. So (and many probably don't know this) fire up REGEDT32.exe (Start->Run), navigate to the key, select "Permissions" from the menu - and grant the ASPNET account full control to the key. Voila - problem solved. Thank you very much Bruce Johnson for your blogpost about the subject (not Sitecore related, the problem is of a more general nature). *shakes fist in the general direction of Sitecore HQ*... dudes... might wanna mention something like this, no? :-P

5.1.1.11 - Linking becomes shadowing?

Right, been absolutely entirely too busy of late to look into the recently released version 5.1.1.11 of Sitecore. Anyhow, it was released little over a week ago, and promised (among other things) the 5.1.1.8 IDTable bug fixed. And it is, so good news on that. Other curiosities, like the Proxy Item Template has also been "fixed" (this wasn't really a bug I suppose, more of a GUI hiccup) - so all in all 5.1.1.11 looks to be a promising release. Now I mentioned previously, it seems the support for upgrading existing sites (specifically version 5.1.1.4 sites) might begin to pose something of a problem. And indeed it is. Where I did manage to upgrade from 5.1.1.4 to 5.1.1.8 - it's not in any (reasonable) way possible to upgrade a 5.1.1.4 installation to 5.1.1.11. And I did try pretty much any trick I have in my book. Quite honestly - just because Sitecore deems it not worth their time to write proper upgrade scripts - doesn't mean my customers feel the same way. So no go. It's not like they keep quite about this though - it's clearly written on SDN (see picture). Doesn't mean I have to like it, or agree with it. All technicalities aside though - what IS happening to the "Linked Items" feature anyhow? Version 5.1.1.11 removes the "LinkedItems" table from the database, and introduces a new one; "Shadows". Ok. This was pretty much expected, as the LinkedItems did have architectural issues. As far as I can tell, this new table solves the issue of linking external items into the Sitecore content tree multiple times without creating multiple copies of items with the same ID. And sure enough, these Shadow items are now mapped into the DB, published to the Web database, shown on the site - all in all the technology seems stable, which wasn't really the case with Linked Items. Question though - and this is something I guess I'll look into a bit deeper. If proxied items are mapped/copied into the content tree like this... and the items are published into the Web database on publish... and the proxy item points to an item from a custom External Dataprovider (such as a Sharepoint Provider)... what happens to the live site, when a new item appears in the provider? (like someone uploading a new file into the Sharepoint content structure) Is a republish needed for the item to show? Would be a bit useless if this was the case - so am kinda hoping there's a key component here that I am overlooking. Or put differently: 1) I set up a proxy item, pointing to an external DataProvider (Sharepoint, for argument's sake) 2) On publish, the 300 items in the Sharepoint storage is copied to the Sitecore Web database 3) A user then uploads a new item to Sharepoint storage 4) ? So are we expected to set up these proxies directly in the Web database? guess that could work. However - what then, if someone wanted to link to an image in Sharepoint from an article written in the Sitecore Content Editor? ok - so we set up the proxies on both the Master and the Web databases then? Questions questions - and I've not had time to come up with a lot of answers yet. I'll look into it. If any readers has had time to look into it, comments and feedback will be very welcomed ;-)

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.