Allow PHP constant to set new options table in wp-config.php

[markjaquith]

I've had several clients ask me to set up a test install of their blog so that they can try out theme changes and plugins without compromising their main blog. If we let a constant determine the options table, they could use the same table_prefix as their main blog, but just specify a different options table so plugins, home/siteurl, themes could be different, but all the other blog data (posts, comments, links, categories) would be the same.

[markjaquith]

Patch against latest SVN checkout

[markjaquith]

Problem:

Let's say we have main_ and dev_, and we want dev_ to have its own options table, but use main_ for everything else.

You run into permissions issues, because dev_ is looking in dev_options for 'main_user_roles' and not finding it. We would need to check to see if the the options table is using a different prefix from that of $wpdb->prefix, and if so, grab 'main_user_roles' from main_options instead of dev_options (where it doesn't exist).

[markjaquith]

[ok, I'm a retart...this was supposed to be a comment, not a description change]

I'm uploading a patch that should do this. It does it dynamically, from
the database, but this is really only going to be used for development
purposes, so I think that's acceptable. We can't save the option in the
local options table because changes in the main blog won't be reflected.
I'm open to suggestions here as to an alternate strategy.

[davidhouse]

Don't see the point of the constant. You can just hack wp-settings.php to change the value of $wpdb->options.

What's stored in main_user_roles?

[markjaquith]

The point is that you can do it without hacking core files like wp-settings.php

main_user_roles stores all the roles and their capabilities.

[davidhouse]

Well if it's only a temporary change by someone that knows their way around WP then... If we wanted to add options in the future which were prefixed with the table prefix then we'd encounter this problem again and again, and have to remember to patch every time.

I'd create a whole bunch of dev_ tables. Then you'd have the freedom to chop and change users and stuff as well.

-1.

[markjaquith]

You get the same problems if you copy the tables into dev_, although yeah, that is more flexible in the end. Maybe I just need to write a "change table prefix" script that I can run after copying the tables that will detect the old prefix and switch to the new one.

[davidhouse]

Well, if you copied everything over to dev_ and set the table prefix to dev_ then everything should work, right? That's what I meant.

[markjaquith]

No, the prefix on the roles within the dev_options table would still be set to the original prefix. And all of the users would still have their options set using the old prefix. So it would require a script to go through and change all of those.

[matt]

Not a core feature.