[wp-trac] [WordPress Trac] #4780: $table_prefix should not be encoded in table_names.

[WordPress Trac]

#4780: $table_prefix should not be encoded in table_names.
----------------------------+------------------------
 Reporter:  docwhat         |       Owner:  anonymous
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  invalid
 Keywords:                  |
----------------------------+------------------------

Comment (by Converting2wp):

 For my attempts to put two installs into one database, I was just using
 the info at
 http://codex.wordpress.org/Installing_Multiple_Blogs#Single_Database [Of
 course, with 3.0+, a network of sites may make more sense for "related
 blogs" but not, of course, for dev/stage/test.]

 Yes, the XXX_options.XXX_user_roles and XXX_user_meta.XXX_capabilities
 entries were mentioned in the original post.

 But I'm making an update here because the "wp_optimize" that I mentioned
 above is, I think, a red herring. It turns out that was a symptom of a
 hacked install, as described in
 http://smackdown.blogsblogsblogs.com/2010/06/14/rackspace-hacked-clients-
 check-your-databases-wordpress-wp_optimize-backdoor-in-wp_options-table/

 So my current hypothesis, assuming there is a reason to change the table
 prefix of a running system, the way to do it is
 1. Change all the table names (of course)
 2. Search the options table for entries with "option_name" starting with
 the old table prefix and change those entries to match the new prefix
 3. Search the user_meta table for entries with "meta_key" starting with
 the old table prefix and change those entries to match the new prefix

 I expect that's what I'll be doing even if I do separate the installs in
 separate databases.

 Thanks for listening.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/4780#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software