body.home .current-menu-item { display: none; }

If you’re not yet using wp_nav_menu to build your navigation menus, then, uhm, wake up! Also, the snippet relies on the body_class usage in your theme, and if your theme doesn’t use one, uhm, wake up! :)

I also want to avoid the discussion about how the primary navigation should be consistent through each and every page on the website, if at all possible :)

Speaking of defaults, NEVER SET DEFAULTS IN THE DATABASE. Not ever. The theme options you store in the DB should always, always, *always* be something the user has selected. If the user selects the default, then that’s fine to set in the DB. but you don’t set it in the DB just because it’s not set at all. get_theme_mod has a second option for the default value. So does get_option for that matter. Use this.

Otto Wood, WordPress Core Developer on Custom Admin Screens

Thanks, Otto, for clearing that up :)

add_theme_support( 'custom-background', array(
	'default-image' => get_template_directory_uri() . '/images/default-background.png',
) );

The default custom background image will be used when one is not set, or the user hits the “Restore Original Image” button in the custom background options. However, the old method should still be compatible with WordPress 3.4, unless you’re doing something wrong :)

However, sent e-mails cannot be deleted, once they’re out there, there’s no turning back. It’s not the best user experience to receive a “testing my twitter plugin” e-mail, right? Jetpack is one of the best ways to deliver e-mail notifications, about your new posts, to your subscribers. I wrote about it before and actually use it myself.

The best way to prevent all of this is of course to use dummy accounts or staging servers. The second best way to test your posts publishing out, is to wait for actual content (and if things didn’t work, try again next time), but sometimes we want to just try it out in our live environment, and if you do that, don’t forget to disable Jetpack subscriptions, which can be done in two easy steps. In the Jetpack configuration page under Subscriptions, hit Learn More and you’ll see a Deactivate button.

Don’t worry, you will not loose all your subscribers, they’ll start receiving notification e-mails, when you Activate the subscriptions module again on that very same page, and yeah, don’t forget to activate it back when you’re done “testing things out.”

That’s about it! How do you handle test posts you don’t want your subscribers to see? Can you easily deactivate the e-mails with other plugins and services such as Feedburner? Share your thoughts and comments and thank you for subscribing!

Tip: if you want to change the default theme in a #WordPress Multisite network, use: define( ‘WP_DEFAULT_THEME’, ‘themename’ );

— Konstantin Kovshenin (@kovshenin) March 16, 2012

It’s important for a network (WordPress Multisite) to have a valid default theme for newly created sites. The current version sets this to twentyeleven in default-constants.php. If your default theme isn’t installed or disabled network-wide, you might face some errors when creating new sites in the network. You can define WP_DEFAULT_THEME in your wp-config.php file.

Tip: don’t use esc_url() with wp_remote_get() and other HTTP functions. Use esc_url_raw() instead. #wordpress

— Konstantin Kovshenin (@kovshenin) March 13, 2012

This tweet gained some good attention on Twitter, so I thought it would be good to explain why. Then I found a support forums thread where Mark Jaquith pretty much explains it all:

esc_url() is for something like <a href="SANITIZE_THIS">text</a>

So if you’re going to use the URL in your HTML output, like a href attribute for a link, or a src attribute for an image element, you should use esc_url().

esc_url_raw() is for other cases where you want a clean URL, but you don’t want HTML entities to be encoded. So any non-HTML usage (DB, redirect) would use this.

The esc_url_raw() function will do pretty much the same as esc_url, but it will not decode entities, meaning it will not replace & with &#038 and so on. As Mark pointed out, it’s safe to use esc_url_raw in database queries, redirects and HTTP functions, such as wp_remote_get.

Oh, there’s now a codex entry for esc_url_raw too!

Daniel Bachhuber of Automattic’s WordPress.com VIP team, gave this awesome talk at WordCamp Phoenix 2012 earlier this year. He walked through some things developers are overlooking when working with WordPress, and some great tips and tricks to speed up your development workflow.

One thing I learned from that talk is that I should stop using Textmate’s “search in project” and use ack instead, which is faster, available in the command line environment (no need for GUI), and has a bunch of options for output customization. By the way, here’s how you install ack on OS X:

• Download and install MacPorts if you haven’t already.
• Open your Terminal and type sudo port install p5-app-ack

You can find the notes and slides to the presentation on Daniel’s blog, and by the way, it was originally called “Five tenets to mastering WordPress development” :)

Hope you enjoy the video and feel free to share your thoughts in the comments section below.

However, the valid reason I seem to have bumped in, is the fact that sometimes you would want to use a specific size for an image, but only once, for one post or page. The add_image_size function here will add a lot of overhead, crunching all the uploaded images into the size you want to use only once. Like a shortcode that can resize and crop an image from your media library to whatever dimensions you tell it to:

[image src="http://example.org/wp-content/uploads/2012/03/image.png" width="150" height="150"]

Right, a shortcode (argh!) to dynamically resize an image. Fair enough, a lot of premium themes seem to have something similar, but mostly use TimThumb because it’s so simple. However, I’ve created an image shortcode function that resizes and crops images from the media library on the fly using the image_make_intermediate_size function available as early as WordPress 2.5!

It saves the resized image on disk, and returns the absolute URL to that image. Of course you’d want to add things like captions, alt tags and so on, but the basic idea is there. Why is this better than TimThumb?

• It stores the image files on disk and uses absolute URLs to those images, meaning you won’t have problems hosting your thumbnails on a CDN.
• It uses functions native to WordPress and works with the WordPress media library, so extra files are deleted when an attachment is deleted — no more junk in your cache/folder.
• It doesn’t have a zero-day vulnerability :)

There are drawbacks too, like the fact that it’s a shortcode! Although I’m pretty sure we can use the same technique and hook it directly to the content, bypassing the shortcodes madness. Oh, and it doesn’t support remote files too, only the ones in your media library, but that’s a good thing, as we have all figured out by now.

Feel free to fork the Gist on Github and experiment with the code, I’m sure you can think of how to make it better, easier to use and faster. Thoughts and comments welcome, and thank you for stopping by!

Dear theme developers, WordPress has a billion functions to work with images, look at image-edit.php and stop using TimThumb! #tech

— Konstantin Kovshenin (@kovshenin) March 3, 2012

Just a reminder, since this weekend I had to help out with yet another TimThumb-powered WordPress theme, broken by a “security patch” at the web hosting provider. This time it was Acquisto by Press75. The problems of Acquisto are not limited to thumbnails.

The major difference is behind the scenes — when most post subscription plugins will use the wp_mail function to distribute your new post (using sendmail from your server or an SMTP account,) Jetpack will simply send your new post to the WordPress.com server, which will take care of the distribution for you.

Why does that matter? I can name several reasons:

• The WordPress.com mail servers can handle far more load than your shared hosting server, VPS or dedicated server, so e-mails will (most likely) be delivered on time and to everyone.
• People enjoy reading posts from one place. RSS feeds is a good option, but so is the WordPress.com Read module.
• People can manage their WordPress.com and Jetpack-powered subscriptions in one place, choose between immediate e-mails, daily digests and IM notifications, as well as choose between HTML and plain text e-mails.
• You can use Stats in Jetpack to track your blog followers.

However, there are drawbacks too, the major one of which, is that you don’t have control over the actual markup in the e-mail that’s being sent, so no advertising, changing colors and so on. But, we can live without that, right? :)

The Subscription Form

The easiest way to enable e-mail subscriptions, is to use the sidebar widget that Jetpack comes with. You can find a great tutorial on the Jetpack website, however, today I’d like to show you how to totally customize that part by using your own form, handler and calls to the Jetpack API.

Note that to get this working, you will need public WordPress site with Jetpack enabled and linked to your WordPress.com account. So let’s begin with a simple form, somewhere in your theme template files:

<form method="POST">
    <input type="hidden" name="my-form-action" value="subscribe" />
    <input name="my-email" value="" placeholder="Enter your e-mail" />
    <input type="submit" />
</form>

That’s easy enough to understand, right? A hidden field that would tell us when the form is submitted, an input field for the e-mail address and a submit button. A nonce field would be very useful too, but let’s try and keep it simple.

The Subscription Form Handler

Next, you will need something that will handle the form submission, somewhere in your theme’s functions.php file or preferably a plugin file (here’s why.)

add_action( 'init', 'process_my_subscription_form' );
function process_my_subscription_form() {
    if ( isset( $_POST['my-form-action'] ) && $_POST['my-form-action'] == 'subscribe' ) {
        $email = $_POST['my-email'];
        $subscribe = Jetpack_Subscriptions::subscribe( $email, 0, false );
        // check subscription status (to be continued)
    }
}

This is quite simple to follow along too, we’re checking whether the form was submitted and then using the subscribe method of the Jetpack_Subscriptions class, which takes three arguments — e-mail address, a post ID (if you were subscribing to comments) and a boolean value for async versus sync calls. You shouldn’t worry about these for now.

This form handler, together with the above form, will already allow users to input their e-mail addresses and hit the submit button. They’ll get a notification to their e-mail address to confirm their subscription, and if they do, they’ll start receiving new posts from your website. Hurray! But wait…

Subscription Status Feedback

The problem, however, is that we haven’t provided any feedback about their subscription: was it successful, or are they already subscribed, or maybe they entered an invalid e-mail address. For this purpose, we should look at what the Jetpack subscribe method returned, and check for success or errors.

We don’t have to reinvent the weel here, but rather use the same code that is used in Jetpack’s e-mail subscriptions widget, right after calling the subscribe method:

// check subscription status
if ( is_wp_error( $subscribe ) ) {
    $error = $subscribe->get_error_code();
} else {
    $error = false;
    foreach ( $subscribe as $response ) {
        if ( is_wp_error( $response ) ) {
            $error = $response->get_error_code();
            break;
        }
    }
}

if ( $error ) {
    switch( $error ) {
        case 'invalid_email':
            $redirect = add_query_arg( 'subscribe', 'invalid_email' );
            break;
        case 'active': case 'pending':
            $redirect = add_query_arg( 'subscribe', 'already' );
            break;
        default:
            $redirect = add_query_arg( 'subscribe', 'error' );
            break;
    }
} else {
    $redirect = add_query_arg( 'subscribe', 'success' );
}

wp_safe_redirect( $redirect );

Although quite long, the code above is very easy to understand. We’re checking the $subscribe variable (returned from Jetpack) for whether it’s an error or an array of errors. If it’s an error, we read the error code, and change the subscribe query argument accordingly, with add_query_arg. This will add, for example, ?subscribe=invalid_email, to our current URL.

If there was no error, we use success for that very same query argument. Finally, we redirect to our newly constructed URL. It’s much easier to understand when you’ll see this in action.

At this point, you can test again by trying to subscribe, and you’ll see that the page is being redirected with the subscribe query argument added each time, showing the status of the subscription. Go ahead and enter an invalid e-mail address.

The Subscription Form (again)

Let’s return to our theme template where we rendered our subscription form and tweak it a little bit, based on our subscription status:

<?php $status = isset( $_REQUEST['subscribe'] ) ? $_REQUEST['subscribe'] : false; ?>
<?php if ( $status == 'invalid_email' ) : ?>
    <p>You have entered an invalid e-mail, please try again!</p>
<?php elseif ( $status == 'success' ) : ?>
    <p>Thank you for subscribing! Please check your e-mail to confirm.</p>
<?php else : ?>
    <form method="POST">
        <input type="hidden" name="my-form-action" value="subscribe" />
        <input name="my-email" value="" placeholder="Enter your e-mail" />
        <input type="submit" />
    </form>
<?php endif; ?>

The first line will read the status into a variable, and then a check for the status with the relevant messages. I haven’t included all statuses for brevity, but you should have a couple more elseif blocks for “already” and “error”. Voila!

What’s next? Well it’s up to you: you can customize the form however you like, you can redirect your visitors to a “thank you for subscribing” page (in the form handler,) or you can even send them an e-mail thanking them for their subscription :)

That’s about it! What’s your favorite way to handle e-mail subscriptions on your blog? What about newsletters, have you tried Jetpack to send out newsletters, or have you got a different preferred way? Share your thoughts and thanks for stopping by!