I'm building a content management system, and need advice on which theming structure should I adopt. A few options (This is not a complete list):

  1. Wordpress style:

    • the controller decides what template to load based on the user request, like: home page / article archive / single article page etc.
    • each of these templates are unrelated to other templates, and must exist within the theme
    • the theme developer decides if (s)he want to use inner-templates (like "sidebar", "sidebar item"), and includes them manually where (s)he thinks are needed.
  2. Drupal style:

    • the controller gives control to the theme developer only to inner-templates; if they don't exist it falls back internally to some default templates (I find this very restrictive)
  3. Funky style:

    • the controller only loads a "index.php" template and provides the theme developer conditional tags, which he can use to include inner-templates if (s)he wants.

Among these styles, or others what style of template system allows for fast development and a more concise design and implementation.

  • 2
    one of the most important things, yes. – Alex Feb 17 '12 at 20:23
  • 1
    In the existing systems, what do you think slows down template development? – FrustratedWithFormsDesigner Feb 17 '12 at 20:28
  • 5
    ...but you are building a new system and the most important aspect is something you have no way of comparing to existing products? – FrustratedWithFormsDesigner Feb 17 '12 at 20:30
  • 6
    I would spend at least a day investigating what CMS systems can be downloaded and customized to what you want, chances are extremely good you can save tons of money and time doing this. – Ryathal Feb 17 '12 at 21:14
  • 1
    In WordPress you need just the index.php template (and maybe the comments.php, everything else is optional. So WP is actually 3. too. – fuxia Apr 7 '12 at 15:36

How about selecting a PHP Development framework like Symfony 2 (http://symfony.com) or Zend Framework (http://zendframework.com) which have pre-build templating systems and you reuse those.

BTW Drupal is currently moving part of its core framework components to Symfony 2 so you may want to take a look at it.


You might classify this as either an example of your "Funky" style or as a discrete fourth style:

4. Smarty style:

  • Include plain-text markers (usually delimited by curly braces) for replaceable items in the template; interpret the entire template at run time, replacing markers with content. The process aims to be more designer friendly since programming constructs are not directly embedded. Whether you use Python or PHP or other server language, you'll parse and replace the placeholders the same way, so the template is relatively benign and reusable in that sense. Conversely, you generally give up being able to pass parameters to embedded functions.

However, you've asked a deeper question that I've also had to wrestle with, and have thoughts to offer: "What style of template system allows for fast development and a more concise design and implementation."

Since your are developing your own CMS, you have the freedom to define your own interfaces to the template system rather than adapting your interfaces to an existing system. You might consider:

  1. Do you want to provide an API to other systems that will bypass your templates? In this case, at the point where you would ordinarily call your template, all of your content needs to be available as fully resolved endpoints for the remote API requests. As a result, your templates will generally be executable HTML files with variable calls that instance that same content into the appropriate places in the template.

    Most API-driven applications will request the main content (title, author, body, page meta) but typically not the same inner-template parts like the sidebar or footer widgets as the web-based user experience. This is a good design approach for any CMS that provides fairly narrative or static content--that is, the content area of the web page can be easily pre-built as a chunk of content prior to being instanced into the template or sent as an API response. Templated content of this form tends to use category names as the labels for the primary tabs, since the main role of the web interface is to provide hierarchical drill-down into rich CMS content (encyclopedic or reading-oriented sites for example). The single index is fine in this case because there is no functional change from view to view, just content updates. Lends itself to front-controller type routing that ties into the content categories/hierarchies.

  2. Does the CMS provide more of an application-based behavior? If the top-level navigation is instead switching from home page to forum to blog to admin, etc., then the "content" is probably very different in each template, and probably a series of functions/queries with headings rather than static content.

    Here, you may either have a separate template wrapping each distinctive type of main content (forum vs blog vs static home page), or a single template with a function in the body that switches the instanced content. Either way, you can still serve that content as endpoints for API requests. This general CMS approach lends itself to page-controller type routing if using separate, type-dependent page templates, particularly if the template shell itself may need to be somewhat different for each content type. On the other hand, if you can implement the content switching via the single embedded function (which may need to control sidebar content if it contains context-dependent widgets), then you can still use the single index template approach which will give you more consistent look and feel experience for users. Either page controller or front controller routing can provide the resolution for that content switching--you are just using a common template with a parameterized content switch instead of a parameterized page with its own fixed content type.

If you can make a clean interface between the content that the CMS prepares in response to a query and the template system (or API call) that uses it, then you will have an additional advantage: By simply changing the name of the template directory, your same-named templates in the new directory will render the same content nearly equivalently. I think this is the single most important payoff of designing that content:template:api interface clearly--you end up with a richer outer template environment like Wordpress enjoys, your context-dependent regions like the sidebar and the footer can make use of inner templates for instancing content into the outer template like Drupal, and you can define the replacement mechanism as either a programming call or a parsed locator as your application requires. I'm able to take any free or commercial template and retrofit it with my CMS interfaces in fairly short order to support very different thematic styles. Most of the work ends up defining separate views between different themes that have their own inner styles for non-primary content (such as sidebar widgets or for the lists/tables used to represent collections; the main content usually just pours into its reserved area without intermediate processing).

Hoping this make sense for the CMS you are designing!

  • 1
    @downvoter: when it's not clear why the answer is bad, it's welcome to have some feedback about the reason of the downvote. It will help the author of the answer to improve it, and to other people to know what's wrong. – Arseni Mourzenko Mar 4 '13 at 17:20
  • Yes, I would appreciate commentary. This is my experience in developing a robust template system for my sites. Is there not something to be learned from my experience? – Don Day Mar 4 '13 at 20:15

In almost ten years of PHP, I haven't found a single advantage in any template engine I've worked with over the "WordPress" style.

Allowing the controller to determine which templates are referenced, and allowing the view to directly reference sub-templates, is direct, concise, and maintainable.

The only secondary suggestion I have is that the developer should be able to specify the theme that the template originates from in some sort of general config. This prevents the developer from having to globally find/replace the theme name in the controllers and subtemplate references.

Not the answer you're looking for? Browse other questions tagged or ask your own question.