Posted on August 6th, 2014 No comments
If you want a quick and easy way to boost the security of your WordPress blogs, a simple, fast and easy thing you can do is to place a password on your wp-admin directory. CPanel enables this in a moment, just by going to the “Password Protect Directories” feature within CPanel.
Password protecting directories works following these simple steps.
- Click Password Protect Directories
- Navigate to public_html by clicking on the folder ICON
- Click the folder name link (NOT the icon) for wp-admin directory
- In the dialog, enter a username and password and save the details under the User portion
- In the dialog, choose to Enable Protection and give it a name, like ‘Top Secret – No Entry’
- Save it and then in another browser tab, navigate to yoursite.com/wp-admin
Now if you’re like me, your wp-admin is broken with a message, “The page has caused a redirect loop”
You google something like wp-admin htpasswd redirect loop, and find suggestions how to fix it… and find some blog posts like this or that, but you ask your web host about it, and they don’t let you modify httpd.conf config file.
What to do?
It turns out the answer is simple, you just need to edit your .htaccess file and add the following line at the top.
ErrorDocument 401 default
If you followed the steps above, the CPanel interface created an .htaccess file for you automatically. Go to the file editor feature within CPanel now, and find this new file inside the wp-admin directory, and click edit. Paste the line at the top, save it, refresh wp-admin, and you should be now seeing a dialog asking for your username and password — the one you set at step 4 above. The final .htaccess file including the password protection we added should look like this when you’re done:
ErrorDocument 401 default
AuthName "Top Secret - No Entry"
Note, do not edit the path for the AuthUserFile – it will be unique to your account and CPanel configuration. This adds a 2nd layer of protection in front of your wp-admin directory in addition to your existing WordPress administrator username and password.
Posted on February 25th, 2012 No comments
Things I learned while attempting to build a custom WordPress plugin…
A) The documentation is far from clear.
B) There’s lots of ways of doing it
C) Many blog posts exist around the net with tutorials and examples, and many of them are outdated
D) Proper, logical coding practices and assumptions do not work.
E) You have to just mess with it until it works.
“The world is already flooded with blog posts about how great W3 Total Cache is and how terrific Super Cache is and how fantastic Bat Cache is. Surely one of these will work for me,” I think to myself.
But alas, I tested using each of these plugins on my site and none of them really did the trick. W3 Total Cache actually broke my theme completely and threw errors; Super Cache didn’t help much either. And Bat Cache was just complete rubbish. Discouraged, I decided to write my own plugin from scratch. So, off I go.
I’ll write a custom caching plugin that uses Memcache.
After a week of off-and-on development, I got my caching plugin working extremely well: What was up to 15 seconds is now sub 300ms! Same page, same WP Multi-site, one plugin with only about 300 lines of code. But it only works in a highly-controlled environment. I want to put it up on the WordPress site so others can use it, but before I can release it into the wild, I need to make sure it’s really polite about errors and easy to work with.
Specifically, I have these 3 simple goals to finish it up:
1) If you don’t have the Memcache extension installed when you try to activate the plugin, it needs to display a warning message about missing extension;
2) I want to use the standard h2 error message to display this error to the user; and
3) I want the plugin to remain deactivated if activation fails.
You would think the WordPress Codex, Plugin Resources and Plugin API Documentation would be chock full of great examples for Plugin developers, wouldn’t you? I did, too, but unfortunately this just isn’t the case.
I’ll give examples of A through E above, and hopefully explain how I was able to achieve the proper implementation points of 1, 2 and 3.
How do you handle WordPress Plugin Activation errors gracefully?
This post says to use the wp_die( ) function.
I tried that and it actually does prevent the plugin from getting activated.
This post suggests that you should just let the fatal error happen and display a slightly better error message in a status box. Terrible idea, IMO.
Better to use this. Render red error messages in h2′s like this post shows. I’m trying to combine these concepts into a single, elegant solution and having a real rough time of it.
I think the only way to do it is like HungryCoder says, you have to freaking ob_start and catch the error with output buffering…
Posted on August 5th, 2011 No comments
It may come as a surprise to you, just like it was to me, to find hundreds of personal photos from Matt Mullenweg’s trip to Alaska in MY WordPress blog database.
Seriously, folks, this is rather rude in my opinion. I invite you to Check your wp_options table for instances of ma.tt and you may be quite surprised what you find.
SELECT * FROM wp_options WHERE option_value LIKE '%ma.tt%'
To be fair, the actual photos aren’t in my database, but useless links to them are. Apparently WordPress stores newsworthy feeds it receives (when is unclear – all day? when I login to wp-admin?) in the wp_options table.
I’m shocked and somewhat horrified to find thousands of rows of this useless junk mucking up my WordPress database unnecessarily. I’m not sure there’s any way to inject malicious code into a database through a news feed that is automagically stored, but it sure seems like a potential security risk to me. If there’s a way to turn off this storing of feeds, I’d like to know.