How-To: Reset WordPress Database to Default Settings

wpdb-reset

Easily Reset Your WordPress Database

WordPress Database Reset is a WordPress plugin I recently came across that will at some point prove very, very useful to me.

It’s not often that I need to reset a production WordPress database to it’s default settings, but this plugin will make the task a whole lot easier. Chris Berthe, the author, describes the plugin like this:

WordPress Database Reset is a secure and easy way to reinitialize your WordPress database back to its default settings without actually having to reinstall WordPress yourself.

I can see this being crazy useful for WordPress plugin and theme developers. We frequently need a fresh database to work with, so I’ll be adopting this plugin in my WordPress plugin and theme development workflow from here on.

WordPress Database Reset requires WordPress 3.0+ and can be installed just like any other WordPress plugin. It’s in the WordPress Plugin directory, and can also be found on GitHub.

If you’re a WordPress theme or plugin developer, you should definitely check it out.

How-To: Add Minimal-UI Viewport Meta Tag to WordPress

minimal-ui-example

Introduced with iOS 7.1

I don’t have an iPhone, but my daughter does have an iPad Mini, which is running the latest iOS, 7.1. However, this only works for those of you on iPhone’s, so I see no difference. :

Martin Wolf was kind enough to let me use the image from his post about this subject so that I could more easily illustrate the difference. So, even if you don’t have an iPhone, you can still see the changes this makes in the featured image above.

With the release of iOS 7.1 (and possibly late 7.0.x builds), Safari introduced support for a new value in the viewport meta tag. To me, it sounds like it adds effects similar to how Chrome hides its top bar when a page is loaded, but more. For example, the navigation buttons at the bottom are hidden.

I rarely use Safari, like never. Chrome is available on iOS, so that’s what I’ve always used. That’s not to say that you shouldn’t support Safari to it’s fullest, because I’d wager that a majority of iOS users stick with the default, which is Safari.

Chances are, your theme already has a viewport meta tag defined in it’s header.php file. If it does, add minimal-ui to it, so it should look something like this:

If your theme doesn’t already have a viewport meta tag set, you can add one with your functionality plugin or theme’s functions.php file like so:

Adding the code above will add a brand new viewport meta tag for you, so only use that if your theme isn’t already using a viewport meta tag in it’s header.php file.

That’s it!

WordPress: Sending Correct HTTP Status Code on Login Failure

login

For some reason, WordPress will send a 200 HTTP response status code, or OK, when a login attempt has failed. Why not send a 403 status code, which is designed specifically to say you can’t be here, or forbidden, actually. There’s even a better alternative to 403, but stay with me.

I came about this bit of information while reading this post by Konstantin Kovshenin. And was able to confirm it myself by logging into this site incorrectly, as you can see in the featured image above. wp-login.php is returned as 200 OK and is circled in red.

So, as Konstantin suggested, we can use this code to send a proper 403 Forbidden status code on a failed login attempt:

But why send a 403, which is Forbidden? It’s not truly a forbidden page, as people have a legit reason to be there, even if they can’t remember their password.

So, sending 401 Unauthorized as the HTTP response status code may be even better.

So, you can use either of those, the first chunk to send a 403 Forbidden response, and the second for sending a 401 Unauthorized response code.

On login failure, send "401 Unauthorized" or "403 Forbidden" HTTP response code?

View Results

Loading ... Loading ...

Either could go in the functions.php file for your theme, or more likely, in your WordPress functionality plugin.

You can find a good list of HTTP response codes at the Mozilla Developer Network site.

WordPress Plugin: Thumbnail Viewer 1.2

I’ve released version 1.2 of the Thumbnail Viewer plugin for WordPress (actually released like 2 weeks ago, just now announcing). Not many changes were made in 1.2 except the fixed paths to the css and javascript files. The incorrect paths totally prevented the 1.1 from working for people who downloaded from the WordPress Plugin Directory.

Go Download Thumbnail Viewer Plugin 1.2

Shortly after the release of 1.1, I started hosting thumbnail viewer at the WordPress.org Plugin Directory. Hosting there gives me access to a Subversion repository, which I had never used before. Hosting at the WordPress Plugin Directory gives the plugin greater exposure and provides me with a central place to store all the code.

Version 1.2 was prompted when I started getting a bunch of people contacting me saying the plugin was not working. I got right down to it and realized the plugin was looking in the wrong directory for thumbnailviewer.css and thumbnailviewer.js. I renamed some directories before moving the project to the WordPress Plugin Directory and forgot to update the directory names in the PHP code.

So, version 1.2 was basically just a fix for the incorrect directory names. Until I can get a dedicated page setup here for thumbnail viewer, please see the announcement post for version 1.1 for installation directions and examples. There’s also some pretty helpful comments in there.

Go Download Thumbnail Viewer Plugin 1.2

If you’re still running version 1.1, there’s nothing your missing in 1.2. However, the directory format in 1.2 is how it’s gonna be from now on, so you might as well upgrade. You can download from the WordPress Plugin Directory. The latest, most up-to-date version will always be on that page.

UPDATE: Finally!!! I’ve taken the time to create an official page for my Thumbnail Viewer plugin. Please try to keep all the support related questions centered on that page. The announcement post for version 1.1 still has some pretty helpful comments though, I may decide to move them to the new page at some point.

WordPress 2.2 Adds Tags

The NeoSmart Files noticed the addition of native tagging support to WordPress 2.2 in the SVN repository. What’s this mean for WordPress bloggers? Not much really, other than the fact you’ll no longer have to use a third-party plugin for tagging your posts or pages.

This is great for WordPress, tagging is something I expected to see with the release of 2.0, but that didn’t happen. Tags are something bloggers really want, native tags will just make WordPress an even more attractive blogging platform.

I’m going to have trouble leaving the Ultimate Tag Warrior plugin behind in favor of the new tagging system in WordPress 2.2. Ultimate Tag Warrior has been so nice to work with and is pretty much the de facto WordPress plugin for tags. Ultimate Tag Warrior has some features not found in the tag system native to WordPress 2.2, such as tag suggestions. Also, Ultimate Tag Warrior allows you to apply tags you’ve used previously to a post via a select form, something not found in WordPress 2.2 tags. Hopefully the WordPress team has those features planned for inclusion at some point.

Anyway, head over to The NeoSmart Files for more, they have a screenshot comparing Ultimate Tag Warrior to native tags in WordPress 2.2.