7

I have nearly completed a project but forgot in the first place to change the wp_ db prefix on install. Now i am a little bit worried to change it afterwards in fear of breaking the whole installation. Therefor the question if these described methods still work with 3.8.x or has anything change since then?

http://www.wpbeginner.com/wp-tutorials/how-to-change-the-wordpress-database-prefix-to-improve-security/

http://digwp.com/2010/10/change-database-prefix/

and have only table and field names to be changed? cuz i also saw a few prefixes starting with wp instead of wp_ ? Best regards Ralf

Improve this question
2

2 Answers 2

Reset to default
5

The basic idea should work-- change the prefix in both wp-config.php and in the database itself. What isn't covered would be cases where the prefix is used in other contexts such as when used as part of a "meta" key. Those cases you would need to trace down one by one.

You could also have trouble it the prefix has been hard-coded into anything, but hopefully that isn't the case.

The safe thing to do, if you are able would be to copy the entire database to a database with a different name, and alter the second database. Switching between the two would be a simple edit of the database name in wp-config.php and you would have nearly no chance of data loss if you make a mistake, just make sure no one is editing the site while you play with it.

I'd download a complete backup of the site to disk, just to be 100% safe.

Improve this answer
7
  • yeah in the first place, before i start i would make a backup. Creating a second database and alter there might be a real good idea. about potential hard coded prefixes i am worried too indeed. and a question you mentioned the cases not covered like "part of a meta key". Does that mean there might be cases aside the fieldname prefixes in the options and usermeta table. which wouldn't be covered with the two select statements?
    – rkoller
    Commented Mar 23, 2014 at 17:43
  • 1
    Yes, I have seen cases where the database prefix is part of the key. In fact, it looks like the Core does that with some usermeta keys, but I'd have to do more research to be sure.
    – s_ha_dum
    Commented Mar 23, 2014 at 18:03
  • ahhhh i see. oki doki. then i guess i just backup the db create also a second "try out" version and then apply the three steps from the posts to my 3.8.1 install. i think i shouldn't worry that much beforehand and just do. ;) thanks!
    – rkoller
    Commented Mar 23, 2014 at 18:20
  • 2
    I ran into this very thing recently - if you are looking for some easy queries to run (after making a backup of your db) try this script on for size github.com/codearachnid/wordpress-snippits/blob/…
    – codearachnid
    Commented Mar 25, 2014 at 21:50
  • @codearachnid nice one. thanks. a few meta_keys are missing in my db when i crosschecked but i guess those are db entries related to functions i have disabled in wp right now
    – rkoller
    Commented Mar 28, 2014 at 12:47
1

Supplementary to s_ha_dum's answer and the comments:

The meta keys I needed to change when I did this (v4.8.5) - i.e. all wp_usermeta.meta_key entries beginning wp_, or whatever your current prefix is - were:

  • _capabilities
  • _dashboard_quick_press_last_post_id
  • _media_library_mode
  • _user_level
  • _user-settings

Symptoms: visiting /wp-admin/users.php and seeing nothing in the 'Role' column (also blank role when running WP-CLI's wp user get), and having an empty 'Change Role To' dropdown at the top & bottom of the list.

It's fixable with a simple find and replace, e.g.

wp search-replace --dry-run 'oldprefix_' 'newprefix_'

(--dry-run means it'll tell you how many rows would change but not actually do it yet. You can narrow it to, or skip specific tables if you like too, see the documentation.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.