Question

The main script includes “modules” which add functionality to it. Each module is set up like this:

<?php
//data collection stuff
//(...) approx 80 lines of code
//end data collection
$var1 = 'some data';
$var2 = 'more data';
$var3 = 'other data';
?>

Each module has the same exact variables, just the data collection is different.

I was wondering if it’s a reasonable idea to store the module data in MySQL like this:

[database]
|_modules
  |_name
  |_function (the raw PHP data from above)
  |_description
  |_author
  |_update-url
  |_version
  |_enabled

…and then include the PHP-data from the database and execute it? Something like, a tab-navigation system at the top of the page for each module name, then inside each of those tabs the page content would function by parsing the database-stored code of the module from the function section.

The purpose would be to save code space (fewer lines), allow for easy updates, and include/exclude modules based on the enabled option. This is how many other web-apps work, some of my own too. But never had I thought about this so deeply. Are there any drawbacks or security risks to this?

Answer 1

For example MODx uses this approach. The PHP “snippets” and modules are stored in the database. Most of those PHP snippets just set some configuration values and afterwards include the main module code from files on the server.

The main advantage is the flexibility in editing the module configuration as all modules may be edited in the backend of the CMS. On the other hand, WordPress also allows to edit the plugin-PHP-code from within the backend, but stores everything as files on the server, without storing PHP in the database.

Well, not really an answer, but I think that is a matter of taste.