PCheX this out...

If you're already maintaining a decent Sitecore Blogroll you know this. But in case this blog has escaped your attention, I think you need to take a look at this: Check your packages with PCheX As someone who often designs update packages and mail them off to clients, I am sure this tool will quickly make it to the top of my list of favourite tools and save me a lot of hassle. The description says it all lol... ;-) "In a way, you can imagine PCheX to be like a little friendly elf who comes around and kindly whacks you around the head with a big rubber hammer if you design an unhealthy package. " And we certainly don't want to get whacked by big rubber hammers do we? :P

Two for the bookmarks

Some of this information has been available for a while, it just hasn't been easy to locate. It actually still isn't ;-) But at least these two links look like they might be more or less permanent. 1) Sitecore 6 Release Notes Gives you all information about known current issues. A big help, which should help you avoid getting too stuck trying to solve a particular issue - only to find that it is already known, and in some cases even comes with a workaround. 2) Sitecore 6 Change Log Detailed information about the individual updates, so you can now be confident when choosing whether to go with the Recommended Release or the Latest Release.

DomainObjects Update 2 released

Just posted an update of DomainObjects onto the Sitecore Shared Source space.

Apart from a few tuneups, this update is primarily about built-in support for referrers.

Say you have a product hierarchy like this:

We are then often tasked with listing or in other ways extracting products based on a selected category (or media, as could be the case in this example). In the simplest of forms, the output could look like this (although I hope no live site would ever look like this :P):

With DomainObjects this is now a very straight forward piece of code. All based on an article by Lars Floe Nielsen which I often refer back to.

Sitecore 6 package, sources, API documentation have all been posted to the Trac space.

Wow @ Sitecore 6 Item Creation Speed

I remember this was being brought up right around the time of release of Sitecore 6, that item creation speed had been increased since Sitecore 5. To be honest, I haven't really noticed. Until today that is. For a client, I am currently in the process of converting/migrating an entire website based on the Polopoly CMS system to Sitecore 6. Essentially a process of getting all the source content, parsing and understanding it, mapping it to relevant Sitecore templates (around 20) in all and writing this entire new structure into Sitecore. Take a look at the numbers I am getting. Migration process starting.... Deleting existing content....done! Building Table of Contents tree....done! Building Departments tree....done! Performing in-memory mapping...done! Duration: -00:03:58.2400000 7271 items created in total - 471 products - 59 images - 1678 documents - 3728 other articles - 1335 departments 7.271 items created (using BulkUpdateContext()) in just under 4 minutes. One word. Fast! :-)

Session State and the Integrated Pipeline in Sitecore

Currently (release 090120) Sitecore has a known issue when it comes to running in the new IIS7 Integrated Mode pipeline. The issue states: "The ASP.NET session state may be unavailable to web page’s code depending on the URL used to access a Web site’s homepage. This occurs with a short URL, such as http://mysite.com/, while longer URLs, such as http://mysite.com/default.aspx do not encounter the issue. "

It actually goes a bit further than that. I did some testing on a completely fresh 090120, Created "Test1" under "Home". And then "Test2" under "Test1". Like so.

• Sitecore
• Content
• Home
• Test1
• Test2

I set up my website to run 32 bit Integrated Pipeline, with a binding to host header "integrated".

I then added some test code to the Sample Layout.aspx, like so.

<% string lala; if ( HttpContext.Current.Session != null ) lala = "Session has value"; else lala = "Session is NULL"; Response.Write( lala ); %>

(Extremely bad coding practice however, don't do this in any real scenario :P Breaks preview and page editor and whatnot... was just to test)

Now, after navigating to the following URLs, I was getting these results.

http://integrated/ "Session is NULL"
http://integrated/default.aspx "Session has value"
http://integrated/test1 "Session is NULL"
http://integrated/test1.aspx "Session has value"

Ok so. A known issue and according to Sitecore Support, no immediate ETA for a fix. Why would you want this however? Well let's consider SEO. Often have I been met with the requirement that SEO friendly URLs are required. And for some reason, SEO specialists seem to think that http://integrated/products/classical-piano is a better URL than http://integrated/products/classical-piano.aspx. Whether they are right or not, I leave with someone who knows more about these things than I do. Bottom line is, I needed these types of URLs for a client of mine. And I was curious :P

According to Microsoft, the list of Breaking Changes for Integrated Pipeline isn't all that long, and none of those stood out to me as something that should be affecting Sitecore. After much digging around, searching the web and reading lots and lots of articles about this new Integrated Pipeline - many of which was full of praise but none really helping me in any way - I finally came across something from someone who knew "what's what". ASP.NET Session State for Native HTTP Requests in IIS 7.0 Upon reading, I felt 99% sure this was the fix I was looking for. A bit of coding, and a bit of optimisation (read through the comments) and I was ready to give it a shot. And it worked :-) A bit of coding (or rather, code pasting), a compile, a simple web.config change and voila. Now all of the above URLs seem perfectly happy to give me the Session State I've come to rely on. If you can't be bothered to set up a project for this yourself, I'm attaching the project and the DLL. Just plop the DLL into your /bin folder and add the following to your web.config at the end of the system.webserver/modules node.

<add name="CorePointIntegratedSessionFix" type="CorePoint.IntegratedSessionFix.Module, CorePoint.IntegratedSessionFix" remove name="Session" add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="" /> (excuse the markup, I am REALLY not happy with my blog texteditor.. but that's a story for another day) And the project file here: CorePoint.IntegratedSessionFix.rar Enjoy :-)

Caveat: Be aware however, I don't have the resources to execute a complete regression test of this fix. It seems fine, but there could be repercussions that I am not seeing at this stage. I have an open support ticket with Sitecore Support on this issue; and I will post these findings there for their review. Will update if needed.

Update 23-February-2009 While eating my own dogfood on this fix, I was experiencing some fairly odd behaviour when using the Sitecore Content Editor. It would pause ever so often for a few seconds, and sometimes operations would get aborted and throw up a dialog box like "Session Terminated Unexpectedly". Quite naturally I was worried this had to do with this fix. Turns out, it hasn't. It IS related to the integrated pipeline however - I had overlooked another issue from the Known Issues List which states: A known issue in Microsoft IIS may cause Sitecore to restart during index rebuilding or package installation when Sitecore indexes are stored below the Sitecore web site root folder.Moving the Sitecore indexes outside website root will resolve the issue.To configure this, add the following to the "settings" section of web.config file: setting name="IndexFolder" value="C:\test\indexes" Note: You must ensure that the application pool identity has full control over the chosen index folder. For more information about appropriate folder permissions, please refer to the Sitecore CMS 6 Installation Guide. So if you do run integrated, don't get caught by this one. Like I just did :-)

Update: 6-March-2009 This has now passed Sitecore QA and is an official workaround according to SDN.

Expert Systems

I know many of you follow this blog, but today's entry certainly did bring back memories.

Those of us who worked when the IT industry (or maybe just the Internet industry, I am not THAT old :P) fired off probably all have some terrifying tale to tell that resembles todays entry in TheDailyWTF. Be it some director's nephew "who was a genuine whizkid with websites", old-skool Mainframe programmers adjusting to the new wave of computing or whatnot.

Fortunately, these days, this phenomenon is pretty much a thing of the past.

Mostly anyway.

IT/Web projects have become business critical and are therefore generally regarded as something best left to proven professionals with at least something of a track record. But even professionals get it wrong. If we look at the article, Victor is probably what WTF describes as "A Complicator". In summary, described as:

“There are some so deeply embedded within The Complicators, that they've acquired a sort of sixth-sense: the ability to find meta-problems ("a problem with the process of creating a solution for the actual problem") in virtually any solution.

As we've all seen, the systems that these developers create often end up as a barely functional application comprised of a Matryoshka-doll-like nesting of problems and solutions.”

And this would all be funny if the most recent experience I had with such a type was "back in the 90s". It was actually very recent.

As a Sitecore consultant (as in, a consultant working with the Sitecore product, not to be confused with a consultant working for Sitecore) I was recently tasked with what looked to be a very straightforward assignment. The client had oversold (which is impressive given the current state of financial affairs) and needed an extra pair of hands to wrap up some loose ends on a few existing projects and then help on the implementation of 1-2 new sites from scratch.

The client didn't have years and years of experience in working with Sitecore, and therefore already had another professional Sitecore consultant on the task. He apparently came with an impressive track record, a good friend of the house and so on. All in all, this was promising to be a sweet deal and I was looking forward to it.

The first week or so, I would be working on my own. No problem. I mean, that's what one would be thinking, no? Almost complete site, just a few issues with some "Related People" not showing quite like the client wanted it. Sounded like straight forward filtering to me, or possibly adjusting a few queries. I should know better by now, that to jump to conclusions ;-)

Much to my surprise, when I started digging in, I found a Sitecore implementation unlike anything I've ever seen before. And I've seen quite a few. Both done in companies I worked for, in clients I've contracted to, in solutions I've been tasked to review. I was confident in my belief that I pretty much had this thing called "Sitecore" nailed and nothing could truly surprise me to any real extent.

Well how about this then.

Ever seen a entire Sitecore site done in just 1 rendering sitting hardcoded into 1 layout? Ever seen a Sitecore site with 3 layers of inherited templates (65 of them in all, just about) yet the ENTIRE site consisted of content items ALL based on just 1 "Mega Template" (aptly named "Page")?

And being designed like this, ever tried to explain to your end user why there are 50 fields, and depending on what values you define in some of them, other fields need to have specific values set? Complicator indeed. We're not talking a simple website here either, mind you. While it is difficult to rate the complexity of a website, it had all the bits you would normally expect today. Content pages, menu structure, left hand navigation, right hand spot elements, you know. The works.

Ok so.

With the issue at hand; "Mr. So and So displays BELOW Mrs. This and That on the People Page. We need the order to be reversed" I started investigating.

Now what probably should have been a 30 minute task ended up taking a couple of days of my time. Backtracking through an immense hierarchy of included XSLT renderings, mode="whatIneedNow" switches and so on - just to get a basic overview of how this Expert System was actually producing page output. Must be my limited mental capacity shining through, or me getting old or something. Or both ;-)

See to build a site like this, essentially bypassing everything "Sitecore" except for perhaps "Sitecore-as-an-advanced-field-editor", one needs to come up with an alternative system. Enter "The Meta System". A sophisticated hierarchy of tags, metatags and content "blobs" which users could then (in theory, at least) tag up and ultimately have displayed on the site.

See there was a "PeopleLister" meta component, an "Office" component, and if you happened to tag everything up just right - you would eventually get information out on your site.

All generated by the very clever rendering Expert System. And as for the problem at hand, I guess the system didn't really consider the order People needed to be presented.

Worse yet - this changed from time to time. Sometimes an alphabetical list of All People was needed, and sometimes the order (as in the case I was tracking) followed "silly business rules" (this is an actual quote). A week came and went, and I finally had the chance to confront my colleague-consultant. While my first inclination was to ask "WTF!?" I did start on a more subtle approach. After all, being a visitor to the client a consultant is expected to show some degree of humility - maybe they preferred it their way.

Turns out they did.

Q: But what about the Page Editor? Surely clients must have seen a Sitecore demonstration, Nicam or otherwise, and expect this to work?

A: Nah, noone uses that anyway. It's not imporant.

Q: Ok. So what about caching? Sitecore has little chance to implement much in terms of useful caching when all it sees is ONE rendering on ONE layout?

A: That's not important. Servers are so quick today anyway.

Q: Umm ok. Well then what about user security? How will you assign permissions in this hierarchy of metadata - controlling which users can actually access/change/delete what?

A: We just give everyone "Is Administrator" permissions and write a guide. If they break anything we can always restore back.

Q: Aha. Well how about integrating other Sitecore modules, like for eCommerce, SEO and so on?

A: It can be done. Or we can just install those on a separate installation and run it on a sub domain. That's what the users want anyway, not to complicate things.

Some may think I am kidding, sadly this is not the case :P Not to complicate things.... Sitecore Support, you have my heartfelt sympathies. I certainly hope you don't get many of these cases dumped into your support tool.

And if you do, kudos for what must be endlessly much more patience than I have myself. After these initial rounds in the ring, everyone decided it was probably best I went on to greener pastures and left them to it ;-)

Let me end this by pointing out what I have already pointed out in the past; please DO be aware that Sitecore is putting great effort into publishing guidelines, best practices and "Cookbooks" for how to approach Sitecore site implementation, development and handling. They're all on SDN. I haven't had time to read through ALL of them yet (shame on me); but if anyone has - is there a definition for Expert System in there? ;-)