Why are templates stored in the database? Topic is solved

[BuzCarter]

I appreciate that in asking this I just might be setting myself up for some serious flaming, but here goes:

I'm curious as to how the decision was reached to put templates into the database. I've dug around on the site and forums and am still left scratching my head.

There's a plethora of wonderful editors out there for CSS and HTML that all work on files. Search and replace across a dozen files, incredibly useful color-coding making editing HTML, PHP, and CSS a dream. All these conveniences are sacrificed, however, as soon as the template is hidden away in the db.

Moreover, in projects such as WordPress switching Themes (the entire site’s appearance) requires but a single click as they just store a pointer to the appropriate directory holding all of the necessary files.

I appreciate that there might be some performance hits in reading files, but surely it would be possible to marry the two approaches -- take a one time hit to suck the files into the db if need be (perhaps “debug” and “production” modes where “debug” always reads the files and “production” reads from the db).

Using files might also make it far easier to create easily pluggable, sharable themes, a feature that's not just useful for folks wanting to launch a site with minimal thought, but for nerd-lites like me -- I find them to be invaluable in understanding how systems work.

Too much transparency is lost when all goes into the db, and I'm an old Oracle/SQL Server zealot. This approach smells a bit of "wow, this is a nifty hammer -- have you noticed all of these nails?".

Anyway, I've found CMS to be quite cool, with so many features that I thought I'd subject myself to ridicule by pointing out what seems to me at least, to be a major hurdle in people adopting this app (ok, aside from the documentation being non-existent, but the active forums compensate, being loaded with smart folks 24 hours)

Anyway, this thought, or question, is sincere and not an attack on what is clearly a decent and well thought out application. Anyone know the history of this decision?

[BuzCarter]

Oooooo. OK, right off the bat, as it were, you've made a great point -- access without requiring ftp. Some might quibble about how often site layouts are updated from cafes -- except that I frequently do exactly that from the library-- the one that doesn't block the ftp port, that is. So that's a good selling point.

Hmmm, still hoping for a middle way, though, perhaps a plugin that would allow for "theme directories" that could be imported. I'm mainly thinking of how quick and easy it is to edit files with Dreamweaver, and of course, a one-click them installer would be sweet.

Thanks.  You make a compelling and fairly substantial entry on the plus side of the db ledger.

[Ted]

Well, for me, it's really 2 issues.

1. If everything is written to files, then you have to worry about website permissions, espeically if you're editing them in the admin panel.  At this point, the installation is fairly easy because you only have to make 3 directories writable by the web server and never have to think about them again.

2. I can more closely control the "metadata" aspects of templates.  And can pick and choose things.  For instance, I added the encoding dropdown to templates back in 0.9.  If that was done with files, then I would need to have some way to make sure the files were linked with a database that was just storing the metadata for them.  Might as well take it the next step, make a text field, and just throw it in there as well...

Look at it this way.  The majority of the other CMS type applications out there have templates that are PHP code!  You have to define metadata and different pieces with functions instead of just dumping it in a text field, replacing 2 things and it being complete.  I think it would be a lot harder to pull off this with just files alone...

Though, I totally agree with your idea of having a template/sytlesheet importing tool.  Heck, it could be a module, since a module has access to that kind of thing anyway.  We've actually discussed this before, but haven't gotten any further than discussions at this point. 

Oh, and thanks for your candor.  Sometimes I have to revisit things I did back in the beginning to make sure they still make sense...  I think this one still does. 

[lemkepf]

Ehh... i think it's a 50-50 shot for me. Sure... i like to not have to mess with FTP'ing files but here is my issue with it....

As a designer/developer i usually work with a mock-up design first in photoshop. Then i transfer that to clean CSS/XHTML. I had this all done when starting to work with this CMS. I got the point where i started to add my templates to the CMS. Oh crap... i want to change something.

So i have to do this:
go to the CMS, edit my template, copy out my HTML code, paste it into dreamweaver, do the same with the CSS, then edit my design, copy html back to CMS, copy CSS back to cms....

instead of:
Open up the template/css, change design, save. Done.

I think instead of saving the CSS/Design in the DB, save them as a file. That way people can edit them in the browser or just edit the file. I think it would also help when moving sites between hosts. (i've already had to do this... why restore the hole DB, when all i want is the templates?)

Just some thoughts.... maybe give the user the option to do both?

[Piratos]

Why make it not simple
As Example:
Copy the default template and paste it in an editor.
change {stylesheet}  to



Copy the stylesheet and paste it in a new instance of your editor

If you are using cssmenu copy  the css from cssmenu in this stylesheet

save the template in as tmp/templates/default.tpl
save the stylesheet as tmp/templates/styles.css

delete the content of the template an write this lines instead:
{include file="default.tpl"}

delete the stylesheet
save it

now you you have the same but the files are not in the database.

so i work since the first day.

[lemkepf]

delete the content of the template an write this lines instead:
{include file="default.tpl"}

Good idea... didn't know that syntax existed... but you can't edit it in the app... I guess i just want the whole world and nothing less!

[Akrabat]

IMO, the best thing about everything being in the database is that you only have one thing to back up.

One thing I really like about Movable Type is their concept of "mirroring" templates. You have the template in the database which is also mirrored to a file. If you change the file, then MT automatically updates the database version. If you change the database version, then MT automatically updates the file.

[cyberman]

I found piratos' hint useful because

1. It's easier to export the template for other users around the world .

2. If I have the choice to work with Dreamweaver/Golive/Weaverslave or TinyMCE/HTMLArea/FCK, I'll take the first alternative .

[BuzCarter]

I'd assumed the promise of "one thing to backup" might also be a reason for the db approach -- until one considers that images and other attachments aren't in the db -- as my cursory perusal seemed to confirm (could be wrong, though); they live on the file system. So for some CMS folks (maybe a majority, but not all installations) the single backup is true and durned handy.

Hey, thanks for a great discussion on this, btw.

PS. Looking forward to trying piratos's idea, too. Perhaps I'll figure a way to implement "one click theme installer" along what the lines of how Akrabat described MoveableType's solution...

[cyberman]

Please make a look at the Projekt CMSms Themes - you are all invited to submit your themes ...

[cyberman]

Why make it not simple
...
now you you have the same but the files are not in the database.
so i work since the first day.

I'm wondering - a clean test installation (local) with the access to database was faster as an other test installation with direct access to tpl ...

[wiseleo]

Databases cache data in RAM and allow for a persistent connection, files require disk I/O.

There is genuine difference.

I wouldn't use the system if I had to keep up with more files. As the product evolves, new functionality will be added painlessly. Besides, all templates are dynamically indexed. If a template is removed, the product does not break as it would if a file were removed.

[BuzCarter]

Ahh, didn't know how well file I/O measured against db connection management plus caching, good to know. Thanks, WiseLeo.

What do you mean by:

Besides, all templates are dynamically indexed.

Are you refering to Referential Integrity? If so, no argument there; database RI always trumps file system.