Storing editable site content?

Question

We have a Django-based website for which we wanted to make some of the content (text, and business logic such as pricing plans) easily editable in-house, and so we decided to store it outside the codebase. Usually the reason is one of the following:

• It's something that non-technical people want to edit. One example is copywriting for a website - the programmers prepare a template with text that defaults to "Lorem ipsum...", and the real content is inserted later to the database.

• It's something that we want to be able to change quickly, without the need to deploy new code (which we currently do twice a week). An example would be features currently available to the customers at different tiers of pricing. Instead of hardcoding these, we read them from database.

The described solution is flexible but there are some reasons why I don't like it.

• Because the content has to be read from the database, there is a performance overhead.

  We mitigate that by using a caching scheme, but this also adds some complexity to the system.

• Developers who run the code locally see the system in a significantly different state compared to how it runs on production. Automated tests also exercise the system in a different state. Situations like testing new features on a staging server also get trickier - if the staging server doesn't have a recent copy of the database, it can be unexpectedly different from production.

  We could mitigate that by committing the new state to the repository occasionally (e.g. by adding data migrations), but it seems like a wrong approach. Is it?

Any ideas how best to solve these problems? Is there a better approach for handling the content that I'm overlooking?

Answer 1

You should think about editable content as a full feature.

• Some added complexity is obviously needed. Maybe you could store the static resource after editing in order to avoid performance harm.
• Content is data, so it's part of system state. Developers must deal with it thinking users can do pretty much everything your UI allows them to.
• If automated tests rely on database state, the tests must also set database state (TestDataBuilders, fixtures...) before running, or make them unit tests (maybe through mocking).

But, instead of making content editable, you could make that technical people part of your development flow. Instead of develop --> deploy --> alter data, you could do alter data --> develop --> deploy. Maybe you could borrow some ideas from static blogging platforms like Octopress.

Answer 2

This is a good task for your DevOps. :) You can do the following:

1. Put editable resources in separate artifact/VCS repository (I'll use Git terminology here).
2. Implement your build and deployment process so that these resources will be simply pulled from that repository to separate location on server (you can establish some convention for different environments so you will not need to configure this location separately for each one).
3. When user changes something on the web site, the change is simply saved to resource file. Push to remote repository is executed asynchronously on each change.
4. To deploy any changes, developer disables the editing functionality and merges his changes into remote repository. Then, on production, he pulls the merged files from remote repo. After that, editing functionality can be re-enabled.

It's possible to automate everything except the merge with Chef or any other tool, so this solution can be comfortable both for users, developers and SQA.

Answer 3

Any ideas how best to solve these problems?

We had the very same situation. We ended up using the following Django apps:

• I18N flavor of flatpages
• with the Redactor WYSIWYG editor enabled.

It's not perfect, but it gives you all you need:

• non-technical people can edit,
• no code deployment needed.
• If you need version control, the reversion app will give you just that.

To have developers experience the same pages as on the production system, if that's an actual requirement, export from production to development and test by using fixtures.

Is there a better approach for handling the content that I'm overlooking?

Conceptually, I think you are on the right track. Ask yourself if you need to implement your own solution, or if you can live with some sort of CMS. Flatpages is one very simple version of that. More sophisticated CMS are available.