Static content lives in no-man’s land. Marketers and site owners want to change copy at a moment’s notice, but giving them access to the source code or relying on a developer to update and deploy is fraught. Content management systems (CMSs) are the ideal platform for copy editors, but how do you effectively integrate CMS pages into a Rails application without duplicating logic across the Rails app and the CMS platform? I have come to favor one of two approaches, each involving the usage of a CMS.

Using WordPress for Content Pages

On some projects where there is a clear differentiation between the content-heavy public site and the application-centric logged-in site, I set up a WordPress app for the public site. The theory behind this separation is that there is no better platform out there for building a [more-or-less] static website {opinion}. I approach this separation knowing full well that the WordPress layout will be different in form and function from the Rails application layout. Colors, styles, and overall look and feel will be consistent, but headers, footers, logo placement, etc. has the freedom to best meet the needs of the role each app is playing. (Example: play around on mint.com’s public pages and then log into the site to see who vastly different the two experiences are.)

The WordPress app lives on a totally different server and assumes the default domain (eg. example.com or www.example.com). The Rails app lives at a logical subdomain, which begins with the sign-in/registration pages (eg. https://app.example.com/signin). To keep the deployment process simple, we typically leverage WordPress-specific hosting platforms such as WP Engine.

Using a Rails CMS for Content Pages

Now that Rails Engines are full-fledge citizens, there is an opportunity to leverage feature-rich CMSs in a new or existing Rails app without much of a struggle. At present, there are two Rails Engine-based CMSs that are worth considering: Refinery and Comfortable Mexican Sofa (note the CMS acronym of the latter ;-). I have used both and have an opinion on which one I recommend.

Refinery is maturing quickly and becoming a favorite of the Rails community. It is feature rich and is definitely a contender for becoming the de facto CMS for Rails apps that need a heavy-weight solution. Ironically, this is the exact reason I am not as attracted to Refinery. If I want a CMS that is trying to compete with WordPress in capabilities, then I am going to use WordPress. I can imagine one of the site owners wanting to add plugins or features that are commonplace in WordPress, but that would require custom implementation in Refinery.

If I’m not going to use WordPress, it’s because I want something more tactical and light-weight. Enter Comfortable Mexican Sofa. I have fallen in love with the ease of use, flexibility and out-of-the-way nature of CMS. If you are used to having some kind of static controller in your Rails apps to serve static/content pages, you’ll love the ability to continue to use the static controller, yet easily delegate to CMS when a static page doesn’t exist. (CMS will rescue from a template not found error and attempt to serve a CMS page matching the request).

CMS also allows the developer to explicitly render a CMS page directly from within any controller in the application. Suppose you had a controller that served up a gallery of pictures from a user’s account. If the user’s gallery did not have any pictures, the controller could be configured to render CMS page instead. This would allow an admin or copy editor to constantly change the content of the “empty gallery” page without changes to the codebase.

Another developer-friendly feature of CMS is the ability to inherit from the application’s layouts. In the simplest scenario, you need a CMS page, but the layout should exactly match the application layout. Easy-peasy. Just state that the layout should inherit from application.html.erb. If you have commonality between your CMS pages and your Rails app, but UI aspects such as navs and footers are different, you can nest your Rails layouts appropriately and inherit from the appropriate Rails layout inside of CMS.

What About Copycopter?

Copycopter is a neat service provided by Thoughtbot. Copycopter allows copy editors to edit snippets of code on the page via a web application owned and operated by Thoughtbot. In a nutshell, all I18N copy gets pushed to Copycopter where a copy editor can change the copy of any of the registered snippets. The drawback is that Copycopter becomes the source of truth for your application’s content (or at least the portion that resides in the snippets that CC is maintaining). This could present a concern to app owners and could have implications if the Copycopter service (either the admin console or the service provding the current content) became unreachable to your application.

Mexican Sofa to the rescue, again. CMS provides a handy feature called snippets. There is a DSL for using snippets directly in your CMS pages using a curly brace notation (eg. {{ cms:snippet:copyright }}). There is also a powerful feature that allows developers to use CMS snippets in any template or layout (eg. cms_snippet_content(:copyright). Using the same example from above where a user does not have any pictures in a gallery, rather than using an entire CMS page, the developer could wrap the message in a snippet. This would keep the bulk of the logic in the Rails app and give the copy editor just the right amount of flexibility to customize the message.

And the Winner Is?

If the project calls for a highly customizable CMS, I recommend delegating to WordPress, in all it’s PHP glory. If, on the other hand, you need a more tactical approach, using either fully-driven CMS pages or small-to-complex snippets, Comfortable Mexican Sofa offers the perfect blend of features, customization and libery without getting in your way. Huge props to the folks at TWG for open sourcing CMS!