Wriitngs about Life, the Web, and SilverStripe CMS

The Benefits of Using a CMS for Your Clients

Tue, 25 Jan 2011 22:03:02 -0600

As a Web Developer (or Web Professional in general), it is my job to give my clients the best recommendation for how to build their site. The two main choices are:

The static HTML version where, if the client wishes to make any updates to their website, they have to brave FTP to access their files, find the right one, then try to write even semi well-formed HTML so they don't leave a tag open or close one prematurely that horribly breaks the appearance of their website and you get a frantic call while you're cooking that time-sensitive roast requesting you drop everything you're doing to fix it this minute. Heaven forbid you use some PHP (or Server-Side Language of your choice) to reuse headers and footers across pages. That's 3 acronyms they have to understand.
The dynamic, database driven website where all the content is stored in a database and output into template files, most commonly found in the form of a CMS.

In the Beginning...

In my early days of professional web work, I built sites following the first methodology. It was my job to train the clients how to update their site and give them a primer on HTML. I even had the misfortune of trying to adapt a site to be maintainable with Adobe Contribute. For those who are unfamiliar with it, it's halfway between both the options I listed above. You edit the files in a Dreamweaver-like WYSIWYG window and can set up permissions for who can edit what through Contribute. Nifty idea but I only used it once, at the client's request, and I hope to never use it again.

But I digress...

But the point of this post is to discuss option the second. Feel free to cite anything I say for your clients in convincing them to invest the extra money to get their site running on a CMS. It does take a little extra time (and therefore money up front) to set up a site on a CMS, but the benefits are so worth it. The points I make will apply to most or all CMS's (or should).

No need for the client to learn how to log into a server with FTP and edit any code. In my opinion, this is the best reason. Everything happens in the web browser. For the static HTML option, the client will need, at minimum, an FTP program and a text editor program, even if it's NotePad. Most, if not all CMS's, use a WYSIWYG field for editing the body content of any page, product, blog post, etc and using one is similar to using MS Word which just about everyone knows how to use. These wonderful fields write the HTML behind the scenes and the most complicated thing to teach the the client is when to use different level headings. The rest of the information about the page is just filling in text fields and uploading files as necessary. So much easier.
CMS's are scalable. This means that, by laying the proper groundwork, the site becomes much easier to manage as it grows and is also much easier to extend its features.
CMS's are built on top of a lot of pre-written code. This means that there's a powerful toolset available to reduce time, and cost, for adding features to the website.
With a CMS, you can enter bits of content once, like products in a store or job postings, and use them anywhere on your website or other websites. If you edit any of the original bit of content, like the description of a product or the title of a job posting, anywhere that content is being referenced will automatically update to reflect the change. Edit once, update everywhere. For example, if there's a store on the website and it showcases select products on various pages, rather than manually entering the product details on those pages, you select which products to show and if any product details changed, all the instances of the showcased products would automatically update.

SilverStripe is my CMS of choice. I've used many others but I find SilverStripe is great for websites small and large. Installing it is takes me 10 minutes and it's very portable between server environments. Adding and editing pages is so intuitive and it's so simple to create a couple custom page types that require an image or manage a collection of child page entries. And the framework it's built on is so powerful and easily extendable. One prominent member of the SilverStripe community developed a small (joke, I think) web app in under an hour with it (Uncle Cheese for those who know of him).

There are more technical reasons why SilverStripe is my CMS of choice, but this was meant for more laymen, non-tech-savvy types. So help me, I'll never build a static HTML website for a client ever again.

The Great CMS Roundup

Sat, 13 Nov 2010 16:09:41 -0600

Everyone's done it and now it's my turn. Since I started working on the web professionally in late-2004, I've hand my hands on Drupal, Joomla, WordPress, ExpressionEngine, and SilverStripe. I've cried and lauded aspects of each one and I'm here today to give my objective comparison of all 5. So, without further ado, let's begin.

Drupal

Drupal is one of the Big 2 open source CMS's out there. It has a pretty rabid and dedicated community and has definitely been around from the early days of CMS software. It is also maligned by developers who have "moved beyond" its limitations and on to "better" CMS's (I don't mean the quotes in any derisive way, merely just quoting words I've heard people use in context. You're entitled to your opinion about which CMS is the best and so am I). The problems I've found with Drupal are that it's rooted in old coding practices from back when it was released in 2001 in the early days of PHP4. I'm not positive if it was originally written in PHP 3 or 4 but the last time I had my hands in it with a Drupal 5 installation (around 2008), I was still working with procedural code with no sightings of anything resembling OOP practices. I feel it suffers from a problem of any software that's been around for a while in that rebuilding the code under the hood would be such a huge undertaking that new versions just strap on new functionality in some hybrid coding practice of the old and the new.

The admin panel is not very intuitive either. In order to make a new page on the site, you have to jump around to 3 or 4 different panels for doing something that should be pretty simple. There's also so many sections for changing settings and such that it's easy to get lost and impossible to find what you need, especially for a non-tech-savvy site maintainer. Drupal has evolved to be very flexible but it has become extremely complicated along the way as a side effect.

One thing I can't argue with is the plethora of modules that extend the functionality. With its age comes a lot of time to build and refine the modules for it AND to have choices in what flavor of blog, store, forum, etc. Also, the community is huge now which means lots of support and pro developers. However, despite that, I feel that the fragmented and old coding style of the software which makes for a steep learning curve to develop for it and the enormous admin panel which I wouldn't wish upon any client of mine makes it one to leave where it belongs with the coding dinosaurs. I feel like it's better for the Drupal devoted to develop their own sites with it and find a different solution for their clients.

Joomla

Joomla is the other of the Big 2 CMS's out there. It's a lot like Drupal except that it's not the fault of its developers that its code is old and dated like Drupal. Joomla branched from the Mambo CMS back in 2005 due to some differences in opinion of the company that produced Mambo and the developer community that had formed around it. Mambo had been around since 2000 and Joomla branched off to begin its own evolution. Joomla felt a little nicer and simpler than Drupal. However, despite its large developer community, many developers have also "moved on to better CMS's." Drupal and Joomla are the CMS's that a lot of new CMS's try to NOT be like and fix the problems that each one has.

The admin interface is still more complex than it needs to be, mired down with large sections of customizable settings and multi-step page creation processes. However, it is definitely a step up from Drupal's. One thing I think people don't realize is that, even though Joomla hasn't versioned up much in its 5 years of life, its maintainers have been taking on the enormous task of rewriting its codebase to OOP and MVC patterns. Version 1.0 was largely a rebranded snapshot of Mambo with some tweaks, but version 1.5 introduced the new OOP and MVC codebase they were working toward. 1.5 served as a transition point with the core developers giving the community until 1.6 to port over their modules to the new codebase at which point 1.6 would drop support for the old modules. I had a job for about a year back in 2007-2008 during the time Joomla had released its 1.5 beta releases and my company was a Joomla shop so I was in the Joomla loop.

Like Drupal, it has an enormous developer community for support and a wealth of modules to choose from to add functionalty. I think it's definitely one to keep an eye on. Maybe once it gets to 2.0 and they have the new direction of the codebase firmly established, it may become better to develop with. Only time will tell.

Wordpress

Wordpress has come up a lot in the world of CMS's. Starting off as a solid blogging platform, version 3.0 offers more CMS-like functionality. I launced one small website with Wordpress 2.3 since I felt it was much better than Drupal or Joomla at the time. I'm am amazed at the kinds of functionality built for Wordpress when it was really a blog platform, especially the store module(s). Not bad for a codebase built to work as a blog. I'd bet there was a huge amount of custom coding for that module.

Anyway, as I mentioned above, Wordpress's codebase is (or was last time I used it) very blog-centric. It's also written (or was, maybe) in a mostly procedural fashion with very little OOP methods used. One thing I find interesting about it, and I give kudos to its core developers for this, is that most of its functions that get used in the templates, are made to look like tags that belong in the HTML. Many systems use a custom templating engine to make life easier for frontend coders who only really know HTML and CSS to not have to learn PHP or whatever language powers the system. Using a templating engine also adds some processing overhead to each time a page loads. Wordpress tailored their functions for the templates to look as much like a simple templating engine while still being raw PHP. Seeing <?php the_header() ?> and <?php the_footer() ?> in the template is about as simple as you can get.

The admin panel for Worpress is also really well-organized. It's pretty obvious how to add a new blog entry (and a new page now, I would assume) and where to go to accomplish different tasks. They also use Javascript to improve the UI making for less clicks necessary to accomplish a given task. They also tout their famous 5 minute installation and I give them credit on this one. With the proper server setup, installing Wordpress is one of the simplest web apps I've ever installed.

Since I've only built one site with Wordpress and it was a small, blog-centric one, I didn't get my hands too dirty with custom development. I don't think I wrote much custom PHP, mainly relying on the exsiting API so I can't speak much for developing for it. I do know that there are also a lot of faithful developers for it. I could see myself coming back to it one day if my current CMS of choice died or fell apart.

ExpressionEngine

My current job has me using the ExpressionEngine CMS. By far, it's the CMS I have the second-most experience with. Among the CMS's I've used, EE is the only one that requires purchase. All the others are open source. I've been working with it for about 7 months now and I just can't get into it. Don't get me wrong, EE has a lot of good things going for it. It has a very dedicated developer community of people who appreciate quality and who I've had the good fortune of meeting some of. There's a large collection of add-ons that do things from improving the backend UI to strapping on whole forums and e-commerce systems. There's also a very active forum that is an extremely valuable resource for answering questions that come up. Both the veteran developers in the community and the members of EllisLab (the development company behind EE) will answer questions there. The admin panel (or Control Panel, or CP if you're hip to the jive), looks nice and is pretty well organized. You can even edit what shows up in the CP for different users, providing the ability to lock the site maintainers out of areas they shouldn't be poking around in. It has a pretty flexible templating engine that allows you to access the content in the templates and have access to some simple control structures without writing a single line of PHP. You can easily get away with building a small to medium site without writing a lick of PHP which is pretty impressive in my book. It uses OOP coding methods which make the code cleaner and more portable.

Despite all this, the thing that gets me the most can be summed up like this: EE is a designer's CMS. If you can write HTML and CSS, you can use EE. If you're a programmer, EE may drive you nuts as it has with me. If you start nesting too deep with the templating code, things stop working consistently. It has a very strange sense of scope and context that makes the templating engine work harder than it needs to. For example, I recently found out that if you put a simple if/else structure in your template, if will render both blocks and then parse the if/else to choose which one to go with. Conversely in a programming language, it tests each "if" statement and will skip down the list until it finds a condition to run and THEN it processes that block and ignores the rest. Imagine having an if/else block with some "else if's" in there and each block required some intensive processing to render. Can we say performance hit. However, I found this out by being introduced to an add-on that fixes this behavior. Also, if I get too deep nesting in the template, things stop working as expected. If you give me control structures and loops like in a programming language, I expect them to work consistently, no matter how deep the nesting goes. It's the programmer in me.

Another pro for EE is that you can define your own data structures through the CP. If I want a staff detail page, I can make a page type that has a name field (usually the page title), a photo upload field, a generic WYSIWYG field for bio, description or whatever, and any number of other fields you want for custom content. I've come to realize this is huge, especially because it's baked into the core functionality.

Writing PHP for EE isn't bad, either. I have written some small add-ons that mainly just add new template tags to the CMS. That IS another thing I dig about EE. It's very easy to extend the templating language. God forbid you have to get into the database though. The database is a bizarre land of abstracted data structures. The core table that stores all the content is huge and inefficient. Every new custom field you add through the UI gets added as a column onto this table. So if you've created 50 different custom fields for use across mutliple page types, it's all stored in the same table and the able will have 50+ columns and many of them will be empty on each row. If you want to pull data from DB in the PHP, you need to map the columns to their fields, and... it's just a huge mess.

One last note I will say about EE before concluding on it. EE version 2 has been rebuilt from the ground up on EllisLab's renowned PHP framework CodeIgniter. CodeIgniter is a simple, elegant, and excellent framework and has been recognized and used by some major companies out there. I've also done a little development with it while I was looking for a new CMS to use and it's pretty nice. Developing for EE2 is allegedly much easier now that it is built on CodeIgniter.

There's a lot more good and bad I could say about EE but I'll sum it all up in a couple sentences. EE is a designer's CMS. I've seen someone else say the same thing. If you're a designer and don't have a developer to build the custom CMS functionality, EE is the CMS for you. If you're a developer, EE can be restricting, confining and frustrating but not impossible. For me, it's hard to like a piece of software when you have already found one that works well for you.

SilverStripe

Last we come to SilverStripe, my current CMS of choice and one that I don't see getting de-throned from that status anytime soon. There are so many reasons why SS has won out for me. Using SilverStripe has shown me what doesn't work in all the other CMS's I've used. Much of what I've pointed out about the others, and more, is largely in comparison to how SS does things. To me, SilverStripe just does so many things right. It recently won the New Zealand Open Source Awards for 2010 for Best Open Source Project. Before I get into details, I'll give a little backstory.

SilverStripe is pretty young in the open source CMS world and, where I am on the west coast of the USA, SilverStripe developers for it are pretty sparse. Between myself and a colleague of mine in San Francisco who introduced me to SilverStripe in his quest for a better CMS, we're the only choices in the San Francisco Bay Area. The further east you go between where I am and SilverStripe's source company of the same name in New Zealand, SilverStripe adoption increases. While SilverStripe may be relatively young (it's version 2 got open sourced back around 2005-2006), it uses PHP5 and leverages some very advanced features of PHP5 to make developing for it very easy, intelligent, and flexible.

So, what are the things SilverStripe does right that I compare back to other CMS's?

An installation of SilverStripe is extremely portable between different server environments. As long as a server supports the base requirements, I can move the all the files into another webroot, enter the DB credentials (or even make the system detect what server its on and have the correct DB credentials load), run the build script through the web browser, and we're good to go. Server paths and domain names don't get stored in the database like with most other systems.
None of its configurations or settings are stored in the database. Where most CMS's make the settings available in the admin UI, SilverStripe relegates that to the code level, citing that the end maintainer doesn't ever need access to those settings.
The admin panel is for managing content ONLY. With a base installation, I get the ability to manage the site's pages, uploaded files, comments (which is getting abstracted out in a future release), and user accounts.
The amount of SQL I need to write is almost none. At most, it's little snippets of a full SQL statement but I rarely have to write a full SQL statement in the code.
Creating a new page is as simple as choosing where you want to create the new page, filling in the content, and publishing it, all in one place.
Managing pages in your site is really easy and you can see the structure of the site at a glance.
It has a very simple templating language that provides simple conditional and looping structures, template variable to output content, and a few other minor things. These template files are converted to PHP and cached and it's these cached versions that get used when a request comes in. Since the templates are parsed as PHP in the end, you can next as deep as you want and you get no performance drop since it's PHP that gets parsed in the end and you get consistent behavior.
It uses SEF URL's out of the box, period.
It uses OOP, MVC, ORM, Decorator Pattern, Singleton Pattern to name a few methods and they all play really nicely.
It's bundled with a RESTful API for easy web service and AJAX development.
It's a CMS built on top of a generic development framework called Sapphire, also produced by the SilverStripe company. This is huge and makes the CMS more easily extendable since the CMS itself is merely a module built on top of the framework. ExpressionEngine got the same right idea with its version 2.0 release.
Creating a custom page type with custom data needs is as simple as extending 2 classes and creating a template file.
The database is very intelligently laid out. It resembles a collection of PHP classes and subclasses. When you create a subclass of the ORM class, it creates a new table with columns matching the fields you define in the ORM subclass. If I subclass that subclass and add some new fields to the new subclass, a new table is created with only those new columns and the system joins the entries on the two tables as needed.
It comes with built-in image manipulation class for easy cached resizing of images and a robust form building collection for easy form building and tying into the database.
And more......

Despite all these things it does right, it does have its weak points, but they are few:

Managing the page entries is not scalable. The SiteTree that allows you to view the pages on your site resembles a folder/file structure on a computer and lazy loads the subpages as you open the "folders" which is great for static pages. When you get into blogs, forums, and anything that has new content added to it often, managing it can without a special interface (which is relatively simple to build) bogs down in the long run.
The selection of available modules is pretty slim but many have great promise and are quite good despite their early stages.
The Sapphire framework is big. Not Zend big, but I've been working on SilverStripe for a couple years now and I still find new things I didn't know about.
The documentation on the framework and CMS is not great. CodeIgniter and Wordpress both have excellent documentation. SilverStripe's needs some work. There's a lot of classes in the framework and some of them are pretty vague in their function.

Conclusion

I hope this helps you find the right CMS for you, even if it's not among the ones I talked about here. I will continue to bask in the glory of SilverStripe until... ummm... ya.

The Power of the SilverStripe Extension Class

Wed, 06 Oct 2010 18:25:18 -0500

SilverStripe has some amazing ways to add functionality to the core code without hacking it. The way they have intelligently set up the class inheritance is fantastic. MVC is pretty standard these days and shines in SilverStripe. And it also supports the the Decorator pattern.

The Decorator Pattern.

It works a little different than traditional class inheritance in PHP and more closely resembles mixins from Ruby. Basically, instead of creating a subclass that directly inherits from its parent class, a Decorator allows you to roll a bit of functionality into its own class and apply it to any number of other classes, no matter what they're ancestry is. For example, in the context of SilverStripe, I have a few different page types:

Blog Entry
Blog Holder
Portfolio Page
Photo Gallery Page
Staff Listing Page
Staff Detail Page

All of them inherit directly from Page. I want to add a slideshow to my Blog Entries, Portfolios, and Photo Galleries. I could go 1 of 3 courses:

Add the slideshow functionality to Page and it will trickle down to all its children. Problem is, I don't need the extra tab in the getCMSFields() method for the Blog Holder or the Staff pages.
I add the functionality into the code for the 3 page types I want it to show up on. But that's not very DRY. If I want to make changes to how the slideshow works, I'd have to make the changes 3 times. Maintenance nightmare.
I create a Decorator with the DataObjectDecorator and using the Object::add_extension() or DataObject::add_extension() methods (and for the record, they're both referring to the same method since DataObject inherits from Object), I apply my slideshow functionality to the 3 pages types I want.

If you've been following along, option 3 is the best answer. I'm not going to give a tutorial about how to write one as that's somewhat covered on the docs page for the DataObjectDecorator class. I'm just bringing everyone up to speed on what the Decorator pattern is.

I had never heard about the Decorator pattern until working with SilverStripe and it seemed to me to live mostly in the DataObjectDocrator class. The DOD class brings us great functionality like Hierarchy (parent-child relationships, powers the SiteTree), Versioning, Translatable pages, Static Publising, and more. However, the parent class of DOD, is the Extension class (I'd provide a link but there isn't a page for it in the SS Docs) gets far less love. I plan to change that by making Extension the celbrity it deserves to be.

A quick overview: The DataObjectDecorator class is specifically designed to Decorate DataObjects and their children. It's a subclass of Extension with special functionality tailored to DataObjects. The Extension class can be applied to any class that inherits from the Object class, which is the base class for a majority of the SilverStripe classes.

So, what can you do with this poor forgotten child called Extension?

I'm glad you asked.

Let's revisit something from the last (big) paragraph.

The Extension class can be applied to any class that inherits from the Object class, which is the base class for a majority of the SilverStripe classes.

So, how might this be useful? The Controller classes inherit from Object. The DBField classes like Text, Varchar, Int, etc all inherit from Object. The GD class which allows us to crop, pad, and resize our images inherits from Object. That means we can add functionality to all of those and more. One quick Caveat on that: you can ADD functionality in the form of new methods, but you can't overwrite existing methods on the class you're extending. Oh, and did I forget to mention you can add as many Decorators (DataObjectDecorators and Extensions) to a class as you want? Ya! Awesomeness!

Allow me to present a few examples.

Extending Controllers

Not happy with a template method on one of the Controller classes in a module? Subclass Extension, write yourself a new template method, apply the Extension, and call the new method in your template.

Let's say we have a Module_Controller class that came with a module and it has an UploadForm method that outputs a form into our template, but there's something about it we don't like, maybe an extra field we don't want to show.

class MyControllerExtension extends Extension {
    public function MyUploadForm() {

        $form = $this->owner->UploadForm();

        // Modify the form

        return $form;
    }

}

Object::add_extension('Module_Controller', 'MyControllerExtension');

<h1>$Title</h1>

$Content

$MyUploadForm

Remember, we can't overwrite the UploadForm method from the exsiting Module_Controller clas so we have to create a new method. That doesn't mean we can't take the original code and tweak it to our needs rather than copy/pasting the original method and modifying what we want to.

Extending DBFields

Just to clarify, the DBField classes are the ones like Enum, Varchar, HTMLText, etc that you declare in the $db property of your Pages and DataObjects. Early in my days with SilverStripe, I wanted to add methods to some of the DBField classes to use in my templates. That was about 2 years ago and now I know how to. One major method I wanted to add was the ability to obfuscate email addresses for Varchar fields on my Pages/DataObjects that stored email addresses. I even created and submitted a subclass of Varchar for the purpose of storing Emails and had special methods for processing email addresses in special ways. It got rejected. *sad face* So today I am happy to present to you the way to add obfuscation to Varchar for emails and a building block for extending DBFields.

class VarcharExtension extends Extension {

    public function ObfuscateEmail() {

        return Email::obfuscate($this->owner->value, 'hex');

    }

}

Object::add_extension('Varchar', 'VarcharExtension');

$Email.ObfuscateEmail

The template code will output an obfuscated email address using the Email class's built-in functionality.

Extending GD

GD is what allows us to prevent site maintainers and visitors from uploading images that break our layout. It's extremely powerful, but very simply written. The major functionality it gives us is proportional resizing, padded resizing, and cropping. So what if you want to add the ability to apply watermarks? I've seen people subclass GD and I'm not quite sure how they make the whole system use the GD subclass. Now, I can't really give an example here because, I'm not great with image editing in code using raw PHP functions and I haven't tested this theory to be absolutely sure, but in theory, you could create something like this:

class Watermark extends Extension {

    public function addWatermark() {

        $gd = $this->owner->gd;

        // Run code to apply the watermark

        return $newGD;

    }

}

Object::add_extension('GD', 'Watermark');

And in your Image subclass:

class WatermarkedImage extends Image {

    public function generateWatermarkedImage($gd) {

        return $gd->addWatermark();

    }

}

... and then refer to it in your template.

Nifty, ain't it?

So there you have some examples of what can be done with the soft-spoken parent of the DataObjectDecorator class. I hope this gets your minds going to come up with some awesome ideas and save you from hacking the core or subclassing when you don't need to.