tags:

views:

149

answers:

4

I have some site metadata I'd like to be changeable... for example, in my application, if the sysadmin didn't want to use the "Inventory" portion of the site, he/she could turn it off, and it would disappear from the main site.

So I was thinking, maybe I could make a table in my database called "meta", and insert values (or tuples) there! Then, if a module got turned off, the script would update the row, and set "module x" to 0, and I'd be done with it, right?

Except it seems like an awful lot of overhead (creating an entire table, and maintaining it, etc) just for a set of values... Basically, my solution sounds like shoving a square peg into a circular slot.

A cursory glance over the drupal database yielded nothing, and I'm guessing they use a configuration file on the server itself? If that's the case, I don't know exactly how saved values in a .cfg file (for example) could be read by the web app, nor do I know how such an app could save information to the file. I'd appreciate your insight, if you've tackled this problem before.

I use primarily PHP, by the way.

Thanks in advance!

+2  A: 

I've often seen this accomplished using a config array:

$config["admin_email"] = "[email protected]";
$config["site_name"] = "Bob's Trinket Store";
$config["excluded_modules"] = array("inventory", "user_chat");

Then later you can check:

if (!in_array("inventory", $config["excluded_modules"])) {
  // include inventory logic
}

Granted, this is a bit backwards. In reality, it would be smarter to explicitly declare included modules, rather than the negative. You would then reference this config.php in your project to load-up and act in response to different configurations.

You could implement this as a database table too, making at least two fields:

  1. Option
  2. Value

Where option may be "excluded_modules" and its corresponding value would be "inventory,user_cat". In all honesty though, this method is a bit sloppy, and may cause you some frustration in the future.

Jonathan Sampson
Just got your latest edit... I was thinking completely backwards in terms of my table schema, initially.Having two columns, option, and value, seem logical, and should be easier to manage (like the contributer below has mentioned).Thanks!
Julian H. Lam
+1  A: 

You have two choices basically - either put it in a DB table, or in a flat config file (probably PHP, perhaps XML). With the latter, to make it editable from a page, you will have to (1) deal with messy OS-specific file access issues, (1) apply proper file permissions each time you set up a site, and (3) parse and generate PHP/XML code. With a database, all you need is a simple query, so I'd definitely go with that.

As for large projects using this approach, I know phpBB does store most of its config in a database (except for passwords, last time I checked).

Max Shawabkeh
+1  A: 

I know your question is "how do I read/write to a separate file on the server from a web app", but I figured I'd address one of the assumptions you made. There's nothing (too) wrong with storing your config in the DB.

I've seen projects (with lots of traffic, and good uptime - and a ton of IT keeping it that way =P) that stored configuration in the database, more or less as you described. If it's a single table, and you don't have a whole crazy fail-over/partitioning scheme on it, then it's not really THAT much overhead.

The DB has lots of features, besides storing data, and a lot of infrastructure around it. If you use the DB for your config, you get to use whatever mechanism you have for DB deployment/backup with little extra cost. You also can take advantage of the built in permissions mechanism, and any undo features that are available.

Edit: However, if you access that config on every page display, though, you might bottleneck :) All about your design. One solution is that if you have a persistent web service, you can have it re-scan the config every X seconds.

Merlyn Morgan-Graham
That's a good point, and I think I've successfully been swayed. :)
Julian H. Lam
A: 

I prefer to work with ini files as configuration that sit before public_html folder.I think that gives me a lot of flexibility and grouping var and create if necessary separate ini for modules etc.

ntan