CMS Made Simple Forums

I started using CMS Made Simple in 2006 and I can remember when the decision was made to move the templates from flat files into the DB. At the time it didn't seem like that big of a deal and in fact was probably the right decision given the mission of the project which was to make a simple cms that was accessible to a wide range of users.

In a lot of ways CMSMS was ahead of it's time. From the beginning the platform implemented OOP and auto loading which was a sharp contrast from the procedural PHP code that was being implemented in projects like WordPress and Drupal.

In addition, CMSMS separated the presentation layer from the logic and even implemented a templating language called Smarty. It's important to put this into context because at the time languages like Twig, Blade, Handlebars and Mustache were not in wide use or didn't even exist. Kudos to the creators of CMSMS for having this foresight.

As time past and more and more CMS's stared to use templating engines and the popularity of VCS such as Git grew, CMSMS continued to keep the templates in the DB.

In my humble opinion, this has been a major misstep of the project.

Major improvement were made with the template system with CMSMS 2.0 but one thing that is still lacking is the ability to move templates out of the DB and into flat files.

I believe that CMSMS would be a lot more attractive to developers if the templates are stored as flat files rather than in the DB. Smarty is powerful and is actually faster than Twig. Much of the work required to setup a CMSMS site is done in Smarty templates. Therefore, I think it makes sense to be able to store the template files as flat files and commit them to a repository. This also supports a modern workflow of making changes in a editor of your choice and committing them to a repository.

I like the way Drupal handles the relationship between what's in the code and what's in the DB and I think that CMSMS could benefit from using the same model. If a change has been made in the DB, Drupal simply denotes that the template is overwritten, meaning that the DB has a different version of that file. It's up to the user to revert the template to the file version or to continue to use the DB version.

How hard would it be to implement this change to the core? Is there a way this could be implemented using the API?

I'm sure others will weigh in with pros and cons, but you can use flat files already, and in fact we do nearly all our development this way.

Template files stored in /tmp/templates are accessible to the CMS, so our normal workflow is to set up a template in admin that then includes whatever external templates we need (just using something like {include file="footer.tpl"} ).

We do it this way for several reasons - mostly because it allows us to use git / svn as well as our editors and linters of choice.

There are a couple of modules aim to sync up external files with the database as well although I've not used them myself.

If we're handing over a site completely then we will sometime push the templates back into the database just to be nice to any developers who come after us.

Scooper - I'm aware of the possibility of using the tmp/templates folder but this feels a little hackish considering that this folder is intended for cached files and is regularly emptied. Generally I exclude the tmp folder from the repo.

Another problem with using the tmp folder is that it still requires the smarty {include} tag and a db entry in order to generate a template.

Flat files should be a first class citizens in the Design Manager System. Ideally there would be a a series of folders that would look something like this: /public_html/designs/<design_name>/<type_name/<template_name.tpl>

When the design manager is visited there would be a script that would look in the designs folder and cache all the templates the same way it already does for db templates.

Other decisions would need to be made like, weather or not to make these files editable in the admin UI but I think an initial implementation wouldn't be too difficult and a much needed feature.

bbonora wrote:this folder is intended for cached files and is regularly emptied.

That's not true .

/tmp/templates is THE default folder inside CMSMS for file based templates. Please make a look at /lib/classes/internal/class.Smarty_parser.php line 49
So only folders /tmp/cache and /tmp/templates_c will be cleared regularly but not /tmp/templates

By the way - CMSMS is a open system. Feel free to fork DesignManager module with file based templates.

The subject of file based templates has been discussed in the dev team and during last Geekmoot.

We will investigate the possibility to implement it (at least for page templates) in future versions of CMSMS. Note however this will not be in the 2.1.x series.