Antisocial Engineering (talas) wrote in phpstory,
Antisocial Engineering

Database Changes

On a separate project I have found a very simple way to store configuration options in the database, instead of just in ./includes/, and I'm wondering if this should be put into phpStory before it is actually released.

In my opinion, this would make it easier to allow the administrator(s) of a site to change the options, especially if not all of them have FTP/SSH access to the server. It would be necessary to keep the ./includes/ file only for the database login information. That file could also be used both to load the configuration from the database and for any overrides on the values stored in the database (if normal administrators should not be able to change certain options).

Comments? Suggestions?

  • Post a new comment


    default userpic

    Your IP address will be recorded 

I'd go for in the database, even though you'd probably have to make a seperate table just for settings. It could also allow you to include a couple of sets of default settings, and allow people to have setting-schemes, kinda like hardware profiles in windows. you could have two entries in that table for each set of settings, one with the values, the next with an authorisation level you would need to change it, so that you could keep all your options in the database while allowing you to bar certain people from changing the options (it'd be as easy as using 1 or 0, for super-admin / admin)

my main objection to storing stuff in the database is that 1) you have to have a seperate table, which I prefer not to do.
2) if you lose your db, you lose your entire site. There's bound to be options that apply to semi-static, non-db content, and once the db fails, you'd have the site revert to the defaults, which might not be the behavior you would want. Ofcourse, you could find very valid arguments for shutting the entire site off when the db fails, especially in something as heavily db driven as php-story (or my own mc :)).

Seeing as you want to go for maximum usability, userfriendlyness, and flexibility, I'd go for options in the db (and probably just put the db info in your, and have it set by the installscript)
I'd say "go with the DB option" if it's not too much work :-)