codeflood logo

Learning the Screwdriver

Posted in:

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.

Comments

Kevin Buckley

Nice post. I've had a similar experience working at a CMS company, later using DotNetNuke then finding Sitecore.
You might be able to create themes in sitecore with some type of custom layout resolver where you always point to a default layouts folder but override the root folder based on the setting.
A theme has to be limited and kind of standard and supoport a consistent set of placeholder keys that you define. I kind of think all pages should anyway so you can change the layout and not have things not show up on the page.
Taking a quick look I think something could be done with a custom Layout Resolver where you replace the root folder of the Context.Page.FilePath to the folder for you current theme but I haven't tried.
Probably more complicated than that but gotta start somewhere.

Alistair Deneys

Nice proposal Kevin.
I would suggest the theme folders are just used to override the default controls. In that way you'd only have to define the controls from your pool (or default theme) which you need to customise for your given theme.
It would be interesting to see how this would go if you developed it into a shared source module. I was talking with a colleague recently about skinning and theming and whether we could make use of it in Sitecore and came to the conclusion that the kind of client who has budget for Sitecore always wants a completely custom design applied to their site. I find themes are great when you just need to get a site up quickly or an intranet, but for your corporate site they are not likely to cut it, so I'd be interested to see if people would use theming if it was provided as you describe above.

Kevin Buckley

I work at a company that uses sitecore, not a solutions provider, so my knowledge around the business aspects are a bit limited.
That being said you mentioned having somewhat of a widgets framework, I also have a widgets type framework and it has some skinning capabilities.
My thought is if there's every going to be a company that provides a Sitecore Shared Hosting Environment where hunderds of sites could be running on one instance of sitecore things like Themes and Widgets or Content Modules and Skins are going to need to be available via a framework people can consistently code to.
Every site may have it's custom theme or themes but they should be able to share the same widgets, have custom widgets installed and built.
I'm not familiar with sitecore licensing, I believe it's CPU based and I don't know what the official cost is but they might not be against having this type of licensing model if the framework was built out to support it.
I think it would come down to is can you make something like wordpress for sitecore with theme and widget support, and get enough people to use it to cover the license fees for the amount of CPU's you would need.
From what I see there may be room for someone to become king of sitecore shared hosting, but they'd need sitecore to be interested in licensing that out.

Alistair Deneys

Yes, I agree Kevin.
Sitecore can be prohibitive for a lot of companies simply due to cost. A hosted solution for them would be quite cost effective and open up the opportunity for these companies to make use of Sitecore.
Current Sitecore licensing does not allow setting up a shared Sitecore hosting infrastructure as you describe above. I remember a few years ago there was talk of Sitecore setting up a shared hosting solution themselves, but that never seemed to come to fruition.

Leave a comment

All fields are required.