2008, the year that was

So. 2008. What a year! We’ve seen a lot of activity from Sitecore this year. We had the Beta program for the new Sitecore codenamed Crestone which was later released as Sitecore 6. This version of Sitecore is the most polished to date (as you would expect). The Sitecore product just keeps getting better and I keep having fun using it.

On a personal note, I had 2 major Sitecore achievements I wanted to complete this year. The first was the initial release of Revolver, which I managed to deliver early in the year. That was a great triumph for me as I have been writing Revolver since about November 2006 (only part time in the seconds of spare time I could find). The other achievement I was hoping to complete didn’t happen. I can’t say too much on it at the moment, but rest assured Phil, I’m still working on it .

I also started blogging to pass my ideas and experiences onto the wider Sitecore community. This has been a most fulfilling experience. There is nothing quite like walking around the office at work and seeing one of the other devs reading my blog. Or having them post comments on my ramblings. Or having some of the highly respected Sitecore people commenting on my posts.

I also started contributing to Sitecore shared source. I started out by publishing some of my Sitecore tweaks into shared source; the Quicklaunch Toolbar and the Editor line numbers. But just a sniff of shared source is all it takes to get hooked. I’m currently working in conjunction with some people from Sitecore and the wider Sitecore community on a new shared source module (more on that when we’ve got a bit further along), but I’ve still got heaps of ideas for shared source components which I’ll get onto as soon as I find some more spare time (or finish one of my other projects).

So what’s in store for us in Sitecore land in 2009? I look forward to it.

Happy new year everyone!

Sitecore Desktop in Firefox and production javascript debugging

Back in the pre Sitecore 5.3 days I would sometimes prefer to use Firefox when logging into the Sitecore desktop. Firefox was much faster than IE for this interface, and especially if I was looking at a slow implementation Firefox would help ease some frustration. The desktop didn’t look exactly as it should in Firefox, which is probably why Sitecore revoked support for the Sitecore desktop for anything non-IE starting with Sitecore 5.3. I also think it does much better for Sitecore if they allow people to use non-IE browsers to access the desktop interface. Warn them that it won’t look right, but let them make their own choice. (or even better, fully support the other browsers.)

So I started looking into how I could access the Sitecore 6 desktop by using Firefox. The login screen obviously was doing some kind of agent sniffing as it removes the desktop interface option if you’re not using IE. So I started by looking into the login form itself. This is located at /sitecore/login/default.aspx. Browsing the controls in this file I could see an advanced login control near the bottom of the file.

<div id="AdvancedLoginTabPanel" runat="server">
<login:AdvancedLogin runat="server" id="AdvancedLogin"/>
</div>

Knowing that the desktop interface is available on the advanced tab of the login screen I know this must be the control which will contain the desktop login option. Checking the ‘Register’ declarations at the top of the file I can find the advanced login control is contained in the /sitecore/login/advanced.ascx file. Opening this file I can find the button control which is the desktop interface option.

<button id="AdvancedDesktop" type="button" runat="server"
  onclick="javascript:onClick('AdvancedOptions', 'AdvancedDesktop', '/sitecore/shell/default.aspx')"
  ondblclick="javascript:onDblClick()">
<img class="AdvancedOptionImage"
  src="/sitecore/shell/themes/standard/People/32x32/monitor.png"
  alt="Desktop" border="0" />
Desktop
</button>

Note the javascript call for onclick. So that must mean that the interface selected for login must be stored by javascript and posted during the postback for the actual login. Well, seeing as though it’s this control which is hidden by Sitecore if you’re not using IE, then all I have to do is duplicate this control and change it’s ID. After all, it’s the javascript which is changing the selected interface.

And there we have it, the option to login to the desktop inside Firefox again. Ahh, the memories…

We can also satisfy ‘that mac guy’…

But what about the production javascript debugging bit in the title of this post? Javascript might be sandboxed off from the rest of the computer, but it is not sandboxed from the user.

So a typical example of debugging javascript would normally include placing a few alert statements throughout your misbehaving function to print the value of variables to see where and how your data is changing. On a production website you would never consider putting these debug statements in the javascript file as every visitor would have these debug messages interrupting them which is not acceptable. But you don’t need to change your javascript code if all you want to do is look at variable values, as long as they are global.

Through the address bar of my browser I can access the javascript sandbox of the web page. All I have to do is use the ‘javascript:’ protocol. So let’s say I have a global variable named loginOpt. All I have to do to view it’s value is enter the following in the address bar.

javascript:alert(loginOpt)

The javascript gets executed in the same sandbox as the web page, so I have access to all the global variables of the page. I could also call javascript functions such as the function that the desktop button calls to set the selected interface for login. So if I didn’t want to physically change the /sitecore/login/advanced.ascx file above, or if I didn’t have physical access to the file, I could set the desktop as the selected interface to log into on the Sitecore login page by executing the required javascript after the page has loaded by pasting the following into the address bar.

javascript:onClick('AdvancedOptions', 'AdvancedDesktop', '/sitecore/shell/default.aspx')

And then just login.

I first found the ability to execute javascript in the address bar in a consumer computer magazine (APC http://apcmag.com (sorry, can’t remember the issue)). The scenario given in the magazine was that of creating ‘javascript bookmarklets’ where you create a bookmark but instead of inputting a url you input some javascript to be run instead. The javascript they gave in the example was to remove the background image of a web page. I was recently reminded of this ability when I was debugging a page which was hosted from a server I didn’t have direct access to. I needed to work out how a particular function came to calculate it’s output value which was being done using jQuery (http://jquery.com/). So I just copied the jQuery section in question out of the external javascript file, pasted it into the address bar and quickly found my result. Again, we’re in the page’s sandbox, so if the page uses jQuery, we can also use jQuery.

So there you go. 2 techniques to allow non IE browsers to use the Sitecore desktop, and a little tidbit on investigating javascript without modifying the javascript files.

I’d also like to take this opportunity to wish everyone a Merry Christmas. I hope Santa brings you everything you wished for.

My Sitecore Wishlist

A few weeks ago Alex de Groot asked the Sitecore community, through a post on his blog, what we want to see in Sitecore. How would we improve it? What features are we missing?

So rather than comment on his post, I am posting my response here. Hopefully it will invoke some thought and others will post their Sitecore wishlists for all too see and talk about.

Below, in no particular order, is my Sitecore wishlist.

1. Faster UI. The Sitecore interfaces are a marvel of ingenuity. Sitecore itself is very extensible and customisable, and the interfaces (UI) are no different. Just look at all the things we can do with the desktop, including writing our own applications which will run inside it and look like a native Sitecore application. As a developer I can appreciate what it took to make this happen. Unfortunately, those heathen non-technical end users don’t always. This is possibly the biggest complaint I get from clients. They feel the interfaces are too slow and could do with a performance boost.
2. Placeholders through inheritance for presentation. Quite often I find myself wanting to define the majority of the presentation on a base template, and only define some smaller pieces on the current template itself. At times you can get away with this by statically placing (hard coding) the page’s presentation hardware (components that don’t change page to page) on the layout itself. Then you just have to define the layout and bind in those page specific components. The issue is I might want to make updates to the page hardware later and don’t want to lose the flexibility I gain through using placeholders. Or I might want the user to be able to adjust this using the page designer. If I could bind presentation components to placeholders on base templates, my problems would be solved. And perhaps also include Chris Wojciech’s Sitecore tweak, the extended placeholder selection module which is now in Shared source, to make the selection of the placeholder on the child template easier.

   

3. Better cross browser support for interfaces. Back in the pre 5.3 days I could access the desktop interface using Firefox. And Firefox was much faster than IE inside the desktop. It didn’t look quite right, but the performance was there, and that was what I was after. Along came 5.3 with heaps of added features (the content editor ribbon, etc) which were great, but Sitecore took away the ability to use non-IE browsers to access the desktop. I’d like to see full cross browser support for the desktop. The question of this ability normally comes up during tender demonstrations from “that mac guy” in the room asking if he can use Safari to do everything I’m doing.
4. Some fat tools. There are many things in Sitecore that don’t HAVE to be done in the context of a web request. Such as publishing. All publishing is doing is pulling items from the source database and pushing them into the target database. This could easily be done outside an HttpContext. Don’t get me wrong, I never want to lose the full web app support that Sitecore offers right now. I think another of the big bonuses for Sitecore is the fact that it runs completely in the browser without any requirement on anything being installed on the client. I just think some of the functions could be supplemented with some fat tools. Another example would be content editing. And scheduled publishing. It’s great that Sitecore has facility to scheduled publishing operations, but I’d like to be able to specify the exact time at which it should run, not just an approximate interval.
5. More secure Database roles. Sitecore uses a single user to access each of the databases. It would be good to have the option to segment functions to database roles. For example, the front end content delivery functions can be segmented from the administration functions. The delivery functions do not require as many permissions as the admin functions, so a separate less permissive account / role could be used for that. This is all in the name of security. Developers will still just use a single account for all their DBs, but the operations guys want a more secure option.
6. Sitecore installer to create database user. The Sitecore installer UI already contains all the options to allow you to install the database component of Sitecore using the current user (integrated authentication). But you can’t currently use this option. I would like this option to be able to be used, and have the installer create a new database user account for me and assign the appropriate permissions to this user for the databases being installed. The current user credentials can be used to create the new database, restore from the backup and create the new user.

Common uses for Revolver

When developing Sitecore solutions I use Revolver a lot. I find it easier and quicker at times to do things in the command prompt than clicking through the beautiful UI. So here’s a bit of a list of common scenarios I use Revolver for.

Most of the scripts below utilise the find command. By far I think the ability to execute the same command against a set of items is the biggest benefit.

You can set ‘filters’ on the find command through the parameters you pass to the command. This will include the items which pass the filter into the execution set, and have the command (last parameter passed) executed against them. You can also optionally pass the recursive (-r) parameter to cause the command to recurse down the tree using the current item as the root. If you leave the recursive parameter out then only the children of the current item are looked at.

1. Unlock all content items. Sitecore 6.0 introduced UI utilities to unlock all of your own content items, but what about unlocking all content for all users? This is good to run before your create a deployment package for a client, as it releases all the locks the developers are holding. Saves you from those calls from the client who can’t update some piece of content cause one of the developers has it locked. (The client was not an admin). Locks on items are controlled through the __lock field. So it’s just a matter of changing that field to an empty lock. Because we want this command to be executed against every item, we don’t pass any filters in this time. Start at the root (/sitecore).

   find -r (sf __lock (<r />))
   

2. Find items with spaces in their names. Sitecore by default allows you to create items with spaces in the names. The problem is you end up with a validation warning cause the space will get encoded to ‘%20′ when used in URLs (bad for SEO). This script allows you to find all items that have a space in their name so you can change it. The items it finds will have their paths printed into the command prompt window. The field value we’re matching on here is a regular expression.

   find -r -a key \s pwd
   

3. Find updated items. This script is good when generating deployment packages. To find all content which has been updated since a certain date, we’ll use the find command (of course) with an expression filter so we can specify a date the __updated field must be later than. Expressions are specific to Revolver. They are a way of writing a test based on attribute and field values. I based expressions on Sitecore query, so a single at (@) denotes a field and double at (@@) denotes an attribute.

   find -r -e (@__updated >= 20081201) pwd
   

4. Find created items. This script is the same as the script above, except now we use the __created field for comparison.

   find -r -e (@__created >= 20081202) pwd
   

For more detail on the find command you can see the help topic on the find command from within the command prompt.

help find

Help has been baked into Revolver from the start. Each help topic describes the usage of the command, gives explanation to the parameters you can pass to it, and gives some examples of how to use the command.

You could also achieve the above using the query command. Query does the same as find except you can use a Sitecore query instead of the filter parameters. One other major difference between these 2 commands is how the get executed. Query is executed as a Sitecore query and so is limited to the ‘Query.MaxItems’ setting in web.config. By default this value is set to 100. So if you’re running queries and keep getting 100 results back, try increasing this value. Find on the other hand uses the API to recurse down to each item it needs to address based on whether the find command executed is recursive and the filters applied. So I would expect find to run slower than query, but it will always hit each item I expect.