A question about templating in the databse - and why it seems like a flaw to me.

I think you mentioned earlier that MODx is not "1.0". But it is with our July release of MODx Evolution 1.0. It’s based on our classic codebase, and is tremendously cleaned up from its predecessor releases, but still has some left over baggage. Some folks prefer templates on the filesystem, some are perfectly OK with how they are. Both are equally right!

An important thing to keep in mind is that MODx is a content management framework (CMF) just as much as it is a regular CMS. As such it is easy today to put together a custom build you need that contains your favorite bits. With the 1.0.1 release that will be even easier, but I’ll let you dive into SVN and figure out those bits for yourself.

Also note, the Revo has introduced static Resources: files on the filesystem with all the metadata managed. I can say with a fair degree of confidence that at least you’d still need to create a representation in the manager to store the associated metadata for the templates. Why? Because of the way MODx works with TVs and ACLs attached to templates. That said, that’d be a 1-time operation.

We’re constantly considering ways to improve MODx. The best way to make sure that something like this (and I think it makes sense for more than just template Elements) is to file an improvement request in JIRA, and we’ll get it slotted into the roadmap.

Quote from: rthrash at Aug 24, 2009, 08:11 AM

Also note, the Revo has introduced static Resources: files on the filesystem with all the metadata managed. I can say with a fair degree of confidence that at least you’d still need to create a representation in the manager to store the associated metadata for the templates. Why? Because of the way MODx works with TVs and ACLs attached to templates. That said, that’d be a 1-time operation.

I don’t understand how to do it (i don’t really understand the sentence, a representation in the manager? )!
Can you give us a hint to achieve that easily with the current public bêta?

I think its important that templates work via the filesystem at the core to make this just one step futher a great CMS

Here’s a plugin to do just that. This way we can both have it the way we like it

Create a new plugin, name it whatever you want, check the OnLoadWebDocument checkbox in the System Events tab, and copy/paste the following code into the plugin’s Plugin Code field:

In the Configuration tab, add this parameter:

Save the plugin. Now you can edit the Path and Extension configuration parameters as you wish.

Create a new template, just giving it a name (no spaces in the name) but no content. Then in assets/templates create a directory with the exact same name, and put your template file in it with the same name + .tpl (or whatever extension you set in the plugin configuration). The template’s directory and file name must match exactly the template name! For example, a template named MyTemplate it would look like this


This could probably use some bells and whistles, such as running it through a function to allow spaces and special characters in the template’s name or loading a default template if the one expected can’t be loaded for some reason.

FYI, static Elements (where content is stored on the filesystem, similar to static Resources) are already planned for 2.1.x release. Since static Resources will actually be refactored to store their content as an Element tied to the Resource (rather than directly as part of the Resource itself), this makes the most sense for how/when to implement this feature. This will also include native versioning and i18n facilities for the content of any Element. This requires some major database refactoring and code reorganization, and this is the only reason this is not a part of 2.0.x release; 2.0.x is serving as a stepping stone between where we have been (0.9.x/1.x) and where we want to go with content storage in the near future.

Here’s an improved version of the FetchTemplate plugin; if the file can’t be loaded it will load the Manager template (which can be a default, contain an error message, or just be empty).

That was my initial reaction to the "code in the database" approach of MODx as well. It just doesn’t feel right. There’s also a practical reason for not doing that and it’s proper configuration management.
All of our sites live in and are deployed from our Subversion repository, which gives us the ability to collaborate on the same project and keep track of all changes. Obviously having code in the database breaks all that so we tried to move all of our code into files under version control in the following way:

1. Created new folders under ’assets’ for our custom chunks, modules, and snippets.
2. For each chunk in the CMS use "[[loadFile? &file=`assets/arc_chunks/chunk_name.chk`]]" to load code from a file.
3. For each template in the CMS use "[[loadFile? &file=`assets/templates/main/template_name.tpl`]]" to load code from a file
4. Use standard develop/upload/test work flow to work with the code.

To simplify the workflow we setup a development linux box with the personal workspaces mapped as Samba drives. Developers were working directly on those workspaces, which allowed us to get rid of the ’upload’ step in the workflow simplifying it to develop/save/test. A very natural way to work.
To streamline things further we standardized on Eclipse environment with Subversive and Mylyn to keep track of tasks and commits.

For each release the DB is dumped and the dump file is committed to the repository as well, which makes the deployment a very simple process: run "svn update" on the production server and import the DB dump file.

Not all code could be moved to files. There were some cases where it wouldn’t work, but moving the same code back into the db solved the problem. Not optimal, but those cases were rare. Overall most of our code lives in files, which are being called from templates and chunks in the CMS.

I haven’t played with Revo yet but am looking forward to the new resource types. Hopefully it can simplify things further.

I’m still convinced that code in the database is bad mojo and am yet to hear a reasonable argument to the contrary, but always ready to listen.

Hope this helps.

outre99: though I would agree that this is a great approach for a development shop using MODx, it ultimately is a bit contradictory to the idea of a CMS in the first place, which is to enable non-technical users to be able to update their site without calling the development shop. I’m looking to the new transport packaging features in Revo to help resolve this in a way that can allow end-users to be able to apply any kind of update to a site, though it requires extra work for the developers to generate the packages for delivery to the target installation. This will be regardless of content being stored in the db or the filesystem; in either case, the metadata needs to be accounted for.

Indeed; the rest of us 99% of MODx users don’t need that kind of management. However, having the option to do things whichever way you prefer is the ultimate goal.

Snippets to include external files are one way of going to the filesystem (as well as reducing the load on the siteCache.idx.php file).

For templates, the plugin posted above will do the trick. I’m thinking about how to use a plugin for chunks as well; empty chunks don’t take up much space in the cache file!

Snippets, modules and plugins are code already, so a simple one-liner include will do fine.

TVs... well, TVs are complicated enough as they are, and don’t get cached anyway.

maybe a webDAV connector would be usefull for people that want to edit database-content like it’s on a filesystem?

Olaf

Quote from: olafmol at Aug 25, 2009, 04:35 AM

maybe a webDAV connector would be usefull for people that want to edit database-content like it’s on a filesystem?

Olaf

That would require that all of the metadata be exposed as WebDAV/DeltaV properties (just like SVN properties) to coordinate with the content. It’s something I explored, but I’m not sure that is really the right direction either, though it definitely could be one solution.