Caloris is a file-based Content Management System back-end built as a Rails 3.1 Engine.
Etymology: The Caloris Basin, an impact crater on the planet Mercury, is one of the largest in the solar system. Hopefully, Caloris will make a significant impact on the Mercury Editor project.
By using the file system for storage instead of a database, content can be easily managed with standard text editors, while the Mercury Editor front-end can be used by non-technical staff. Version control can be leveraged, as with source code, to handle deployments of site content and history.
A CMS for Rails should:
- Be an Engine, so that you do not have to build your app around it, nor change the way your app works
- Be simple until a more complex site warrants something different
- Leverage what is already used or known, i.e. git for version control
- Be easy for non-technical users, while not being cumbersome for the technical
Mainly inspired by the Mercury Editor.
The author was discouraged buy a high complexity-to-performance ratio of available Rails CMS approaches. Mercury Editor has a great philosophy: provide a great WYSIWYG front-end rather than to create an end-to-end solution that might not be useful in all cases. Caloris is attempt to take over where Mercury leaves off to provide a solid back-end that will meet many needs without being overly complex nor limiting.
Components of a full-blown CMS might be:
- Front-end, Mercury Editor
- Back-end, Caloris
- Managed content, version-controlled with git
Most development has focused on the use of git for page storage, but the design should allow for other methods, such as database-backed stores.
The git layer sits on top of a file-system-based layer, adding branch, revision, and low-level commit functionality. The design assumes that a Rails app would point to a repo on the local file-system. To support multiple concurrent users, sessions are able to select a branch for browsing and editing. Commits are made directly to those branches without affecting the mater branch or HEAD, using low-level creation and manipulation of git blobs and trees. The Mercury Editor Version interface (rebranded as Branches and Revisions) allows browsing of any revision in any branch using the dialogs opened via the toolbar.
General content requests are served directly from the git repository, in general from the master branch. It is possible to instead serve content from a different reference -- currently only when editing content, by supplying a query parameter to the URL. This way a link to a provisional page could be passed to a colleague for review at any point in the design cycle. It would also be quite simple to provide a mechanism whereby general content requests use a different reference with a small modification.
It is assumed a web content manager would want to review any "pull requests" from branches before moving into a production branch. Deployment involves merging commits into, and advancing, the master branch.
TODO: Implement an index of all differing pages for review, and a graphical change-view per page. This change-view could conceivably render another iframe and provide a toggle button in the toolbar to switch between the current master revision and that in the selected branch. The change index could maintain state so that reviewed pages could be checked off after review, or more complicated state machine to allow for compliance or other audit workflows.
For an example application, check out test/test_app.
Inpired and made possible by Mercury Editor.
Distributed under the MIT License, copyright (c) 2012 PENSCO LLC.