Storing site settings on the server

[eluser]Zack Kitzmiller[/eluser]
I know all of you guru's all have your own way of doing this, but I'm curious as to how you keep your authenticated member's personal settings.

I'm thinking the best way to handle this, is to store a setting string as json, and store it the database somewhere..

I don't want to add a column to the database for each setting, that seems silly.

[eluser]BrianDHall[/eluser]
I just use an associative array and serialize it. The only performance issue with serialize is if you have massive data being stuck into as it wasn't designed for that, but for configuration it's easy.

So I just have a single column in my user table such as "user_preferences" which contains a serialized associative array, so once unserialized it becomes as simple as $userpref['homepage'], etc.

[eluser]kurucu[/eluser]
I had a user settings table, with a column for each setting.... Hmmm. I was about to implement a system whereby the site default setting is used if a user setting can't be found.

But your serialise option seems very nice (only pity is you can't filter/sort on it - depends on the setting on whether this is useful or not). Anyway, a massive advantage to the serialised method is that I could use array_merge, and then the array would pick up any unset user preferences from the default set.

Timely question asking! Thanks!

[eluser]Phil Sturgeon[/eluser]
You can take a look at my settings module for PyroCMS as a rough example of how this can be achieved.

[eluser]kurucu[/eluser]
I just took a look at the code (nice!) and that's pretty much what I had in mind previously. The distinction on my site is that certain preferences (e.g. posts shown per page of thread) can be further customised by each user. Unless I've missed the fact that your items array is prepopulated with user data at some point.

Had I spotted your PyroCMS before writing mine I'd definitely have borrowed your code instead lol.

[eluser]Phil Sturgeon[/eluser]
Make another method $this->settings->user_item() and make another table with an extra field for the user id. Call it "user_settings" and modify the model. Then you just need to add in a $this->user_id = <whatever> in your settings controller and you are good to go.

Either way, it shows you how to handle defaults nicely. either have a default field or have it falling back on the config values. If nothing in the database it will just use a config value of the same name. Double default fallback time :-)

[eluser]Zack Kitzmiller[/eluser]
serialized php is gross... But I could do the exact same thing with JSON.. Which is probably what I'll do.

Thanks guys

[eluser]BrianDHall[/eluser]
You could use a custom 'build user preference' function was a little more careful with merging the default and non-default array, as an option.

Not having it so MySQL can operate on it is the primary weakness of the strategy - but as I have no need for such functionality, it isn't a problem If its a must-have then you would of course need a different way of doing it.

For search though, I just use SQL LIKE when I really must, or even use a loop as I don't have many thousands of registered users it isn't very processor intensive.

The advantage of serializing is it is easily expandable, you can just shove another config option in there anytime anywhere. It's easy, simple, and quick. The downside is it isn't robust like using JSON or XML object strategies.

Hm, another option though is using a MySQL table for user preferences, with only 3 fields - preference name, user ID, preference value. So each user preference took up one row in a special table - but the system doesn't care if you create new rules or delete old ones.

Its way more functionality then I've needed for user prefs, and it would be made especially easy with ORM like DMZ - but I just don't have a use for it myself

EDIT: You'd want a 4th field for the index just is just 'id', but that's beside the point.

[eluser]jedd[/eluser]
[quote author="techneke" date="1253560970"]
I don't want to add a column to the database for each setting, that seems silly.
[/quote]

Please explain this belief.

[eluser]Zack Kitzmiller[/eluser]
[quote author="jedd" date="1253569686"][quote author="techneke" date="1253560970"]
I don't want to add a column to the database for each setting, that seems silly.
[/quote]

Please explain this belief.[/quote]

I don't ever need to search or sort by these settings, so why would I want to manage them with columns?

If I use a "settings" column with a a string in it, I can manage all of the settings, change the number of settings, the setting values, and the type of data stored in those settings with just a a flick of PHP.

Having to go into something like phpMyAdmin and add a column for one thing seems asinine. I could end up with 10,000 columns. What if I deprecate a setting, go back in a delete a column?

It's not very modular, no does it seem like it's best practice of any kind.

what if I have 10 different emails that go out?

wants_mail_1 wants_mail_2 want_mail_3 wants_mail_4 ... wants_mail_10 all columns? Ugh.