I’ve activated the WP Security Scan plugin. It recommends changing the wp_ prefix and mentions the lack of a .htaccess file in the wp-admin/ folder. I’m anxious about messing up the wp_ prefix change process, so a little more specificity would help me out:
1) Will changing the wp-config.php file permissions to “666” meet the needed requirement?
2) Please clarify what is meant by making sure the database has “ALTER rights.” How do I check for that? What am I looking for?
3) As far as the plugin’s observation that I don’t have a .htacess file in the wp-admin folder, what code should that .htaccess file contain?
4) Is there anything else I need to do before implementing the wp_prefix change?
I really want to complete these security measures, but I just need a little more info. Thank you in advance for any help.
Will changing the wp-config.php file permissions to “666” meet the needed requirement?
Please clarify what is meant by making sure the database has “ALTER rights.” How do I check for that? What am I looking for?
are you on a shared host? Ignore this step if you are.
As far as the plugin’s observation that I don’t have a .htacess file in the wp-admin folder, what code should that .htaccess file contain?
it can be empty to satisfy that message.
if you want to get fancy though you can set up authentication through apache.
Is there anything else I need to do before implementing the wp_prefix change?
whooami, thanks a lot for your answers. Yep, I’m on shared hosting, so I’ll ignore the “ALTER right” issue, as you say.
I’m unusually nervous that this plugin will mess up my database. But would you say that, as long as I’ve backed up the database and comply with the above-mentioned requirements, it’s almost a sure thing the process will work as described? I realize one can’t give a 100% guarantee, but would you say the odds are pretty close to 100% success if I follow the directions?
Thanks for indulging my fearful questions!
But would you say that, as long as I’ve backed up the database and comply with the above-mentioned requirements, it’s almost a sure thing the process will work as described?
Yes, I would. Youre fine. 🙂 I’ve used that plugin and know the author.
Well, then I shall proceed! Thanks for your patient explanations, whooami. I really appreciate your help.
Hmmm, I have a few more questions. Whenever any of you folks have implemented the wp_prefix change with the WP Security Scan plugin, have you left all other plugins activated?
Is this prefix-change process typically a quick one, or do I need to be concerned about alerting visitors that web maintenance is underway?
I think I’ll hold off on changing the wp_prefix till hopefully I get some feedback on this. Yeah, still feeling a little timid about performing this operation!
I left all the other plugins activated, didnt touch a thing.
Is this prefix-change process typically a quick one..
Takes about 4-5 seconds. You decide about the maintenance alert 😛
Youve really overthunk this. Just click the thing already.
Well, I do tend to overthink things. I guess that’s because I’ve been “burned” on occasion.
I did start the process, but I received the message that I didn’t have ALTER rights. It was mentioned that I wouldn’t have to worry about ALTER rights if I was on shared hosting, which I am.
I decided not to try the manual route for changing the wp_ prefix at the moment, because I’ve not worked much with the database inside PHPMyAdmin, I’m not really used to some of the terminology used in the instructions so I decided I’d hold off until I can review the manual process a little more.
I’m sure this must be a piece of cake to folks who are used to working with the database, but it’s not for me. I don’t know all of the lingo at the moment, and I don’t want to do something that I might regret.
So that’s where I am with this at the moment — hopeful but not yet there.
but I received the message that I didn’t have ALTER rights.
ouch, sorry. so much for my assumption about shared hosting.
Why is wp_ a bad thing when all the other plugins are using wp_ for their databases?
Plugins don’t use wp_, at least not if they’re written correctly. A correctly written plugin automatically uses whatever prefix is set.
Well all of the plugin prefixes in have a wp_ for example wp_polska. At least they are when reviewing the PHPadmin page.
In attempting to correct an issue with on the plugins they wrote in the message wp_ for the three tables they wanted to make sure where there.
Also, what is the deal with the htaccess file not in the admin folder? Why is that a bad thing? I wondering because it went where 2.7.1 said it wanted to go to when moving the index.php to the root directory.
wp_ is the default table prefix. You can have it be anything you want. Whatever it’s set at, a plugin will automatically use that. If you change it, plugins will start using that. So if you change it right now to someotherprefix_ in your wp-config.php and in the database, then all the plugins will automatically adjust, and any new plugins that add more tables will magically use someotherprefix_ as well.
what does changing the prefix acheive? its been that way for years with no problems, so Im skeptical that its very important
Igneous: this is a “zero day attack” mitigation. There is no specific known security threat with using wp_ as the prefix, but I think the idea is that through obfuscation of your table names it might save you from some hypothetical future attack that relies on the knowledge that everybody using WordPress has identical table names.
DebNCgal et al: Regarding the process for changing prefixes if you’re on a hosted server:
Many hosting companies don’t allow ALTER rights (including, apparently, Godaddy). This is probably good, based on my limited knowledge of MySQL security.
There are numerous websites that explain workarounds if this is the case for you. For me, a nice safe process with plenty of fallbacks in case I !@#$ed it all up was as follows:
- Backup your tables: http://codex.wordpress.org/Backing_Up_Your_Database (fallback #1: worst case, restore from this file)
- Open the “.sql” backup file that you’ve just created in the text editor of your liking, and replace all instances of “wp_” with whatever your desired new table prefix is; SAVE AS a new file (fallback #2, you still have the original “.sql” file from step 1 in case this modified SQL dump file doesn’t work out)
- Now, create a NEW empty database on your hosted server. This process varies by hosting company. For Godaddy users, for example, you just login to your hosted account, select Databases > MySQL > Create Database. Once you have your new database created, upload the modified “.sql” file to this database; that is, the .sql file with the new prefixes in it. You can probably use these instructions to accomplish this keeping in mind that you’re not *really* restoring from a backup, but populating a new database using your saved data: http://codex.wordpress.org/Restoring_Your_Database_From_Backup
- Locate your wp_config.php file. Save a copy as wp_config.php.backup (fallback #3, you can revert to the “old” wp_config file, which points to the “old” and untouched original database). Edit the wp_config file so that it contains your new database information including the new username, database name, password, and $table_prefix (~line 11).
- Now the fun part. Until now, you haven’t changed anything on your blog. It’s still using the original, unmodified database. Everything you’ve done until now has happened in the background with no effect on your website. Now you’re going to upload the modified wp_config.php file into your blog’s root directory. You’re telling WordPress to use the new database with the shiny new prefixes in it. If something goes wrong, just upload the backup wp_config.php file and WordPress will use the old, untouched database.
Like you, I’m nervous about any automated database modifications, so this process should give you the peace of mind that should something disastrous happen, you have several immediate options to revert back to the way things were.
NOTE: If you encounter the “You do not have sufficient permissions to access this page” error, follow these instructions here.
Hope this helps!
- The topic ‘[Plugin: WP Security Scan] Anxious About Changing wp_ Prefix’ is closed to new replies.