[LRUG] Though on CMSs

Matthew O'Riordan matthew.oriordan at gmail.com
Fri Nov 7 02:39:17 PST 2014


Hi all

Slow to reply, but I have been interested to see what people had to say about this.

In my former Microsoft life (hell), for around 7 years I was largely implementing CMS systems.  They were mostly .NET based at the time because of our technology stack, but they were certainly not exclusively so we worked with some PHP, Java and a weird XML/XSLT only system at one point.  What I did learn whilst working with those CMS systems is that you will be surprised at how much functionality they will pack in to cater to a wide variety of content management requirements.  From experience, trying to grow your own CMS solution, or use any of the Rails CMS systems that exist (I looked into them all around 9 months ago), will be incredibly limiting.

Unfortunately, I have not to date found a Rails / Ruby CMS system that goes beyond very simple content editing and publishing requirements.  When we used to scope out which CMS we would recommend to a client, you would inevitably look at their requirements and find a CMS that matches on features and budget.  I suspect that if you did this now against some of the Rails CMS systems, you may find a reasonable match of features to requirements.  But I can assure you that any business that grows and has more people editing the website content will very soon need and expect the following:
Staging sites i.e. ability to publish content to a staging server, preview it all, and then publish the whole set of changes in one go to the production server.  This is not needed generally when you are editing single pages, but when you need to roll out a big change in one push, it becomes incredibly difficult with most simple CMS systems as they don’t have any concept of content packages that can be deployed.
Multi-lingual support - this is a mine field, to effectively have multi-lingual support (even if just to support American locales where relevant), you need work flow support so that when an article is published in British English, an editor is alerted that they must publish an American equivalent.  They should then have a section where they can see their backlog, and get localising.  When you move to other languages, you really need visual diff tools so that when the source page changes, the editor downstream for their locale, can see only the changes and make those changes to their version as well.  Without this, it is near on impossible for editors to efficiently roll out localisation changes to existing content.
WYSIWYG editing from within the web front end itself - whilst lots of editors may prefer the more hardcore admin interface, from experience a lot of other people prefer to simply log into the website, go to the page on the front end website they want to edit, hit edit, and then edit that content in-line so that a) they know how to find the content, b) they can see how the changes affect the website with the actual layout.
Workflow - as soon as you have more than a few people working on the site, it is common for one or two people to want to sign off on new content or changes.  Once again, all the features listed for multi-lingual support come into play with the need to review versions, visual diffs, support for pseudo state machine so that article changes can be rejected etc.  Added to this, all of these workflows need to be customisable because clients have different processes.  Finally, you will probably need permissions so that the junior who just started and looks after news updates can’t touch the corporate investor area.
Data and content - typically when most people think of a CMS they think of articles, blog posts, page content.  However, any decent CMS will go far beyond that and support rich data structures that are treated as content items.  Think Rails models, but they are set up within the CMS, and can be managed entirely within the CMS back end based on the meta data about the fields that dictate how the admin interface should work.  And then of course you will find there are exceptions were you need custom components within the admin interface, so you expect support for that from your CMS.  If a CMS does not support flexible data types so that you can treat typical Rails models as content, then you will always struggle with the constant cross over between your custom admin section and the CMS admin sections to manage content, because often the models (such as products) really should be teated as content.
Asset management - having a simple list of files very soon becomes unmanageable, editors will very soon expect to be able to file assets into folders, and perform basic image manipulation such as cropping and resizing.  Again, a workflow may be required for this.
Dynamic content - such as serving up different content based on a publishing schedule, the locale or locality of the user, based on user behaviour, user permissions, device of the visitor or content type requested.

Now all of the above is incredibly boring, I know, I implemented those systems for a long time.  I have one piece of advice, if your clients need a CMS that they will use into the foreseeable future, please don’t try and build a CMS or use one of the flimsy Rails solutions out there.  There are plenty of sophisticated open source CMS products out there (not Wordpress, it’s a pile of rubbish) that have APIs you can work with and will genuinely provide most of what your clients need out of the box.  If you want to work on a Rails stack then, simply use the API to pull content form the CMS and present it where necessary, or alternatively build your Rails app as an API and let the CMS communicate with your Rails app. 

I sound like a Rails hater, but that is not the case.  I am a CMS hater, and would hate to have to work with CMS products ever again because they are unwieldy, enterprise-y, and just not fun.  However, if I found myself once again exchanging my time for money for a client, and they needed a true CMS, I’d either turn the project down because I am not interested in providing a CMS solution, or I would provide the best solution that a client could get and give them what they need, an off-the-shelf CMS product.  I realise that doesn’t apply to every person who needs to edit content, but I urge you to think carefully about what features a client may need now, and will most likely need in the future as well, and make sure you’re not leading your client into a corner where they’re paid you to implement a solution that won’t scale to meet their CMS demands in the future.

PS. Take a look at https://prismic.io/ <https://prismic.io/>, it’s an interesting idea and looks good, although I have never implemented it.  It may be a good solution for people who need lots of content managed by editors and don’t want to do the boring bits of either building or implementing their own CMS system.

Regards,

Matthew O'Riordan

> On 3 Nov 2014, at 20:40, Ed Lepedus <ed.lepedus at googlemail.com> wrote:
> 
> Evening LRUG,
> 
> As the title suggests, I was wondering what your thoughts were regarding CMSs, and on content management strategies in general. Having spent some time with Wordpress and Drupal in the past, I find myself somewhat prejudiced against them. 
> 
> However, if you have a site, you must have some system for managing its content, so it becomes a debate about using existing solutions vs rolling your own. The main things I'd like to know are:
> 
> Do you use a CMS? 
> Is it custom built or off-the-shelf?
> Do you use the same CMS for many projects, or are they project-specific?
> If you do use publicly-available CMSs, which ones, and would you recommend them?
> Any other comments/experiences etc
> Thanks,
> Ed Lepedus
> 
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20141107/fbdfb8c1/attachment-0003.html>


More information about the Chat mailing list