Quote from: kenw at Mar 15, 2009, 11:58 PM
Nevertheless, I also believe you can build a scalable and highly performant CMS using the file system to store content. In fact, I architected and led the development of a successful "enterprise CMS" (targeted at small to medium sized financial institutions) using flat files for regular content and templates. It runs on a server farm supporting over 100 sites/server and millions of hits/day. We did use a database to store user info and some odds and ends where it seemed to make sense but 90% of the content was being pulled out of plain old files.
We decided to use the file system because we believed it would make it a whole lot easier to support versioning, grouped changes, and multi-stage deployment, features that aren’t part of MODx and which are probably not important to MODx’s core audience (but are important to a certain class of CMS user). In fact, these sorts of features are antithetical to MODx’s basic premise of simple content authoring and publishing. I’m still not sure you need to user a relational database to store snippets, chunks, etc. but that won’t stop me from continuing to use and like this great application.
Is this a PHP CMS? No denying that you can do that, but ultimately, you have to be able to cache that content (and the database hits) to serve truly scalable sites, unless you are talking about writing straight PHP. That doesn’t count, because CMS users do not want to edit plain PHP/HTML files to manage their content.
Never-the-less, MODx Revolution 2.0 will give you the option of storing your Resource source content (i.e. Documents) on the file-system. The release after that will do the same for Elements (i.e. Templates, Chunks, Snippets, TVs and Plugins) and introduce native versioning, regardless if your source content is stored in the database or the file-system. Ultimately your caching strategy is going to be your most important point; where your source content is stored is only important to the environment you are running the site in and your decision on where to store content should be based on those facts.
Our aim (or at least mine) with MODx is to force as few rules on the developer as possible when constructing a site. I prefer flexibility and allowing the utilization of tried and trusted software over making MODx do everything, and the same philosophy will be applied to this issue, so (for example) those who want to use Subversion to version their content can, while others can choose to use the native MODx versioning features (once that feature is released).
MODX Staff
