Question about serialized data and the datastore table
 

I'm working on a project for the admin CP that requires permission from the site owner / super admin so I don't want to put the settings in settings > options. I thought of creating a new table but as I researched how the various vB options are stored for use I see they are serialized and put in the datastore table. Somewhere this table is queried and the options unserialized to be available as $vbulletin->options. I want to do something similar and store my project settings this way as $vbulletin->my_project

If I go this route I see no reason to build a new table for my settings. Is there any reason I should have my settings in a new table if they're in datastore?

But most importantly, where is the datastore table queried and how do I unserialize my project settings (i.e., what hook location)?

Function build_datastore() in includes/functions.php has a function build_datastore(). It has a parameter to automatically unserialize the data when it's read. You can arrange for your datastore item to be read back in (and unserialized) by adding it to $new_datastore_fetch[] at hook init_startup. If you want it only to be read in the admincp, you can check for VB_AREA == 'AdminCP'.

Just for the record, the settings are kept in the 'setting' table and automatically built in to the settings datastore item when they are edited. So I think another option might be to add your settings to the setting table but put a value for grouptitle that doesn't exist in the settinggroup table, then I think they won't be displayed. (But now that I think about it more, I'm not sure what the advantage of that would be.)

I had gotten as far as build_datastore() but couldn't find where was queried. Your idea almost did it but you have to do it like this:

Notice the nested quotes. I haven't followed it all the way through but I suspect the single quotes are there so it can be used in an eval to create $vbulletin->my_project from the serialized data stored under 'my_project' in datastore.

My first idea here was to build all my options in settings > options then manually delete (not with the [delete] link) the setting group so it wouldn't show in settings>options. It still worked but I looked at the product xml file and it won't export the options if the group name is deleted.

Another idea I was tinkering with was to gather all the settings into an array in the code block to which the form submits , then serialize the array and write it to a file my_project/settings.txt. My project has its own my_project/global.php that is required by the other files, and in there it would read the file and unserialized the data into a settings array for all the other files. Either approach would work but I think I'll go with using datastore just to be more like vBulletin coding.

Thanks for the help.

That might be. You can actually set $new_datastore_fetch[] directly and not use the extra quotes if you'd rather. Looks like they decided to leave $datastore_fetch[] the same so as not to break old mods.

I tried that and it didn't work (but maybe something else was wrong at the time). I think it needs $new_datastore_fetch (without single quotes) to know it should read that row in datastore and $datastore_fetch (with single quotes) to create $vbulletin->my_project with some sort of eval() code.

Anyway, I have it working more or less. Thanks again.

You know, someone else said the same thing once, even after I tested it myself and it seemed to work. I guess there must be something I don't understand about it.

You're right, that does work. I must have had another problem at the time. But I think I'll stick with the nested quoting anyway in case older versions need that. I'm hoping this will work in vB3. Some time when I don't have a dozen windows open I might follow through and see how all that works

Good point, i hadn't thought of that. I checked vb3.8.7 and it has $new_datastore_fetch, but vb3.8.3 doesn't.