Clients often ask for fuzzy, non-standard, maybe weird and not always logical permalink structure for their sites. If you’re now working with such a client, consider yourself lucky, because the brand new Rewrite Rules Inspector plugin is here! Props to the WordPress.com VIP team :)

Jetpack 1.3 has been released, and it now ships with the Grunion Contact Forms plugin, the very same forms plugin that’s running (behind the scenes) on WordPress.com. The update fixes a couple of small bugs as well. You should be able to download it from your Dashboard very soon.

How to write a terrible WordPress tutorial: “Do X without a plugin. Just paste Y into your functions.php!”

— Evan Solomon (@evansolomon) April 11, 2012

True, and here’s a related post I wrote earlier about Plugins vs. Without a Plugin. Still, we keep seeing such tutorials piling up everyday, even obvious ones like Google Analytics.

Why would one want to go through the trouble of copying and pasting code into their theme’s header.php file, and then breaking everything when they change their theme or when the theme gets an update? Why not just use a plugin that will retrieve the analytics profile via OAuth?

Is it considered “cool” to copy/paste all my plugins into my theme’s functions.php file? If so, I might just try it out right here on my site! And since I’m running multisite with quite a few different sites, I’ll have to do that ten times for each plugin that I need to use. Then maybe use constants to indicate which snippets I want active and which ones I don’t. *

And as soon as I end up with a 5000-line functions.php file, I can go complain that WordPress is too difficult to learn, and that it’s a pain switching themes or domains, and maybe blame Otto for absolute URLs too. *

* Sarcasm

Considering doing a new WP plugin. I’d call it “inbound marketing for WordPress”, does the same as my SEO plugin, but paid :-P

— Joost de Valk (@yoast) April 9, 2012

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!

Wow! Congratulations @michaeltorbert! All in One SEO Pack for #WordPress reaches 10,000,000 downloads wordpress.org/extend/plugins…

— Konstantin Kovshenin (@kovshenin) February 27, 2012

Yes, the tweet button is doing a great job these days, but let’s admit, that we content publishers enjoy retweets more than regular tweets to our articles, because:

• They show your name and your Twitter avatar along with the original message, so when others see your tweet retweeted, there’s a better chance they’ll follow you.
• They instantly show up in your Interactions and increase the retweet count, so you can always see who’s tweeting your posts, without having to use Twitter’s search.
• They give you a better chance to get a Top Tweet, thus providing even more exposure.

With the use of Twitter’s Web Intents I was able to create a small extension for Sharedaddy (bundled with Jetpack.) It allows the use of a retweet button as one of the sharing options.

It currently fetches the post meta for a retweet-id key which has to be the id number of the original tweet on Twitter. You can use the Custom Fields interface to enter the retweet-id value, but will probably wrap this up in a meta box, where one could just give the URL of the tweet.

As soon as there’s a retweet ID associated with a post or page, the retweet button will show up, and when clicked, it will popup a web intent with the option to retweet.

However, if a retweet ID has not been supplied, the retweet button will fall back to the original tweet button shipped with Sharedaddy, so make sure you don’t use the two together :)

Download

The plugin is still very rough and I thought I’d give it a test drive here on my blog, before sending it out to the public plugins directory. Obviously there probably are some bugs, cross-browser issues and css overhead. You can follow the plugin project on Github and make sure you have activated Jetpack or Sharedaddy before using the plugin.

Thanks for stopping by, and feel free to share your thoughts and comments. Let me know if you’d like to contribute to the plugin, so I can give you push access on Github. I appreciate retweets too!

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!

class Some_Plugin {
    function __construct() {
        add_action( 'admin_init', array( $this, 'admin_init' ) );
    }

    function admin_init() {
        // Whatever
    }
}

If you don’t, then you can stop reading now :) I’m addressing the naming technique here, the fact that admin_init is both an action tag, and a method that you assign to that action tag. So if I’m naming all my methods after actions and filters tags in WordPress, isn’t there a way to cut down the burden of having to add_action and add_filter all the time?

I’ve been thinking of an approach that could solve this problem in both, an easy to understand way, and a compatible way. Perhaps we’re lacking a WP_Plugin class in WordPress that would take care of this (along with a bunch of other things) for us, so that we can focus on writing our plugin, and not spend time matching tags to methods.

Here’s a concept that first popped into my mind, experimental and buggy, but something to get our heads thinking about it. If your class extends the WP_Plugin class, and your method’s name starts with a double-underscore prefix (or any other convention we may choose), and matches an existing action or filter, why not run the action or filter automatically without having to add_action or add_filter?

class Some_Plugin extends WP_Plugin {
    function __admin_init() {
        // Will run during admin_init
    }

    function __the_content( $content ) {
        // Will filter the_content
        return $content;
    }
}

Again, it’s just a thought and a lot of decisions should be made before implementing something like this. I went ahead and drafted a plugin file which works well to some extent. You can change the method name convention on line 18.

So my questions to you, dear reader are: is will this make things easier for the WordPress developers? Will this mess things up? What do you think of the prefix convention? How would you propose to handle the priority dilemma? What else could go into a WP_Plugin class?

Update! It seems like Reflection is a better approach at what I’m trying to do, and separating actions from filters logic too. Thanks so much for the heads up Ryan McCue, Kaiser and Daniel Dvorkin. Here’s Ryan’s improvement over my first Gist.

Thanks for stopping by and subscribing!