There are several incremental steps that we should take to make our online template management better.

  1. (DONE) Incorporate a better code editor, such as Editarea http://www.cdolivet.com/index.php?page=editArea&sess;=ca31d50658ccc652b57d11956a36d9fb (#2805)
  2. Provide date stamp next to each template (last uploaded/modified/author)
  3. Provide log info for each template (excerpt from the log related to each individual template), in a nice YUI slideout or whatever they are called.
  4. Template versioning (either SVN-based as described in #2556, or maybe consider Git http://git-scm.com/ ; another potentially useful link is http://blog.endpoint.com/2009/02/git-it-in-your-head.html )
  5. Make a more intuitive navigation (revise breadcrumbs first, so they are useful in navigating multiple templates)
  6. Create a “template map” feature, e.g. xyz.tpl includes templates template1.tpl, template2.tpl, templateN.tpl
  7. Come up with a way to keep better track of the CSS entities used (preventing duplicates, mapping out includes)
  8. Standardize around the 960 grid system to create common template elements (snippets) that can be more easily reused across sites

micz’s brief review of the campsite templating issue

campsite (like typo3) allows full control over the templating structure. different from other cms solutions (like drupal, wordpress and joomla) the naming and architecture of template files does not follow any conventions. the campsite approach is deliberating, because you can do what you want and the way you work. you can build custom html and css and use it any way you like. yet, in order to make it easier for new designers or webmasters to come on board, a “gentlemen’s agreement” on how to structure and name your files and folders would be very helpful. along the same line, the possibility to develop and manage themes in an easy way, would improve implementation with campsite massively.

at the same time, the template building in campsite can be enhanced. but let’s go through some suggestions for naming and ordering first.

naming and structuring of templates

the following suggestions are not enforced by the system at this moment (version 3.3.5). they might be in a more developed form in future releases – if they turn out to make sense in practical use. at this moment they should be seen as a clean up plan.

i suggest that inside the templates folder, each publication should have a folder with the publicationname. inside this folder only .tpl files for issue, section and article are placed. inside this folder a number of other folders are placed to be called from the main templates via include. these folders are:

templates/publicationname            -> main folder with the main .tpl files
templates/publicationname/_tpl       -> folder with snippets which are called via include
templates/publicationname/_img       -> images which are independent from the css, like logo or advertisments
templates/publicationname/_js        -> javascript files
templates/publicationname/_css       -> main folder for css skins (e.g. green)
templates/publicationname/_css/green -> the set of css files and images for the classic skin 'green'
templates/publicationname/_misc      -> other files (e.g. flash players, banners, etc.)

the leading underscore of these folders will be helpful at a later stage when displaying the available templates in the three template selection dropdowns (Front Page Template, Section Template, Article Template) on the Change Issue Details or Change Section Details screen. here it would be easy to exclude .tpl files with /_ in their path. this idea is similar to the .foldername in linux which is being excluded from normal listings.

template sets and themes in campsite

because campsite is so flexible, you can’t predict the publication structure a user will build with this system. the opposite is the case for e.g. wordpress. building a skin for wordpress is easy to control, because you know what the system spits out. with campsite, you can set article types, sections, issues and so forth.

in order to make it possible to discuss the issue of better template management, i want to suggest the following distinction:

  • template set: a template set contains of all the .tpl files necessary to create the needed functionality of a publication.
  • template theme: a template theme contains all the .css files to create the look and feel of a publication.

this distinction is necessary, because the template set of a multilingual daily newspaper will look very different than the template set of a blog like thread. also comments will be used or not, polls included or not and so on. once the template set has been developed, it can be themed with the css files.