TreelistEx not registering links in LinkDatabase

Ahh nothing like being kept up till 11pm on the last day before xmas holidays... :P So here's the thing. TreelistEx is broken. You're supposed to be using this field type to "tag" content. Probably most often, you will use this to tag up categories for news articles, blog posts, meta keywords and similar stuff. And on that same note, quite obviously, you're supposed to be able to "reverse lookup" all these tags you can set. Not much point in having to loop through ALL of your 100.000 articles to find the ones that are marked "Holiday Capers" - Sitecore has a Link Database for that. If you've not worked with the Link Database before, Lars Nielsen has an excellent post about it. But here's the catch. As I said, this is broken. Nothing you store in a TreelistEx field will be registered in the LinkDatabase. "tree list", reference, droplink - sure. They all work. But not this one. A little work with Dr. Reflector eventually led me in the right direction. Now why one would need to, is an entirely different story for a different day - I believe I already had a few comments on that earlier. It comes down to TreelistEx being unknown to Sitecore itself - odd as this may sound. The field type simply doesn't exist in FieldTypes.config - and this will eventually force Sitecore to skip the field when doing it's internal RebuildItem functionality. This is, as Reflector will tell you, the method that Sitecore will recursively call when rebuilding the Link Database. Add the missing field type to /App_Config/FieldTypes.config - force a full rebuild of the Link Database - and everything now clicks into place as it should. fieldType name="TreelistEx" type="Sitecore.Data.Fields.MultilistField,Sitecore.Kernel" Thanks Sitecore. Where do I bill my lack of sleep? ;-) EDIT: 14-February-2009 This fix was released in build 090212 (also known as Service Release 1).

Showing Sitecore how to improve...

A while back, Alex De Groot invited to an open debate on areas where Sitecore could improve. This post is my response.

Readers of this blog will have noticed, I often take a somewhat critical stance to Sitecore. What may not be so obvious at a first glance however is, my beef is not so much with the product itself, but rather Sitecore as the company behind the product. The issues that come from working with the product ultimately comes down to the practices that are in place in the company that creates it. Sure, a particular bug might be annoying but it's just the smoke - not the fire itself.

So I won't be requesting features, in short. In fact, if anything, I will request "no new features" at all; but instead point out that good solid project management practices, quality assurance, usability studies and whatnot make up a very important (if not the most important) part of any ongoing software development endeveaour. Even if I couldn't spell that right... ;-) But then - it is also obviously very easy for me to just sit here and say "hey guys, manage your stuff - how hard can it be?!". I've been doing software development for many years now, and if anything I've come to realise that perfection is more a direction than a goal in itself.

I've seen improvements in the way Sitecore has been working, especially over the last year or so. Documentation for instance, has always been a weakness when working with Sitecore. So I was very pleased to find, that documentation is taking on a whole new level with The Sitecore 6 Documentation Package - while far from covering everything there is to say about working with Sitecore, it's certainly a step in the right direction. Through Sitecore Support I've had the priviledge of looking at some of the other documents still being drafted, and I'm glad to see that this new trend is taking on. Documentation would have been top of my list still, as the first thing to improve. It doesn't matter that you have a good product, if noone knows about it. With that said however, for crying out loud guys will you fix and consolidate your online information already? Per Bering from Codehouse pointed this out as well as a comment to Alex' post. Your site search is absolute bollox and there is not a single other thing to say about it :P "Did you mean.. xsl rendering xsls rendering xslext rendering exslt rendering xslt rederings xslt renderingid xslt renderingitem xslt renderendtag " ... :P

Right now, the only way I am staying "on top" (if that's what I am, I don't know) of current Sitecore technical information is, by subscribing to roughly 20 Sitecore related blogs, chatting with people who work for Sitecore, chatting with other consultants who work for Sitecore partners and then as the last resort - the ultimate Sitecore tool; Reflector. I've even seen Sitecore support personnel themselves point developers in the direction of Reflector as a source for information. And while it's a great tool, I can't really believe this is how it is meant to be. Notice btw, how I deliberately didn't include SDN5 as a common source of information for me. While I go there, it's very rare that I am able to successfully find what I'm looking for there - so the fallback option is Sitecore Support. Fortunately I find Sitecore Support very good, at least :-) Enough about documentation however.

The second thing I would ask for, is for Sitecore to start eating their own dogfood. If it's not good enough for you to run your own site on, it's certainly not good enough for the very large developer base out here who has very limited access to documentation on the product. Update notes and changelogs don't really tell a useful story as I think most who work with the product will know. I've never seen a changelog saying that the "admin" user no longer comes with Danish locale as default in a blank Sitecore 6 - and that this breaks the way some fields work in Sitecore - nor have I seen a note that it was fixed. It might exist somewhere; see "searching" above ;-) Or what about Page Editor acting up and throwing exceptions if you happen to run Sitecore in a non "en" language context? Or breaks if you don't set a layout for the Print device? I would much rather wait an additional 3 months for any Sitecore release, if it means it has been fully implemented throughout the Sitecore organisation before being released to the general public. This will not cover all usage scenarios of Sitecore as a product - but it WILL get rid of "all those little annoyances" that are so very hard to explain to our customers. "Why does my image links break, if I do it this way instead of that way?" and so on. Fortunately, level 1 support is behind me - but then.. should we accept these kinds of issues at all?

Finally, and just for good measure, I will throw in a product feature comment. The Page Editor. Brilliant, but hugely underestimated right now. Find a good way to solve the problems of configurable controls (a.la SharePoint WebParts) getting easily added to layouts - and come up with some form of layout or rendering inheritance as pointed out by another commentator. Not necessarily saying the suggested approach is the best one (although it very well might be), but it certainly is something that I would like to see addressed and solved. In summary:

1. Document. Love your developer base, please ;-) Take a look at what the competition is doing, maybe expecting a new MSDN is asking too much after all ;-)
2. Eat it yourselves. First.
3. Keep evolving the Page Editor, which I honestly believe can be one of the absolute killer features and opens up a lot of opportunities for new development areas.

That's not asking for much is it? ;-) We were invited however.

Sitecore Packager throwing System.IO.IOException: The file exists.

Just had a bit of a curiosity when attempting to create a package using the Sitecore Packager.

Essentially it would give up on me, and tell me that the file existed. Stacktrace revealed:

[IOException: The file exists.] System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +2056933 System.IO.__Error.WinIOError() +30 System.IO.Path.GetTempFileName() +2715024 Sitecore.Shell.Applications.Install.Commands.BuildPackageCommand.Execute(CommandContext context) +106

And so on. So looking at this, turns out the packager isn't really to blame here. Except maybe for the fact that it should have cought this exception and given a better error message :P

Looking into my C:\WINDOWS\TEMP folder revealed:

And further looking at MSDN reveals:

The GetTempFileName method will raise an IOException if it is used to create more than 65535 files without deleting previous temporary files.

The GetTempFileName method will raise an IOException if no unique temporary file name is available. To resolve this error, delete all unneeded temporary files.

A bit of housekeeping, and voila

All good again :-)