I wish I knew how to make real ordered lists here, because it would make the text more readable. I’ve summarized the discussion into lists of arguments and counter-arguments. Sorry that there’s so much text, I tried to make it as short and clear as possible.
Arguments in favor of database storage for templates, chunks and snippets:
1. Databases are more flexible because they have more sorting and searching features.
2. Databases perform better because they cache data in memory.
3. Databases are more secure because you can handle permissions at a higher level.
4. Storing metadata in the database is more elegant than in file comments.
5. Databases are better at versioning data.
6. Databases offer more reliable automatic code deployment, especially to multiple servers.
7. Using a database prevents editing conflicts.
Counter-arguments for all but the 6th point:
1. The flexibility databases offer is real, but it’s just not required for templates, chunks and snippets. These elements are just retrieved by identifiers and parsed or written to, everything a file system can do. The naming limitations of file systems are acceptable, because only the developers should see template, chunk and snippet names, categories and descriptions.
2. Caching in memory only starts to matter with high loads, and sites with high loads probably won’t be running in a shared hosting environment without access to solutions like opcode caching. Writing to memory instead of a disk makes no real difference, because templates, chunks and snippets are for the business logic and structure layers of the system and their development and deployment shouldn’t be very write-intensive unless you’re abusing templates, snippets or chunks for storing content.
3. Data in a database is more vulnerable, because database users are more likely to have write permissions for all tables by default, while the HTTP server user is less likely to have write permissions for all files by default, especially in production environments. This is because PHP files are unlikely to contain editable content, while databases are almost guaranteed to. Storing code in a database means a SQL injection vulnerability can give away control over more than just the content layer, and SQL injection vulnerabilities are common, because SQL is often generated dynamically based on user input.
4. The template, chunk and snippet metadata is only a development aid and it would be a side-effect if it made a difference in the site. Template, chunk and snippet identifiers, categories and descriptions for flat files would simply be file names, locations and comments.
5. Evolution doesn’t store version history for templates, chunks and snippets, and its "undelete" function only applies to documents, and even if it did version templates, chunks and snippets, it still would be a substandard VCS.
6. I agree that databases could be more reliable for code deployment than other tools.
7. Using a database prevents editing conflicts by simply preventing concurrent editing. A real VCS would instead allow you to resolve editing conflicts while still supporting concurrent editing.
Arguments for using file storage for templates, chunks and snippets:
1. The best development tools only support editing code on file systems, but because MODx stores templates, chunks and snippets in the database, you’re either locked to using MODx as a substandard IDE or using a workaround, and both times the cost of increased complexity will be less time to spend on tasks that could create more visible added value, because attention is a limited resource for humans.
2. It’s harder to make your code read-only by default if it’s mixed with editable content in the database, and coupled with SQL injections being common, this makes MODx sites generally less secure.
I think that MODx would benefit from moving templates, chunks and snippets to the file system, because the benefits of database storage for these elements don’t stand up to closer scrutiny well, while the advantages like productivity and security of being able to use a real IDE and separate the code layer of the content layer are very clear. MODx could at least support WebDAV for templates, chunks and snippets, so that they could be accessed as files from a mounted drive. I could implement it myself using a library like
SabreDAV, but I’m already using time I don’t really have just to post this.