Tuesday, May 23, 2006

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).

Thursday, April 06, 2006

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.

Monday, March 06, 2006

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

Wednesday, February 15, 2006

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 ;-)