Learning the Screwdriver

Recently I had to learn another CMS to create a site for a family member’s new business. Being that it is a commercial site I couldn’t use Sitecore Xpress for it. But realistically I’d been looking for an excuse to learn a new CMS anyway to become more pragmatic in my approach to developing with CMSs.

This idea comes from the idea of learning multiple programming languages to become more pragmatic in your approach to programming. Features of one language may not be offered in another language, and the approaches you take to fix similar problems in each may differ greatly. This activity can give you as a programmer a very different perspective on things you used to know and only approach in a certain way.

The best quote to illustrate this:

 

When all you have is a hammer, everything looks like a nail.

 

But this idea of learning multiple tools for the same task at hand isn’t limited to programming languages (or even programming in general) and can be applied to how you approach a CMS website build. After having gone through this exercise I can definitely say that I look at my familiar Sitecore builds in a little different light.

The CMS chosen for this build was WordPress. The primary reason I chose WordPress for the build was because the non-technical business user who I was speaking with had heard from another non-technical business user that WordPress was awesome and she should use it to manage her website. I have used WordPress for blogging for the past 2 years, so I also had a little experience with WordPress in a non-technical capacity.

The first thing you’d normally do on a Sitecore build is define the data templates for your content items. WordPress doesn’t have structured content so this step isn’t required. All WordPress has is title and text. So the task of designing the data templates isn’t required. To support some additional concise data WordPress allows the author to define custom fields, but these are done on a page by page basis.

For the website I was building I had to support the ability to “tag” any page as being featured on the homepage. Featured pages were displayed on a separate menu on the homepage and included some optional text and an image for each page. Achieving this in a Sitecore solution with structured content is very easy, just create the fields required on a base template. In WordPress I used the custom fields to define part of this data. Because the custom fields are simply name / value pairs there’s no easy way to allow selection of an image to associate with a page. For that I leveraged the “post thumbnail” capability which allows you to select a single image for the page.

I also ran into some issues when I tried to structure the content into a tree. WordPress does support this, but I tried to do it the way I do on a Sitecore build, with the home page as the root and all other pages underneath that. In WordPress this structure was upsetting my URLs. Instead I placed all top level pages next to the home page on the same level. The home page is selected on an admin screen and behaves a little different to the other pages, particularly in regards to it’s URL.

With the data sorted I could then move into the presentation which in WordPress is done by creating a new theme. A theme isn’t just a different CSS file, you also need to define your “templates”. Yeah, I know. I can heard a bunch of Sitecore developers yelling at me right now telling me this is the incorrect usage of the term “template” as Sitecore uses it differently. But honestly, most people and systems out there call the presentation of their pages the “page template”. We need to let it go and accept that Sitecore is the minority trying to redefine that term for their own usage.

With WordPress being a PHP application you need to write your template files in PHP and the exact template which is used is determined by a number of factors. In Sitecore I choose explicitly the presentation each of my pages get, with no default as a fallback. This presentation can also be very granular and allows reuse of components and layouts. For example, each page will share a very similar overall layout but might change the control producing the main content of the page without having to redefine / rewrite the layout each time. WordPress has built in logic to determine which template to use based on the type of page the request is for (single post detail, posts summary, some other kind of post list, a page, etc). And you can also specify on a single page a different page template to use.

There are no controls in PHP, but there are includes and functions (methods). WordPress provides a variety of functions which can be called to do things like get the current page title or generate a hierarchical menu. And with the includes functionality you can carve out succinct chunks of HTML to display on many templates and define it in a single file. But unlike controls you can’t set attributes and change the behaviour or output of that piece of HTML.

So what is the appeal of WordPress? As I mentioned above it was non-technical business users who recommended I use WordPress, so why are the non-technical business users ranting about WordPress.

If I already have a LAMP (Linux, Apache, MySQL, PHP) environment setup and I know what I’m doing I can download WordPress and have a new website, ready for production up and running in about 10 minutes. And I’ve got access to a library of thousands of themes to adjust the look and feel of the website for free. And there’s also a huge library of thousands of plugins and widgets to extend the capabilities of my site. All this without any development required. Oh, and WordPress is open source and free. I think that’s another big factor.

So what can Sitecore learn from WordPress? Let’s take a look a themes. Could Sitecore support a themes feature where you could download new complete themes to completely change the look and feel of the website? This works in WordPress cause posts and pages can only have a title and text. We can’t customise the structure of the content as we do in Sitecore. So the page templates in WordPress know the exact format of the data they’re interacting with. For Sitecore to support a similar feature to themes the content structure would have to be restrained. We also have a different approach in Sitecore for how presentation is built for a page. But there’s no reason why we couldn’t use some fixed controls in the layout which chose the correct controls to load from the theme. This of course restrains what can be done in terms of presentation, so I don’t think it’s a good idea.

Just on the subject of themes, the clients that have budget for Sitecore are never going to be happy with picking a theme from a library. They will expect a completely custom theme which meets all of their needs. The reason themes works for WordPress is because many of the people using WordPress do so because of it’s cost (free), and they are quite happy to pick a theme from a library.

So what about widgets? Widgets are a function of the way WordPress builds presentation for a page. A theme may register that it supports widgets and display any installed widgets in the sidebar. And yes, I think Sitecore could support this kind of function. In fact, we already have a similar feature built into the Sitecore framework we use on all Sitecore builds at Next Digital. All this feature entails is having the widgets registered inside the CMS and a presentation component to display the widgets on the page.

And plugins? You might say Sitecore already supports plugins in that you can deploy new functionality into Sitecore through a Sitecore module. The issue here with the way Sitecore does this is that a module cannot be uninstalled or deactivated. I think this is definitely something Sitecore could learn from WordPress. In WordPress each plugin is deployed to a separate folder and must be activated through the admin screens before the plugin’s functionality becomes available. I think Sitecore could learn from this. Perhaps having each module deployed to it’s own folder so it’s very easy to remove when you don’t want it. But Sitecore packages do more than just deploy separate new functionality. For this concept to work there would have to be another mechanism.

All in all I think I’m better off having learned a different CMS and seeing the world of content management through different eyes. I am by no means an expert, but I think I can appreciate the different perspectives now. So I urge all of you to go out there, download another CMS and learn it. It will make your Sitecore solutions even better.

Announcing codeflood

It is with great pleasure I finally announce the launch of my new website, codeflood. So what is codeflood? codeflood is an attempt at a more professional web presence than my previous self indulgent website World of Al. codeflood is where I will host my projects such as Revolver for Sitecore and SashimiCMS.

Although the current project pages on World of Al will remain, all the new stuff and new versions will be released through codeflood. I’ll add a nice little message to the deprecated pages on World of Al to point users to codeflood.

I’ve gotta say, I’m quite excited to finally get this website live. I’ve been slaving over getting it live since the start of December, and interrupting my other projects such as the next version of Revolver and the Sitecore shared source Integrated Help Module. More on both of those to come…

User Group Meeting

Last night we held the first Sitecore Australia and New Zealand User Group meeting in Melbourne, Victoria, Australia. Note for anyone wanting to hold a user group meeting, don’t do it in a noisy pub if you have presentations to make.

I’d chosen what I thought would be a quiet pub for a Wednesday night. Unfortunately it wasn’t so quiet. Tim Ward and myself both made presentations to the users. Tim talked about OMS and Sitecore 6.1 and I talked about Techniques for sharing content in Sitecore between sites (details on that in another post). It would have been fine if not for the noise which prevented most of the users from hearing anything Tim or I were trying to say.

So for all those that came, thank you and apologies for the noise. We’ll select the next user group meeting venue more carefully. The next meeting we’re also aiming to have in a different city to give more users the opportunity to come to a meeting.

Here’s a few pictures from the meeting.

Some of the users gathering before the presentations.

Start of the presentations.

Tim Ward (Sitecore Solution Architect for Sitecore Australia) presenting Sitecore 6.1 and OMS.

Introduction to SashimiCMS

I’ve recently made a few minor updates to SashimiCMS and released a new version 1.1.2. You can find SashimiCMS on my website at http://users.tpg.com.au/adeneys/sashimiHome.html.

So what is SashimiCMS? SashimiCMS is a CMS I created a few years ago. I didn’t write any compilable code for this CMS. All data is stored in XML files, all transforms are done using XSLT and the thing that binds this all together and builds the site is the Java build technology Apache Ant . The CMS contains no friendly user interfaces and no web interface. It is developer oriented as you have to write the (x)HTML yourself.

But what good is SashimiCMS? To answer that, let’s look at why I created it in the first place. I was redesigning a community website that was being hosted on a free hosting platform which didn’t allow server code. I didn’t want to have to worry about keeping the common page elements such as navigations in check and consistent across the site, so I tried to devise a way in which to automate this. My original idea was to write some code that would replace custom tags in the HTML files. So instead of writing out the navigational components, I could just use a custom tags like <menu/>. And being that I wanted to remain cross platform compatible I was going to write this in Java.

At the same time that I was thinking about this little project I was playing with Apache Ant a fair bit at work. At the time I was doing a little stint as a Solaris sys admin and build manager for a Java project. Through playing with Ant I realized it could execute XSLT directly without any extensions. I already knew about the power of XSLT through a little bit of reading and a brief play with it through using Sitecore 4. So I started to create the first incarnation of SashimiCMS which worked quite well.

The original version of SashimiCMS was actually custom built into the community website I was building. After I launched that site I rewrote SashimiCMS under it’s new name using the website project as a reference. And thus, SashimiCMS was born.

SashimiCMS doesn’t have a huge market share, and it never will. In fact, I only know of 2 sites which use it. One is the community site (hopefully soon to be migrated to Sitecore Xpress ) and the other is my website http://users.tpg.com.au/adeneys.

But looking at SashimiCMS in terms of raw features, it does have some pretty nice facets which I’m proud of. It employs a “page template” approach to pages. You simply write your HTML page template and use it amongst several pages. Each page and template can make use of custom tags which the user creates. So I could create a custom tag for a reusable piece of HTML, such as the webmaster email link might be bound to a custom tag called <email/>. Out of the box there are “controls” to render menus, a breadcrumb, a header, a footer, rss and lists of articles. And SashimiCMS is cross platform. It runs wherever Ant runs; Windows, Linux, Mac, Solaris, Unix, etc.

Each page can also contain multiple content fragments which are bound into the template at build time. So I might define the central content area as a fragment, and some side bar promotional element as another content fragment, and the template pulls these fragments in at build time.

So what should you use SashimiCMS for? SashimiCMS can aid you when you have to generate an HTML only site and the only people interacting with the content will be developers. For any other case at all, use Sitecore!

My New Blog

Welcome to my new Blog!

Now get off my back Phil!

My name is Alistair Deneys and I’m a Solution Architect working with .net and Sitecore. I have a strong interest in programming languages and development process and I hope to share some of my experiences with you.

Ever since Phil Heltewig started the Australian Sitecore office, he’s been hassling me to start a blog. I’ve been resisting for a while now as I’ve just had too much on. I hope some of you have seen my hard work in Revolver. Now that the Revolver release is imminent (the beta is just wrapping up), I’m finding I have a little more time on my hands (which I’m sure will evaporate very soon). This all also falls into timing with the NDA period for the new release of Sitecore codenamed Crestone coming to an end and the floodgates are opening on the torrent of Crestone info about to hit the wild, wild web. In a vain fit, I’m hoping to cast one of the first Crestone blog entries (next blog post…).

So, back to me and blogging. Previously I’ve resisted the urge to blog. I’ve seen far too many blogs which were appalling. Blog entries which were no more than “I saw this cool link, go check it out”. Or entries which just asked the readers what they were doing; “I want to do this thing. How are you all doing it?”. These kinds of blog entries add absolutely no value what-so-ever. But why should I not try to contribute just because these other blogs only detract? So I’ve set myself some boundaries and guidelines to blog within.

And so, here we go, further down the rabbit hole…