Just fooling around with this plugin in my test site. I installed the latest version, activated the plugin, ran the check, all worked fine. Then my eye fell on the suggestion to change the wp_ suffix for tables, so I gave it ago and changed them to tst_. The report said that all changes were successfull except two wpau_ plugin tables which I had to change manually. So when I decided to see if the site was still up, I got the screen that I had to install WP and then I got a password. Very funny! So now the site is a completely fresh and new WP installation without theme, posts or anything.
That wouldn’t have been funny if it was a live site!
That happened because you didn’t read the instructions.
Before running this script:
* wp-config must be set to writable before running this script.
* the database user you’re using with WordPress must have ALTER rights
This is printed directly above the “Start Renaming” button. You didn’t ensure that wp-config.php is writable. Therefore, WordPress had no way of knowing that the prefix had changed. If you don’t want to/can’t make it writable, you can change the file manually like when you initially install WordPress.
1) I thought it had, but I can’t access my control panel from work to check;
2) My user has too many rights was a remark that came from the initial check.
But just for my understanding, did the installation break over the two plugin tables that couldn’t be renamed? I didn’t get more errors than that. Should I have edited them manually before continuing to work in the WP admin?
Nothing happened from the two plugin tables that couldn’t be automatically renamed other then obviously that plugin wouldn’t work.
Had you ensured the wp-config was writable, or changed it by hand, WordPress would have worked fine. This can still be done. Even installing the fresh copy of WordPress won’t overwrite your old tables. All you would need to do is change it in wp-config and you’ll see your old WordPress.
As for your database user having too many rights, that’s a security precaution. Ideally, the database user WordPress runs as would have only just enough rights, in the event that it’s compromised. For instance, you wouldn’t want that user to be able to create new databases or delete databases.
This isn’t always something that you can change, depending on your hosting provider.
You said as much, but I only realised during my stroll downtown during lunchbreak, but the only thing that happened is that my wp-config points to a no-long-existing database. Editing that by hand will probably suffice. I can only try that when back home.
Even installing the fresh copy of WordPress won’t overwrite your old tables.
Just one more question, (for me and people as stupid as myself). WP immediately prompted to install, so I did. Undoubtely new wp_ tables were created. That doesn’t change anything to the wp-config story, right? Change it and let hackers make their injections in not-used wp_ tables (or just delete them again).
And this is why I have a test site. I only learn by trial and ERROR 🙂
Your database is not “no longer existing” unless you removed it.
Neither WordPress nor my plugin can remove a database.
I’m not sure what you mean by wp-config story, or about the not used wp-tables.
When you used the auto table name changing functionality of the plugin, but failed to read the line telling you to ensure your wp-config.php is writable, the plugin was unable to change the wp-config.php along with your table names. When you browse to your website, one of the first things that happens is that WordPress checks wp-config.php to see what the table name prefix is, then it checks to see if any tables by that prefix are in the database. This is how it knows whether or not WordPress has been installed. Since your prefix in wp-config.php didn’t match the ones in the database, WordPress had no way of knowing they existed. When you went through the installation, it created new tables in the database. However, it would not have overwritten your original tables. They should still be there. If you change wp_ to tst_ or whatever you changed the table names to, then your website should show up.
Just a comment… for your benefit and for anyone else reading this… if you change the wp-config.php permissions to writable, please make sure you don’t forget to change it back, just like with any other file that you temporarily make writable.
That was exactly what I tried to say 🙂
And I suppose that when I check my database now, I’ll notice that I have both wp_ and the same tables with tst_ prefix (since I reinstalled WP).
-And don’t answer this question if I take too much of your time, but how is changing the prefix safer. Of course, in all WP installations the tables have the same name, but the databases don’t, so it is (relatively) easy for a hacker to access the database directly other than by exploiting WP?
Michael, one more question about your plugin.
When I click on “scanner” I get a red line for my themes folder. It is Chmodded 555 and you recommend 755. Is it just red because my chmod is not the same? 555 Is ‘better’ than 755, right? If nobody can put anything in the folder, not even myself. Or…?
You’re correct. It’s in red because it isn’t exactly the recommended setting. A later release will show green if it <= the recommended setting.
Perhaps three colours:
1 red: unsave
2 green: recommended
3 yellow: even better
Something like that. I’ll stick to my Chmods for now.
Thank you again for your quick answer.
Well the problem with that is that while the recommended settings are ideal for 99% of people, different people have different needs, as well as different server setups.
Say, but since you’re online anyway, I’m struggling with this:
.htaccess ../.htaccess 0644 755.
A little more of the path would be nice. I have several htaccess’ but I can’t find the 644 one!
 I found the one, somehow it wasn’t on top of the files, but somewhere around the bottom.
Michael, I know I’m nagging again, but I do have another question.
I change the file permissions of the wp_config, change the database prefix and wp_config and without doing anything, the chmod is back to what it was. Is this a feature of your plugin, or some weird thing of my host? (The latter would explain some things.)
Pfff, I’m done. If you follow instructions, this plugin works like a charm. I also used the occasion to change usernames and passwords of the database users (not using the plugin of course) which wasn’t very funny since my host has some strange demands for passwords so I messed up a couple of times. But all came out just fine in the end.
The path starts at the same root for each file/directory. Remember, .htaccess files are hidden from many file explorers, including ls at the command line. Only your hosting company can tell you how to see it from your control panel, from the command line just type ls -a.
I’m not sure what you mean by back to what it was, but I assume as is well.
If you change your database user and/or database password, just make sure you change it in wp-config.php also. I’m assuming that since you aren’t having a problem that you’ve done that (the site would have a hard time coming up otherwise).
I’m glad I was able to help you. You asked good questions. Feel free to mark this thread as resolved 🙂
- The topic ‘[Plugin: WP Security Scan] “Welcome to WP, please install your blog”’ is closed to new replies.