[wp-trac] Re: [WordPress Trac] #2512: Allow PHP constant to set new options table in wp-config.php

[WordPress Trac]

#2512: Allow PHP constant to set new options table in wp-config.php
----------------------------+-----------------------------------------------
       Id:  2512            |      Status:  assigned                
Component:  Administration  |    Modified:  Mon Feb 27 07:59:59 2006
 Severity:  normal          |   Milestone:  2.1                     
 Priority:  normal          |     Version:  2.0.1                   
    Owner:  markjaquith     |    Reporter:  markjaquith             
----------------------------+-----------------------------------------------
Old description:

> 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.

New description:

 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.

 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.

Comment (by 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).

-- 
Ticket URL: <http://trac.wordpress.org/ticket/2512>
WordPress Trac <http://wordpress.org/>
WordPress blogging software