The stomping ground of Jeff Whitfield, developer of cutting-edge, modern websites.
In my last post, I talked about a few problems I have with MODX. In this post, I’m going to introduce a CMS called SilverStripe that I believe can help address some of the problems that developers might have with MODX.
SilverStripe is a content management system developed by SilverStripe Limited, a web development company that has been around since 2000. The CMS originally started as a proprietary system but, with the 2.0 version, the company decided to release it as open source in 2007. Since then, a 3.0 version was released in 2012 with some very welcomed changes. I appreciate the fact that the SilverStripe is a web development company because it means that, through the use of their own system with client sites, they can review how clients use the system and improve useability.
SilverStripe is more of a framework than a CMS. The core of SilverStripe is a framework known as Sapphire, which can be used much in the same vein as other PHP frameworks like CodeIgniter and FuelPHP, allowing applications to be built using no CMS at all. In fact, the CMS portion and every other addon to SilverStripe are nothing more than modules added onto the framework, which lends itself to being highly extensible.
Everything in the framework follows a heavy MVC model. When I showed this system to a seasoned Rails developer, he looked at it and said, “That’s Ruby on Rails!”. Yes, Rails developers will be pleased to find that there are similarities between Ruby on Rails and SilverStripe.
Easy Data Modeling
When I sit down to start developing a site, the first thing I do is try to get a handle on how the information is structured and how it might be managed. Not only does SilverStripe make this easy but the database itself will reflect your data model to the letter.
Both the model and controller classes are handled in a way that makes it easy to extend any PHP class in the system however you’d like. The two main classes that you’re most likely to use in the system are the DataObject and Page classes. The DataObject class is the default class that is used to manage every data model in the system. In fact, the Page class is just an extension of the DataObject class. For every class you create, you’ll likely extend off of either the DataObject or Page class depending on how you’ll use the data.
Every class you create can have its own set of relationships with other classes: one to many, many to one, many to many, you name it. Within any class you can easily filter and return whatever information you want. In most cases you don’t have to write a lot of code because the management of relationships is handle automatically for you. The best part of this is that the classes of information you create in the system are reflected in the database in a normalized manner. Any DataObject classes you create will have a table with the same name in the database with index tables created for many to many relationships. It’s as simple as that. No ambiguity between your model and how it’s stored.
And here’s the kicker: SilverStripe manages the database for you! With a simple URL command, any changes you make to your data model will be reflected in the database automatically. The neat part of this is that it’s done in a non-destructive way. If you decide to add, edit, or delete a field name or table, SilverStripe will update the database in a way so that none of your data gets destroyed. You might need to go in and do some maintenance to the database away from SilverStripe but, aside from that, SilverStripe does its best not to do anything destructive to your data.
Quick Interfaces Using Scaffolding
Models are handled in a way that is not only easy but allows for quick scaffolding for easy management of the data from within the SilverStripe administration UI. This is the part that completely blew me away. I was amazed at the fact that I can give SilverStripe a model and, with a few lines of code, can have a complete way to administrate all the information from within the UI. Even complex data models can be scaffolded quite easily! Amazing stuff!
Just like MODX components, you can create stand-alone areas of the CMS for managing data. However, unlike MODX, the management of information from within pages is not only easier but is managed in a way that accurately reflects your data model.
For instance, as mentioned in my previous post, imagine you have a Staff model that is attached to a specific Staff page. In SilverStripe, this is as easy as creating a StaffHolder page that has a one-to-many relationship with a Staff model. Whenever you set a page with the StaffHolder template, SilverStripe will automatically create an extra tab called Staff where you can easily add individual records for each staff member. This information can then be easily parsed and used from anywhere on the site.
While this is a simple example, you can create even more complex relationships with your data and implement them in a way that makes it easy for your clients to manage the information within the UI. Not only does this empower your client with the ability to manage their data more effectively, it can be done very easily with not a lot of code and/or knowledge. All it requires is solid knowledge about PHP classes.
Just like MODX and Rails, management of templates and views is easy. The management of views are very similar to how Rails works in that each view reflects the class that is responsible for the view. Simple placeholders are used for information like the title, content, and other data related to each page or dataset. Logic can be added to a view to help facilitate things like if statements, loops, menus, and other bits of logic.
Unlike MODX though, you can’t manage your views from within the CMS. All view files are managed on the file system using various files with a .SS extension. In fact, all files related to the programming of a site are managed on the file system. The only thing that is managed using a database and the UI is the content itself. Upside of this is that all view, classes, and other files can easily be managed with a versioning system like SVN or Git.
Good Documentation, Great Community
When I first started to dive into SilverStripe, I picked up their book SilverStripe: The Complete Guide to CMS Development. Granted, this is an old book. It was written in 2009 and covers an older 2.3 version of SilverStripe. Even then, you can still learn a lot about the philosophy of SilverStripe as well as the basics of how the system works. Through the use of a step-by-step tutorial format, you can quickly get a good understanding of how data modeling, scaffolding, objects, and templates work, all the fundamentals required to build great websites. Still, it would be nice to see a second edition of the book that covers the new 3.0 version and goes farther in the exploration of the system.
But what truly makes SilverStripe great is the community. Like MODX, SilverStripe has a vibrant community of talented developers contributing to the project and writing all kinds of modules to extend the system in infinite ways. A short visit to GitHub will show you an extensive list of SilverStripe related resources.
From Amazing to Awesome
To give you a taste of just how awesome SilverStripe can be, take some time to visit the SilverSmith project. This addon by Aaron Carlino (AKA UncleCheese) for SilverStripe allows you to quickly and easily write tons of code with just one command. In fact, just watch the videos about the SilverSmith SLI and the links off the SilverSmith project site. My jaw literally dropped! Imagine scaffolding your entire site with just a YAML file and a text file. It basically allows you to do what would take you a few hours to do and do it in just 30 minutes. Insane!
While the CLI is in alpha, the best is yet to come. Aaron has plans of building a native Mac app that allows for visually building your initial data model as well as adding the ability to use plugins for direct integration of other SilverStripe modules. I can’t wait!
So, there you have it! A fairly decent review of SilverStripe and it’s benefits. Is it a full replacement for MODX? Maybe. Is it perfect? No. There are definitely some areas that could use improvement. But, even then, it’s still a great system and very useable in a production environment. Try it and decide for yourself. For Rails developers looking for a solid solution with PHP, SilverStripe might just be the ticket! :)
Those who know me know that I’ve been a long time MODX supporter. Hell, I was there from the beginning when the project was forked from Etomite. Since then, I had the pleasure of working for the folks who founded the project for the better part of four years. Eventually, MODX went LLC and was on its way to becoming a full fledged open-source startup. But after four years, I realized it was time to move on, to learn some new things, challenge myself, and expand my career.
Part of that process included learning new tools and new languages. I started looking at Ruby on Rails and, after a brief review, was shocked at how easy it was to create custom data models and do stuff with it. While most Rails developers say that scaffolding isn’t the best thing to do, it’s still amazing at just how easy it is to get up and running with a fairly complex data model. So it begged the question: Why can’t we do this with MODX?
MODX has always been about creative freedom. It still remains one of the best CMS platforms out there for web designers. With a little knowledge of how MODX works, a web designer can build a site with complete creative freedom with little or no PHP knowledge. Not only that, but they have access to a ton of addons that allow for quickly developing custom solutions for clients. That’s huge!
I’ve used MODX for close to five years now. As with any platform, there are limitations to what you can and cannot do. While MODX is a fantastic tool for non-developers, it can be challenging to a PHP developer. For those seeking a solid solution that adheres to a strict MVC philosophy and proper data modeling techniques, you might find yourself scratching your head now and then.
Compared to the first version, MODX Revolution gave way to a whole new way of handling the data model in MODX. The introduction of xPDO allowed for treating data in a more object-oriented fashion using schemas to create custom data models. xPDO is some seriously powerful stuff! You can realistically create some crazy powerful custom applications in MODX!
The problem is that, while xPDO is powerful, the MODX data model doesn’t line up with it all that well. The data model built for MODX isn’t normalized in a way that makes sense for integration with a custom data model. In fact, the data model MODX is based on is, in my opinion, seriously flawed.
For instance, let’s say that you wanted to create a Staff page that listed multiple members of a company in a way that’s easy for the client to manage. In this case, the company doesn’t want each staff member to have their own pages but would like to relate each staff member with blog posts, project pages, and other related content. The client wants to manage this using an interface that allows them to easily add staff members, filter the list, and export a list every once in a while.
In this case, a third-party component would need to be created. Seems like a pretty simple task. Now, while the data model for the Staff component can be created fairly easily, creating the interface for it and relating it to content in the Resource Tree within MODX can be a bit daunting. Aside from that, you still have to find an easy way to relate each staff member with various other resources on the site.
1. Inconsistent Data Models
While we can build a custom data model that is normalized and makes sense, the way data is stored and related for resources isn’t exactly normalized in an obvious way. Resources are broken down by the template they use, the template variable values, and which template variable template each of them use, all stored into different tables. In other words, all content is stored in the same content table, all template variable values are stored in another table, with the template variable type stored in yet another table. This means that a complex lookup of any content and their related template variable values and data types requires parsing a lot of data before generating a result which, from my experience, has always been a problem with how MODX works.
The problem lies in the fact that the MODX data model is not going to reflect the way the information on your site is structured. As such, trying to relate the content and template variable data with your custom data model is going to be tough and somewhat inefficient. While relating a single resource with multiple records in a custom data model is a no-brainer, going the other way around isn’t. Even without a custom data model in the mix, parsing multiple resources in the Resource Tree with template variable values and complex content requirements can be difficult without having to write a lot of custom code. Unlike a custom data model using xPDO, it’s difficult to create relationships between resources using nothing but the Resource Tree and template variables.
2. Lack of Scaffolding
In my opinion, regardless of how experienced you are, adding a custom component or manager page in MODX is not easy. A simple interface to manage a data model can’t be this difficult to create, right? Reviewing the documentation on how to do it is enough to make a modest PHP developer cringe. Unlike Ruby on Rails, getting an interface to manage a custom data model requires a lot of steps. There are MODX manager configuration steps to make, lexicon files, controller files, ExtJS files, and more. Unless you understand how ExtJS works then creating custom manager pages is just painful. This is by far the one area in MODX that I’ve always hated. Just never could learn how to do it without pulling my hair out.
While xPDO is certainly powerful, it still lacks any cohesion with MODX and feels like a separate component. Multiple steps are required to create a custom data model, including the creation of a schema file written in XML. The requirement for the schema are pretty straight-forward and easy but it does take a bit of time to create it. On the flipside, making use of the schema and generating your PHP classes and maps does require you to create a PHP file to generate your model. On the surface, this seems pretty easy but, when you factor in updates to the model after creation, the generator required quickly becomes a problem. Documentation on generating and updating an xPDO model is skimpy at best. Which brings me to my final point.
3. Lack of Documentation
In the past, whenever I’ve introduced MODX to a fairly seasoned PHP developer, many get excited but point out the lack of proper documentation. Not that there isn’t documentation. While there’s plenty of it, there are also holes in the documentation. You can get pretty far with the current documentation but, after a while, you start running into walls. I hit plenty of walls when it came to xPDO and custom manager pages. There just didn’t seem to be any way of cohesion between these two topics.
While it appears that the documentation is being updated all the time, many entries appear stale and haven’t been updated in some time. With the sheer amount of documentation that’s been added, I would imagine that keeping it updated is a task in itself. To make up for this, plenty of MODX fans have stepped up to the plate to offer all sorts of tutorials and other resources.
I would presume that one saving grace in documentation for MODX would be the MODX: The Official Guide book. From the table of contents, it looks well organized and covers a lot of ground. Someone looking to get into developing with MODX would likely want to read it. Unfortunately, it was written in 2011, is 772 pages long, costs $59, and weighs over 3 pounds. Being an older book isn’t necessarily bad and is still likely useful. The problem is that, to date, there still isn’t a digital version of it available. Many people, including myself, own iPads, Kindle Fires, and Android tablets. We don’t want to lug around a brick of a book. As such, many potential MODX users likely won’t buy it. MODX desperately needs an updated edition of their guide and one that comes in standard digital formats.
To be clear, I still think MODX is a great CMS. However, I do feel that it could be better. I’m sure the MODX guys have a lot in store for the 3.0 version. In the meantime, improving documentation and getting a better edition of their book would be a good step in the right direction.
I kept mentioning Ruby on Rails in this post. Granted, Rails isn’t a CMS and comparing MODX to it isn’t fair. However, I recently started using another PHP based CMS for client websites, one that shares many similarities to Ruby on Rails like scaffolding and normalized data models. It’s a system that will make Rails users smile and MODX users cry. I’ll talk about it in my next post.