|wordpress table prefix|
Pros and cons of changing default wp_
| 7:39 pm on May 13, 2009 (gmt 0)|
I am fairly new to wordpress, have moderate html/php/mysql skills.
Looking at security for wordpress blogs, have implemented all suggestions except changing the table prefix.
I have searched this forum and cannot locate any posts on this topic.
There is a plugin that helps with this and I have found documentation on other items that need to be changed so I am pretty confident that I can do it.
How will this affect future plugins? Will they know about the new prefix?
Are there any other gotchas to look out for?
| 8:16 pm on May 13, 2009 (gmt 0)|
Hey Jean - I have never done it, but you might like to have a look at the comments of cmarshall in this regard in the thread on Securing Wordpress [webmasterworld.com].
| 10:07 pm on May 13, 2009 (gmt 0)|
Well, I have decided that unless i change the names of the wordpress logon page to be something other than wp-login.php, changing the table prefix to something other than wp_ for security by obscurity is useless as entering the blog address plus this file name will take the hacker to the sign in page.
I have removed all the very obvious signs that it is a wordpress blog and left it at that.
Instead, I installed .htpasswd protection for the wp admin so that a potential hacker has to know two login ids and two passwords in order to hack the blog. Allowing updates from only specific IP addresses via .htaccess is an additional layer. Also, via .htaccess, limiting the file types than can be updated in wp-content to images is adequate for this blog so i've done that as well. Another suggestion to limit file types in wp-includes disabled adding links to a post so i didn't go that route. Once I've figured out how to fix this, I will add this limitation as well.
Also, reading the thread you so helpfully provided, and links from it, it becomes clear that the best additional protection is to:
regularly back up the blog
so I installed an automatically scheduled back up plugin
be choosy about plugins especially avoiding those allowing php execution in posts
be sure that wordpress and all plugins are latest versions
dont hack your system so that it is difficult to upgrade - i always use the KISS approach!
use strong passwords: the ones generated by the password tool are excellent
| 4:03 am on May 14, 2009 (gmt 0)|
>>I installed .htpasswd protection for the wp admin
Good idea. I don't know why that isn't mentioned more often.
Like I said in the thread, I fugure eventually, you get hacked, so I wrote a small shell script that runs as a cron job every night and emails a backup to a gmail account. I mirror all the media files on two computers. So if hacker succeeds, I lose one day. Not ideal, but it saves me a lot of worry.
| 4:16 am on May 14, 2009 (gmt 0)|
Yes, there is a back up plug in that will save or email me a back up hourly/every 12 or 24 hrs or weekly.
The one I installed is called WordPress Database Backup by Austin Matzko
If you install a plug in such as this it is a good idea to test that restoring from the back up actually works.
I test by restoring a version on my local XAMPP server so that if it doesn't work, I don't clobber the live database.
| 4:23 am on May 14, 2009 (gmt 0)|
I wonder how it can keep track of time if it's being set from the plugin interface and not a cron job.
I suppose the plugin does a "poorman's cron" and every time a page it loaded it takes a timestamp and compares it to the last backup timestamp, and then fires the DB backup.
The downside to that is that unless my guess is wrong, it's going to fire the backup job while, by definition, someone is at your blog.
Of course the downside of the cron job is that it fires at 1am Texas time whether it's busy or not (but since most 90% traffic is US it's not usually busy) at those hours.
| 4:44 am on May 14, 2009 (gmt 0)|
The documentation says it uses the wordpress built in cron.
Just scanning the code, I cannot tell how it decides what time to run the cron job but I have asked the author and we'll see what he says.
| 4:26 pm on May 14, 2009 (gmt 0)|
Okay, that's probably a poorman's cron like in Drupal. A PHP script can't know what time it is, so it has to be fired based on a page access.
| 5:49 pm on May 14, 2009 (gmt 0)|
When I ask it to schedule, say 24 hours, the first backup is 24 hours from now. There is an option to change the backup time.
Poor man's cron, it works for me. I have it set to back up at 4 am.
| 6:23 pm on May 14, 2009 (gmt 0)|
>> I have it set to back up at 4 am.
Yup, but you understand that if nobody visits the site between midnight and 8am, the backup will occur at 8am, right?
Of course, to a large extent, it's academic because if nobody visits during those hours, no harm done.
If you want your cron tasks to occur at a specific time, whether there's a page request or not, and your host allows cron jobs, you can create a true cron job that will fire every day at 4am. All you need to do is point a cron task at you wp-cron.php file (that's according to the documentation, I use the native MySQL commands, so I've never tried that).
Your posts got me thinking about it, though, and the same is true if you want a future schedule post to go live a precise time and you get very little overnight traffic.