A question from alt.php:
What I’m asking – is there a best practise to this concept?
Not really… When you say “best practice”, there’s always a question, “best for what?” And that “what” in turn can be either a feature of system environment or a design objective…
For example, storing content in a database is good enough for most occasions, except when you are told not to expect database connectivity in the target system environment. 🙂
As to design objectives, you may be told to develop for performance, maintainability, or time to market. Let’s pretend you are told to store both textual content and executable code. Storing the content in the database is clearly the preferred solution, but what of the code? You can:
- Store it in a database and use eval() to run it, which will be fine and dandy in terms of time to market and maintainability, but will have its share of performance issues, which, however, will only show at high loads, or
- Store it in files and execute it with include(), which will have the best performance, but will create problems with both maintainability (because backing up the database is no longer enough; the file system must also be backed up) and time to market (because you now need two separate storage routines, one for content, another for code), or
- Figure out a hybrid solution: store code in a database, but also save each snippet into a file when the relevant DB record is updated and/or when the code is about to be used for the first time and then include() the resulting file; this approach would create a minor performance drawback (there will be the overhead of generating code files and checking for their existence), get rid of all maintainability issues (the database is, once again, the only source of data the application needs to operate), and push back your time to market (since you need to write the code to manage the stored code).
In case some of the above sounds familiar, #1 (with a ton security precautions surrounding it) is implemented in Drupal under the moniker “PHP filter” and #2 is used in WordPress’ plugin and theming systems (although you can’t create a new plugin or theme file from within WordPress, you definitely can edit those files with WordPress). I am not aware of anyone using #3 as described, but I sincerely doubt I am the first person to have thought of it… 🙂