How To Empower Your WordPress Visitors With Post Reading Times

When you get a visitor to your site, you want them to stay there as long as possible and information that you can give them that will help is worth the effort.

Estimated reading time for posts is a great example of the extra information and is used by recent new sites Medium.com and by ManageWP.org to let their users know what time investment is required for each post.

In this article, I’ll show you how to add reading time to your site, without having to edit your theme.

Reading times provide valuable information and greatly improve the user experience
Reading times provide valuable information and greatly improve the user experience

There are a few plugins in the WordPress plugin repository that cover reading time but none do exactly what I am looking for.

For the same reason that you shouldn’t add analytics to the theme, I want the reading time insertion to be independent of the theme so that I can swap themes and still have the reading time appear. Or that I can stop displaying reading time by simply disabling the plugin.

I found a plugin that was close, Post Reading Time by Bostjan Cigan, and using that as my base I’ve altered it to better suit my requirements and will hopefully be useful for you to.

I’ve made the following changes to the original plugin:

  1. Calculating and storing a word count for when the post is published and storing it in a custom field, rather than calculating it at the time of output.
  2. Automatically adding the reading time message to the title
  3. Adding a stylesheet to the page header to allow styling of the reading time text
  4. Changing the settings to allow a format for the reading time message to be specified

I’ve kept the original plugin’s widget so you can also display the reading time in a sidebar.

And, of course, it’s all tested on WordPress 3.7.1.

The Reading Time Calculation

The calculation for the reading time is as simple as:

number of words / words read per minute

So, 1000 words at 200 words per minute is 5 minutes. You can set the words per minute in the Settings > Post Reading Time

Formatting the Output

I’ve introduced some simple formatting for the output message. The format uses  %min% and %sec% as placeholders for minutes and seconds respectively.

If you don’t use %sec% then the minutes will be rounded up.

For example, for a 4 minute 35 second reading time,

  • %min% minute read = 5 minute read
  • Reading time: %min% mins %sec% secs = Reading time: 4 mins 35 secs

If the minute is 1 then “minutes” becomes “minute” and “mins” becomes “min” if used in the format.

Download the post-reading-time plugin and see what you think.

For those of you with an interest in plugins, I’ll quickly step through the more interesting parts: I’m not going to worry about the calls to the Widget and Settings APIs.

Calculating and Storing the Post Word Count

The original plugin was calculating the reading time for a post every time the post_read_time function was called.

I think this is overkill, so I’ve added code to the publish_post hook to calculate and store the word count in a custom field when a post is published or updated which shortens the reading time calculation. I’ve used the word count so that the format of the reading time message can be changed and all posts will immediately reflect that change.

// Calculate the number of words for a post and add this to a custom field

function readtime_publish_post( $post_id ) {

// get the post content

$content = apply_filters('the_content', get_post_field('post_content', $post_id));

// count the words
$num_words = str_word_count(strip_tags($content));

// store the result in a custom field
update_post_meta($post_id, 'word_count' , $num_words );


// hook the function to the publish_post action
add_action( 'publish_post', 'readtime_publish_post' );

To cater for existing content, this same function is called when the reading time message is being generated in the front end and the word count is missing, meaning that the calculation still takes place and that the word count is stored on the post.

Here’s how the reading time message is created:

function set_readtime( $post_id ) {

// if this is not a post then don't worry about a reading time message. You might need to update this if you have custom post types

if ( get_post_type( $post_id ) != 'post' ) return '';

// get the global options for words per minute and format

$words_per_second_option = get_option('post_readtime_wpm');
$format = get_option('post_readtime_format');

// get the word count value for the post
$num_words = get_post_meta( $post_id , 'word_count' , single);

// if the word count is not set - existing content - then let's set it now
if ( $num_words == '') {

readtime_publish_post( $post_id );

$num_words = get_post_meta( $post_id , 'word_count' , single);

// still no word count? outta here
if ( $num_words == '' ) return '';

// calculate the minutes and seconds

$minutes = floor($num_words / $words_per_second_option);

$seconds = floor($num_words % $words_per_second_option / ($words_per_second_option / 60));

// Check the format for %sec% - if not found in format then round up the minutes
if( strpos( $format , '%sec%' ) === false ) {
if( $seconds >= 30 ) {
$minutes = $minutes + 1;
$seconds = 0;

// construct the reading time message

$readtime = str_replace( '%min%' , $minutes , $format );
if ( $seconds > 0 ) $readtime = str_replace( '%sec%' , $seconds , $readtime );
if ( $minutes == 1 ) {
$readtime = str_replace( 'minutes', 'minute' , $readtime );
$readtime = str_replace( 'mins', 'min' , $readtime );
return $readtime;


Being able to specify the format makes it more flexible and actually replaces three of the original settings.

You’ll also notice that the reading message is only being generated for posts. Ideally, the Settings would let you select from a list of custom post types but it’s not that sophisticated yet!

Displaying the Reading Time Message

I’ve kept the original post_read_time() function so if you do feel the urge to edit your theme you can use this function to output the reading time message.

However, I’ve also made use of the the_title filter to automatically add the reading time message whenever a post title is shown.

function readtime_the_title( $title , $id) {

// if we are in the admin interface then we don't need the reading time message

if ( is_admin() ) return $title;

// we only want to add the message to content, not menus, etc

if ( is_main_query() ) {
$reading_time = set_readtime ( $id );
if ( $reading_time != '' ) {
$title .= '' . $reading_time . '';
return $title;


add_action( 'the_title' , 'readtime_the_title' , 10 , 2);

Key things to note here are:

  • the check for is_main_query(): this stops titles in menus from having the reading time message appended.
  • the add_action call which hooks this call onto the the_title filter
  • the reading time message gets added within the title tag (


    ) so needs to be styled.

Styling the Reading Time Message

There is a small CSS file in the plugin directory that gets added to the header of the page via the wp_enqueue_scripts action.

I’ve used the most basic of styling and you’ll probably want to change it to fit your template:

h1 span.readingtime {

display: block;
font-style: italic;
font-size: 70%

/* hide message on single post pages */

.single-post span.readingtime {
display: none;


As the reading time message is wrapped in a span, I’ve changed the display to block so that it sits below the heading (remember it is actually contained with the heading tags) but you can just as easily keep it on the same line as heading by removing the display clause.

I’ve also hidden the message altogether on single post pages because I’m displaying the reading time message in a widget.  Playing with the CSS in this way, allows quite fine-grained control over where and when the message is displayed.

And that’s really all there is to it.

This is a very simple plugin that provides really quite valuable information to an all-too-often time poor site visitor. And anything that contributes to a better user experience has got to be worth considering.

Do you use reading time on your site? Do reading times affect your reading decisions when you visit a site?

Photo Credit : Fernando de Sousa

Download the plugin: post-reading-time plugin

How To Power Your WordPress Site With A Social Paywall

Yesterday, I looked at implementing a paywall on a WordPress site.

If you are just starting out or are using your WordPress site for reach then a monetary paywall will provide little benefit. A social paywall, though, might be just what you need.

In this article, I’ll look at how to implement a paywall where the currency is not cash, but Likes, Shares, Tweets and PlusOnes.

Social paywalls are a low-cost method for site owners to realise value from their content
Social paywalls are a low-cost method for site owners to realise value from their content

Implementing a social paywall is actually very similar to implementing a regular paywall. And just like a regular paywall, you need to think about the model you want to use and how receptive your audience will be to it.

You might argue that the cost in a social paywall is significantly less but you need to remember that not everyone will have a social media account or perhaps will be willing to “spend”. The same rules for your content apply: it must be compelling, unique and of value to the reader.

Warning! Premium Plugins Only Ahead!

Many of you will have noticed in yesterday’s paywall article that none of the reviewed solutions were free. In the context of an e-commerce scenario, I don’t see this as a problem. It seems perfectly reasonable to expect to pay for a plugin or service that will be used to generate revenue.

A social paywall generates value but obviously the realisation of any financial return is not immediate. So, when I started researching this article, I tested a number of free plugins. Unfortunately, not one was good enough to make the cut. I always leave debug messages on when I test and I was frequently met with notices about the use of deprecated functions (some as far back as WordPress 2.0), missing indexes and references to buttons on the editor page that no longer exist.

Now, I don’t want to get into a free versus premium debate. I’m certainly not knocking these plugins nor the developers who freely give a great deal of time and effort. But the bottom line is that the premium plugins I’m going to review cost a mere $19 and $21 respectively, so even if the free plugins have only minor issues, it doesn’t seem worth the risk when professionally developed and supported premium plugins are available for such small cost.

Pay With A Like by WPMU DEV

Cost: $19 (unlimited sites)

Pay with a Like is a solid, functional if visually unspectacular, social paywall plugin
Pay with a Like is a solid, functional if visually unspectacular plugin

Pay with a Like is structurally very similar to the Pay Per View plugin that we looked at yesterday. It allows global setting of the paywall and how excerpts are displayed which can be overridden on a post-by-post basis.

The paywall can be configured to provide buttons for Facebook, LinkedIn, Twitter and Google+ and whether a social share is required for every piece of content or just once per visit. Authorized users can be allowed to view any content without needing to social share (the role can be selected) which could work well in encouraging visitors to become subscribers.

The paywall can be switched off globally and applied only to specific content within the post, such as a downloadable file, video or audio. This is as straight-forward as enabling the paywall for the post, selecting the selection tool method, highlighting the content in the WYSIWYG editor and then using the custom toolbar icon to wrap the content in a shortcode.

Pay with a Like comes with very basic statistics, a running total of the various shares plus the top two most shared posts.

Pay with a Like is a solid plugin that would allow a site owner to quickly and easily set up a social paywall and works equally well for a global paywall or for individual content items.

Learn more about the Pay with a Like plugin.

Social Locker by OnePress (via CodeCanyon)

Cost: $21 (single site)

A better-looking social paywall with impressive statistical reporting

Social Locker by OnePress takes a different approach to Pay with a Like with its concept of the locker and allows for greater customisation and for multiple paywalls.

Multiple lockers can be created and each is highly configurable, from the text that appears to the visitor, the look and feel of the locker on the front-end and which buttons are presented. Social Locker provides no less than seven buttons, adding a Facebook Share, Twitter Follow and Google+ Share to the standard Like, Tweet, Share and +1 buttons.

Lockers can also have a timer interval which behaves like a YouTube advert allowing the visitor to simply wait a set time before the locker will disappear and the content is revealed. As with Pay with a Like, a Locker can be hidden for members.

A Locker is applied to content via the insertion of shortcodes. There is no option to allow access to all content after one share but a Locker is not repeated, so if the Locker appears on another post with the same URL (that is the URL is not blank and therefore using the current URL) it will be displayed.

Social Locker comes with impressive looking Google Analytic-style stats.

Find out more about Social Locker on the Code Canyon site.

Which To Use?

Either of these two plugins can provide a social paywall with the minimal of fuss. If you are interested in detailed statistics and want to be able to customise the look of the paywall then Social Locker is probably your best bet.

Alternatively, if you want to be able to implement the paywall globally and want to easily implement the one share per visit then Pay with a Like would be a better fit.

If you are looking at a solution for multiple sites then you might also want to keep in mind the differences in the licences.

Social paywalls are a low cost entry into the world of paywalls for both site owners and their audience and are a relatively straight-forward method to realise value from content.

If you are looking to extend your reach and build an audience then they are a method that is well worth considering especially if you are producing free whitepapers and ebooks.

Have you implemented a social paywall? If so, how and what plugins did you use?

Photo credit: Kismihok

WordPress Automatic Core Updates: Is Your Site Compatible?

Since WordPress 3.7 shipped and installations around the world began updating in the background to 3.7.1 over the weekend, the mild panic over automatic updates still hasn’t subsided.

This is despite lead developer Andrew Nacin’s attempts to assure everyone that background updates are “incredibly, incredibly safe”. Auto-updates was no doubt the release’s most thoroughly tested feature.

Also, WordPress 3.7 has been downloaded more than 1.7 million times… and is yet to break the internet.

The concern is that background updates site owners don’t test could break a site’s compatibility with certain plugins or themes.

Nacin addressed this issue in a comment at WPTavern, pointing out it’s important to keep in mind that minor releases of WordPress are fairly infrequent and usually security related:

In practice, minor releases are rare. The .1 release will always be needed to fix some bugs. Pretty much all others are security releases. Sometimes, the .1 also contains security fixes. A .2+ release is only going to happen for security reasons if there is a serious regression that somehow wasn’t discovered before the .1 release (which implies it probably wasn’t that serious).

Generally, then: .1 is a minor release with serious bug fixes. .2 is a security release and/or a critical regression fix. If you’re on 3.7, you’re going to want a regression from 3.6 fixed on your site. There’s really no reason to decline either of those releases. No, there is no differentiating in terms of how we version them, and we don’t plan to do so.

Finally: We have the ability to push out a minor release without having it auto-updated. We also have the ability to slowly roll out auto-update instructions. Essentially: We have a lot of tools at our disposal to ensure your site is getting exactly the fixes it needs. For more on this, read the definitive guide I wrote. I also talk about how this might mean more frequent minor releases, but that might just mean that .1 might be less of an omnibus release four to six weeks later, and is instead only a week or two later with a few important bug fixes.

Nacin has written a great in-depth and definitive post at Make WordPress Core on how to disable auto-updates, which should allay some fears about automatic updates.

Why Isn’t There an On/Off Switch for Auto-Updates?

Many users have questioned why there isn’t a UI solution for turning off automatic updates.

Nacin’s answered this in the comments to his disabling automatic updates post:

For the betterment of the web, we made a conscious decision to avoid a UI option. You’d be out of your mind to consciously avoid updating to fix a critical bug or security issue. We think the vast majority of users (many who don’t even know what PHP is) will celebrate this as a win in usability and security. – Andrew Nacin

The fact is, developers and advanced WordPress users can easily turn off automatic updates whenever they want. Novice users who are unfamiliar with site security are better off not having the option to switch off background updates, hence the decision not to have an off switch in the WordPress UI.

Is Your WordPress Install Compatible With Auto-Updates?

Nacin and core contributor Dion Hulse have released Background Update Tester, which allows you to check whether automatic core updates will work with your WordPress install.

Most sites are able to update automatically in the background. This plugin checks if there are any compatibility issues and explains any problems.

To use the plugin, go to Dashboard > Update Tester. If you’re using Multisite, go to Updates > Update Tester in the network admin.

I tested the plugin on a fresh install of WordPress and passed with flying colors.

Background Updater Tester
The Background Update Tester plugin allows you to check your WordPress install is compatible with automatic core updates.

Then I updated my wp-config.php file to turn off auto-updates. It’s easy enough to do (I covered it in How to Turn Off Automatic Updates in WordPress 3.7). Just add the following line of code:


I checked Background Update Tester again and got this:

Background Update Tester
And this is what happens when you turn off automatic updates…

Nacin emphasised this plugin is an “early rough cut”. He said in a future version he wanted to add the ability to send a test email to check that your install can email you.

Have you had any issues with automatic updates? Or do you think all the fuss is much ado about nothing? Tell us in the comments below?

How To Implement A Paywall On Your WordPress Site

Publishers from the New York Times to Australia’s Fairfax Media are implementing a variety of models as they start to charge for access to content.

But you don’t have to be a large media company to either consider or implement a paywall. You just have to value your content and have an audience that values it to.

In this article, we’ll look at the paywall models available and how to implement them on your WordPress site.

Collage of the NYT and FT subscription forms
You don’t have to be the New York Times to consider a paywall – you just have to value your content

Paywalls have gathered momentum in the last twelve months as the relative success of big players such as the New York Times has breathed confidence into an industry that has, at best, struggled with the changes wrought upon it by the internet.

Perversely, whilst online publishing has hammered the traditional players, it has opened up new opportunities for small and micro publishers to create and share their knowledge, often in niche subjects that can provide a sustainable audience when scaled globally.

The small publishers have still had to battle the “everything should be free” mentality and have relied on advertising and products to realise the value of their content. However, the slowly changing acceptance of paying for content being driven by the big publishers is making paywalls a realistic option for small publishers.

Not surprisingly, WordPress, with it’s massive user-base, already has a number of paywall solutions.

Pick a Model, Any Model

There are several flavours of paywall and which you choose will depend on a number of factors:

  • Publishing frequency (how often you publish)
  • “Size” of content (number of words or reading time)
  • Lifespan of content (is your content date sensitive or is it “long tail” material)
  • Subject matter (is it niche or generic)
  • Target audience (socio-economic factors)
  • Reputation of either yourself or the site (is there a desire for content from you)

Each of these factors can influence your choice of model. So what choices do we have when it comes to paywalls?


In the pay-per-view model, a value is assigned to content, either globally or locally, and the reader must pay that amount to view the content.

Pay-per-view works best for significant items of content (essays, long video and audio) that are perceived as being of “high value”. That value might be because of the reputation of the author, the uniqueness of the content (i.e. no readily accessible alternatives) or that the knowledge can be of financial benefit to the reader (speculate to accumulate).

Fixed-Time Pass

A fixed-time pass provides access to a content repository for a limited period of time, anything from a day to 30 days and is useful in situations where the reader is researching and is not interested in a longer-term commitment such as subscription.

They can also be used for more generic sites as a gift or trial with the aim of trying to upsell to a more traditional subscription.


Subscriptions are, of course, (often recurring) payments for access to new and existing a particular site for the period covered by the subscription period.

It is a model that we are very familiar with being the dominant model in offline publishing but it has not proved particularly successful online. This may be because it is often implemented as a “hard” paywall and therefore no content is freely available.

Subscriptions are usually found on websites that either have content that is of high commercial worth, has reduced competition and are often purchased by business (and is therefore a deductible expense). The financial papers such as the Wall Street Journal and The Financial Times fits into this model as do many B2B online publications.

Metered Paywall

The metered paywall is a relatively new model, created specifically for online publishing and is quickly gaining popularity amongst the major publishers. The metered paywall is a “soft” paywall in that it allows for a certain number of items to be viewed for free in a certain time period (usually a month) before a subscription needs to be purchased.

The significant difference is that there is generally no restriction on what the “free” content is. The reader simply reads whatever they want until they use up the quota. There is no real consensus on what a quota should be: the New York Times allows 10 articles per month, whilst Fairfax’s The Age (Melbourne, Australia) allows 16.

Metered paywalls also have significant advantages in that it caters for indexing by search engines and the sharing of content on social media, essential drivers of traffic. Hard paywalls cannot do this.

If you choose to use a metered paywall then you’ll need to think hard about what quota you set and this will be most heavily influenced by the publishing frequency. Obviously, newspapers tend to publish multiple items per day, so running up 10 or 16 reads is not going to take very long.

Even if you don’t publish daily then the metered paywall is worth considering. Even with a much lower quota, it is still giving the reader the opportunity to sample the content before having to make a purchase decision.

Membership Is A Product Not A Paywall Model

This may seem slightly pedantic but I’m not going to include membership as a paywall model. Membership is a product in itself and whilst it may include access to premium content it will often be bundled with other products and services.

You’ll also find that membership plugins and the sites that use them will have various membership levels, with each step up in cost providing added benefit.

Paywalls, on the other hand, are usually single-level models for online content (multiple levels for newspapers, for example, usually include access to paper versions of the publication) with any variation related to the length of access. A subscriber either has access or they don’t.

For that reason, I’m not going to be looking at options for creating a membership site (that’ll be for another time). I am going to concentrate on true paywalls for online publications.

Local Or Cloud-Based Functionality?

Even once you’ve chosen your model, you’ll still need to decide if you have a preference as to whether your paywall’s functionality sits locally within your site or is provided by a cloud-based service.

The cloud-based solutions offer considerably more flexibility, supporting all the models discussed above. It’s also a maintenance free approach, as new functionality can be added to the paywall without the need for updating any software.

However, as we’ll see, the cloud-based solutions are not without their issues. Implementation is not always straight-forward and the costs are potentially much higher than local functionality. And if you implement a paywall with a cloud-based solution you have to consider the consequences of introducing a dependency on an outside service for a critical function.

Cloud-based Paywall Solutions

There are a number of cloud-based subscription services available to WordPress users. Two, TinyPass and MediaPass are available to WordPress.com VIP users, so these naturally would be your first ports of call.


Screen grab of Tinypass paywall management screen
Plenty of flexibility and features but mostly managed outside WordPress

Fees: 15% + $0.30 per transaction (sales volume less than $2,000/mth), 10% + $0.30 per transaction (sales volume greater than $2,000/mth), any transaction less than $2, 30%

Plugin: Yes, but just to hook up to service. Most management performed on Tinypass website.

Models: Time-limited Passes, Pay-per-view, subscription (including metered)

Multisite: Not specifically

If confidence is the key for cloud-based offerings then Tinypass needs to pay more attention. The plugin threw an “invalid header” error when it installed. This may be a minor error and it may well activate the second time but this is not really good enough. Especially as it seems from the WordPress support forums that Tinypass knows about the error.

Like MediaPass, I had a tough time implementing it, frequently getting 503s on the call to the enabling javascript. Again, confidence takes a hit, which is shame because Tinypass has plenty of functionality and flexibility.

Ultimately, the little niggles, the separate management interface and having to individually tag all your premium content all combine to reduce Tinypass’ appeal. The cost structure may also be an issue if you are likely to have a lot of transactions for $1.99 or less.


Screen grab of Mediapass config
Lots of functionality but not confidence-inspiring

Fees: 20% of price

Plugin: Yes, adds full integration into WordPress

Models: Pay-per-view, subscription (including with metered option) – must choose either model

Multisite: Yes

If MediaPass were not part of the service offering from WordPress.com then I don’t think I’d be looking at it. The plugin in the repository hasn’t been updated in over the year and only claims compatibility to 3.3.2, although clearly this cannot be the case if available to VIP customers.

It’s also doesn’t inspire confidence that both the company’s Twitter and Facebook accounts have not been updated since November 2012 and yet are fairly prominent on the homepage of the company website.

Obviously they might just be too busy developing and supporting the product to update their social media accounts and the WordPress plugin repository, but it’s odd just the same.

On top of that, I couldn’t actually get it to work. Now, that may be down to me rather than MediaPass but implementation is not, it would seem, an entirely straight-forward process.

That said, if you can persevere, it’s a comprehensive offering with three different models, easy configuration of the paywall messages and the option to exclude specified locations from the paywall. For Canada and the US this goes down to the city level which is pretty impressive.

It does support multi-site, via a network pass for those of you who want to consider selling access to a network of sites.

Local Functionality

Two contenders again, the Leaky Paywall plugin from IssueM and WPMUDev’s very own Pay-per-view plugin. Unlike the cloud-based solutions that are in competition with each other, these two plugins focus on supporting different models.

Leaky Paywall by IssueM

A good option if a metered paywall is your chosen model
A good option if a metered paywall is your chosen model

Cost: $55 (single site) + merchant fees

Model: Metered paywall

The Leaky Paywall plugin from IssueM focusses on doing one job – providing a metered paywall – and does it well.

With no requirement to worry about what content is free and what is premium, the implementation is very straight-forward: just select the post types that are subject to the metering, set the pricing structure and you are good to go.

The meter is highly configurable, allowing setting of both the number of free items and the timeframe. This flexibility is repeated on the subscriptions where a one-off, lifetime payment is also an option.

The plugin just uses the reader’s email address for access, in conjunction with a cookie, so management overheads should be fairly low.

The only downside to the plugin is that it uses the Stripe payment gateway which is currently only available in the US, Canada, UK and Ireland. However, IssueM are planning on releasing an updated plugin with PayPal support in early November.

If you are looking at implementing a metered paywall, then the Leaky Paywall plugin is well worth a look, especially if you want to combine it with IssueM’s issue-based publishing plugin.

Pay-per-view by WPMUDev

Screen grab of PPV config screem
Pay-per-view, fixed-time and subscription all at one low price.

Cost: $19 (unlimited sites) + merchant fees

Model: Pay-per-view, fixed-time, subscription

Last, but not least, is the Pay-per-view plugin from WPMUDev which provides the functionality to have the three models running side-by-side.

Pay-per-view can be configured globally and then overridden for each post type and the plugin includes the option to include custom post types. The length of the fixed-time pass is set in days as is the subscription length.

There can only be one subscription, so you need to consider this carefully, although the fixed-time pass does give you a second option.

PayPal processing is built-in and is the only payment gateway that is supported and readers can sign-in using with either their Twitter or Facebook details.

Like IssueM, Pay-per-view’s simple approach results in a straight-forward implementation that is easy to navigate and configure.

Which Option To Take?

Photo of signpost with many signs
Choice depends on the model

It’s difficult to recommend the cloud-based solutions. Neither TinyPass nor MediaPass are easy to set up, there’s the ongoing costs and both require jumping into a separate website to configure the paywall, although MediaPass is not as bad in this respect.

The cloud-based solutions look even less appealing when there are two very viable plugins available that provide excellent solutions. Which is the best option will depend on your choice of model as they don’t crossover in this respect.

If you want a pay-per-view, with simple fixed-time and subscription options and a low fee then Pay-per-view is well worth checking out.

Alternatively, if you like the sound of the metered paywall model then the Leaky Paywall plugin from IssueM is your best choice.

Ultimately you need to choose the plugin that provides the model that best suits your situation. And the more paywalls we see, the more acceptance of paying for content will grow and the more sustainable online publishing will become.

Do you charge for your online content or are you considering it? Are you using Tinypass or MediaPass, if so, what do you think?

7 Reasons Why Novices Should Not Self-Host WordPress

WordPress 3.7 is out today and with each release this blogging platform becomes more capable and more sophisticated and that barrier to entry rises just a little bit.

All those little rises now represent a significant hurdle. So much so, that if a non-technical friend of mine asked me whether they should self-host their own WordPress site, I’d say no.

And here’s seven reasons why.

Illustration of the white rabbit from an ealrly copy of Alice In Wonderland
Lewis Carroll’s White Rabbit valued his time too much to self-host WordPress

1. It’s difficult: there’s a lot to learn

It’s probably true that with a bit of luck a novice could stumble through the setting up of a self-hosted WordPress site but a little knowledge goes a long way in making sure that an installation is secure and stable.

The problem is that that little knowledge goes across a plethora of subjects including, but probably not limited to, domains, DNS, mail, databases, web servers, htaccess, security, CPanel, bandwidth, etc.

And once that’s learned, there’s WordPress itself. Again it’s possible to just jump in and start publishing but to really use WordPress properly, even for a simple blog, time needs to be spent gaining even a basic understanding of the content model, the publishing workflow, plugins and themes.

That’s not an insignificant learning curve and whilst it may be shallower than say Drupal, it’s a learning curve just the same.

2. There’s too much choice: analysis paralysis is always hovering

If ever there was an example of too much choice being a bad thing, then WordPress themes is it. Choosing a theme is nothing short of a bewildering nightmare.

There are 2,097 themes in the WordPress Theme library; TemplateMonster claims to have 1,800 plus themes; ThemeForest trumps them both with 3,477 themes and templates.

Putting aside the obvious question of why are there so many themes, how does a self-hoster choose a theme from such a massive selection?

Perhaps that’s why the theme-seller memberships work: it cuts down the choice to a manageable number.

3. It’s not the cheapest option: free can be so expensive

Free is such an alluring proposition. Free software, free themes, free plugins, even free hosting, what’s not to like? As most of us know the only truly free component of self-hosting is the WordPress app everything else is going to have a cost that we might not want to pay.

Self-hosting with any confidence requires the use of quality components and that quality, along with support and continued development, quite rightly does not come for free.

A back of the envelope calculation for a domain name, reliable hosting, a decent theme, and a couple of premium plugins comes out at anything between $250 and $450 for that first year. An equivalent site on WordPress.com would cost between $150 and $250 for a Pro site with a premium theme whilst SquareSpace costs $250 for unlimited storage, bandwidth and a custom domain.

4. It’s time-consuming: self-hosting properly takes up your most valuable asset

Proper, and that’s the key, self-hosting takes up plenty of time. There’s regular updates to the WordPress core that, ideally, should be tested before being applied to self-hosted site. Then there’s updates to themes and plugins, again that should be tested first.

That also means maintaining a test environment somewhere and regularly updating it with the live data and configuration. Not difficult once the live site is created but it all takes time.

For most people, time is their most valuable asset so why spend it on maintaining the environment when it could be spent on the far more productive activity of creating content?

5. It’s not worth the risk: there’s just too much that can go wrong

Many self-hosters get away with a lax approach simply because there is safety in numbers. There are so many WordPress sites out there that it takes time for the hack-bots to find them but it is only a matter of time.

Even conscientious owners who do put the time and effort into maintaining their environments can find they get into difficulties sometimes not of their own making. Hosting downtime, server disk failure, targeted attacks on a particular host and vulnerabilities introduced in an updated plugin all real possibilities and all can have a significant impact.

6. Starting from scratch is hard and unnecessary

Self-hosted sites start with an audience of one, no page ranking, no indexed content in any search engine and no mailing list. All of these essential facets of a successful site take time to build and grow.

Sure, it’s possible for the self-hoster to kick-start their site to a certain extent if they already have a significant social media presence but it’s still going to be a hard slog.

7. Flexibility is overrated

Many defences of self-hosting will mention flexibility: the ability to pick the theme and that unique collection of plugins that are needed to create the user experience that the site owner is looking for.

That might be true for commercial or niche sites but not for a blog. If there is anything that the likes of WordPress.com, Blogger, Medium and even Twitter have taught us, it is that simple is better.

There Are Better Options

Simply put there are services out there that will enable a novice to get a better looking, easier to operate site up and running in far less time and for less cost than is possible with self-hosting.

Services take all the worry out of hosting and often provide extra functionality. One the key advantages these services provide, not obvious at first glance, is that they dramatically reduce choice both in plugins (generally reduced to an absolute minimum) and themes. All of which, maximises the time that can be spent on content creation.

And if that wasn’t enough, some of them will also give you a leg-up when it comes to putting you in front of an audience.

So my advice to my non-technical friend would be to think hard about what they really and truly need and make a list. Then check that list against the likes of WordPress.com, SquareSpace, Medium (when it opens up) and any number of hosted WordPress solutions.

My hunch would be that at least one will provide all the functionality for less cost and far less hassle. And my friend can focus all their attention on creating killer content.

What would you recommend to your hypothetical non-techie friend?


How to Turn Off Automatic Updates in WordPress 3.7

Automatic core updates are now part of WordPress, thanks to the release of version 3.7 yesterday, and while it is an “opt-out” feature, developers will be pleased to know it’s possible to switch it off.

WordPress co-founder Matt Mullenweg has made no secret of his desire for auto-updates, flagging the idea in his State of the Word address in 2012. At the time, Mullenweg said he admired Google Chrome’s approach – the browser software is always automatically kept up-to-date without users necessarily knowing version of Chrome they’re running.

But not all WordPress users have welcomed the feature, with many asking for a way to turn it off.

In this Weekend WordPress Project, I’ll show you how to switch off automatic core updates.

Automatic Updates

So How Do I Turn Auto-Updates?

The WordPress admin area doesn’t have an “Off” switch built into the UI, but you can disable automatic updates by adding the following code to your wp-config.php file:


There are a couple of other methods developers should know about:

  • If you’re using a deployment system that uses SVN or GIT it’s disabled by default
  • You can also make use of the auto_upgrader_disabled automatic_updater_disabled OR auto_upgrade_core auto_update_core filters

Turning Off Automatic Updates With a Plugin

If you don’t want to dig into the code, why not install a plugin instead?

Gary Pendergast’s fantastic plugin Automatic Updater For WordPress not only allows you to automatically keep your WordPress install up-to-date as soon as updates become available, but also allows you to disable updates.

Summing Up

While automatic updates might scare off some developers, it’s important to remember why this feature has been introduced: to ensure WordPress installations are updated to the latest secure version. Remember TimThumb? Exactly.

If you turn off updates if defeats the whole point of automatic updates as a feature.

However, for some developers – and managed WordPress hosts – turning off automatic updates is necessary, particularly if your site is heavily dependent on plugin’s for functionality and you need time to test your plugin’s against future versions of WordPress.

Enjoy your weekend!

How To Add Flexibility To WordPress Comments Options

When it comes to managing comments in WordPress, the only option at a site level is a big on/off switch which, of course, only works for new posts and pages.

More likely you want more granular control than that. Perhaps you want to switch off comments for pages or but leave them on for standard posts. Or maybe, you’ve spent a great deal of time and effort seeding your site with content only to discover that you forgot to turn off comments and now you’re faced with going through each page and switching them off manually.

In this week’s Weekend Project, we’ll look at how, with minimal effort, you can take control over comments not just for future content but also for existing content.

Composite image of an on-off switch
The built-in WordPress comment settings are little more than a global on off switch

Before we start, let’s quickly recap on the comment functionality that WordPress provides.

The global on/off switch is located in the Default article settings section at the top of the Discussion Settings page (Settings > Discussion)

Screen grab of the default article settings from the Discussion Settings page
The Default article settings are effectively a global on / off switch and only for new content

Crucially, this will affect any new post type, so pages, posts and any custom post types will default to what you set here. It does not change existing content.

As the Settings page tells us, that global setting can be overridden for individual articles. On an item’s edit page you’ll find the Discussion metabox where you can enable and disable comments and trackbacks for that item. The default value is the global setting from the Discussion Settings page.

Screen grab of the discussion metabox from the post edit screen
The Discussion metabox allows you to override the global settings for an individual item

Incidentally, if you don’t see the Discussion metabox then scroll to the top of the edit screen and click on the Screen Options label. A panel will expand and you should see Discussion listed under Show on screen. The checkbox controls whether the discussion metabox appears on the edit screen, so set it accordingly. If Discussion is not listed then that probably means that you are editing a custom post type that does not support comments.

Okay, so out-of-the-box we can globally switch comments on and off for new content and we can override this setting on each post, page and custom post type (if it supports discussion). That’s pretty limited and potentially requires remembering to override global settings at time of publishing (certainly not one of my strong points) so let’s look at how we can extend this and make comment control far more flexible.

Flexible Comment Control? There’s a Plugin For That!

One of the wonders of the WordPress ecosystem is that if you have a WordPress itch then generally there’ll be a plugin available to help you scratch it. In the case of more flexible comment control, I found and tested several but in the end I chose No Page Comment by Seth Alling.

I like this plugin as it allows settings to be applied separately to pages, posts and any custom post types, allows separate control of comments and trackbacks, allows modification of current content and provides access to its functionality via a simple, easy-to-understand, visually-appealing Settings page.

Download and install the plugin and then access the plugin settings via Settings > No Page Comment.

Screen grab of the No Page Comments settings screen
The No Page Comments plugin allows granular control of each post type as well as modifying existing content

As you can see, the Settings page is split into two sections, one for new content and one for current (existing) content. You’ll also notice that Articles is listed – that’s because I’ve got a plugin installed that created this custom post type.

Set the Global Settings For New Content

By default the plugin disables comments and trackbacks on all post types except for Posts, so if you want to change this and check and uncheck the boxes as appropriate and then click on Update Settings. That’s new content taken care of and remember, these options can still be overridden on an individual item.

If you uninstall the plugin, then the WordPress global setting comes back into play for those items that do not have their own discussion setting.

Dealing With Current Content

Now you need to consider what to do with existing content. Unlike the new content settings, these settings are permanent so be sure about what you want to do.

For each post type you have the option to disable and enable comments and trackbacks. What this is actually doing is going through each page or post and changing the discussion setting on the item which is why it cannot be rolled back.

Let’s say, then, that you want comments on pages: simply click on the Disable All Comments button and the Allow Comments option will be set to off for all pages.

What About Existing Comments?

Disabling all comments will prevent further comments on the post type but doesn’t hide or remove any existing comments. If you want to do this then there’s the manual option of moving all the comments you don’t want to Trash in the admin interface or, if there are a lot comments, you can add this code to your theme’s functions.php file:

function hide_comments( $comments ) {

global $post;

// not in admin, is a page and comments are not allowed
if ( !is_admin() && $post->post_type == 'page' && $post->comment_status == 'closed' ) $comments = array();

return $comments;

add_filter( 'comments_array' , 'hide_comments' );

This code will empty the comments array if we are not in the admin interface, the post type is a page and the comment status is closed, effectively disabling the display of existing comments. Checking for the comment status means that any item-level overrides are respected.

Change the if statement to whatever suits your situation or simply duplicate it if you want to add more tests.

That’s it for this Weekend Project: ten minutes well-spent in adding much needed flexibility to controlling comments on your WordPress site.

Photo Credit: Robert Kevin Moore

WordPress 3.7 “Basie” Now Available

WordPress 3.7 has dropped.

In a short and sweet post at WordPress News, WordPress co-founder Matt Mullenweg today announced the latest release was now available to download or update from the WordPress dashboard.

Mullenweg said version 3.7 featured “some of the most important architectural updates we’ve made to date.”

Version 3.7 has been named “Basie” in honor of American jazz pianist, organist, bandleader and composer William James “Count” Basie.

WordPress core developers share a love of jazz music, and since version 1.0 all major releases of WordPress are named in honor of jazz musicians.

WordPress 3.7 Major Features

Automatic Updates: Maintenance and security updates are now automatic so you don’t have to manually update your WordPress install. Most sites are now able to automatically apply these updates in the background. The update process has also been made even more reliable and secure, with dozens of checks and safeguards. Just to clarify, automatic updates are for minor updates of core, so from 3.7 to 3.7.1, not 3.7.1 to 3.8.

Stronger Password Recommendations: The password meter has been strengthened using Dropbox’s zxcvbn library. Engineer Dan Wheeler developed the open source estimator as an independent Dropbox hackweek project. The estimator catches common patterns and doesn’t penalize sufficiently complex passphrases like “correcthorsebatterystaple”. Wheeler’s post on the Dropbox Tech Blog offers a detailed rundown of how the estimator works and how it compares to estimators used by sites like Facebook, Gmail and Yahoo!

Better global support: Localized versions of WordPress will receive faster and more complete translations. This version adds support for automatically installing the right language files and keeping them up-to-date, which is fantastic for everyone out there who uses WordPress in a language other than English.

Other WordPress 3.7 Features

There are other features in this release that didn’t get a mention in the official announcement:

Improved Search Results: Search results are now ordered by how well the search query matches a post instead of ordered only by date. So if your search query matches the title of a post, that result will be pushed to the top.

Advanced Date Queries: Developers can now query for posts within a date range or that are older than or newer than a specific point in time, i.e. search for all posts written on Friday afternoons.

Multisite Improvements: wp_get_sites() allows developers to easily get an array of all the sites on your network without resorting to a direct database query.

The 3.7 development cycle also focused on cleaning up more than 3500 open Trac tickets. So far, only a few hundred have been closed, but many, many more have been looked at and this cycle has certainly gone some way to tidying up Trac.

The Quickest Release Cycle in WordPress History

This cycle has been the quickest turnaround between major versions – just 86 days – in the history of WordPress. WordPress 3.6 was released on August 1.

Mullenweg said this was also the first release using the new plugin-first development process he flagged during his State of the Word address at WordCamp San Francisco.

He said WordPress 3.8, due out in December, will continue this plugin-led development cycle, which gives more autonomy to plugin leads and allows core developers to “decouple” feature development from a release.

Mullenweg gave props to 211 contributors for this release, but lead developer Andrew Nacin and co-leads Dion Hulse and Jon Cave deserve most of the credit for this release.

Have you downloaded WordPress 3.7? What are your first impressions? Tell us in the comments below.

WordPress 3.7 Set For Release Any Day Now

With WordPress 3.7 expected to be shipped in just a matter of days, the second release candidate has been made available for testing.

Lead developer Andrew Nacin posted at Make WordPress Core that RC2-25890 will be the last build of 3.7 before its release.

Automatic updates will be a key feature of WordPress 3.7.

Core developers are set to meet in IRC today at 10am EDT to “see if everything is a go”.

If you’re already testing WordPress 3.7, your install will have been already automatically updated to RC2 thanks to the release’s flagship feature, automatic updating.

For those who would like to start testing, try the WordPress Beta Tester plugin or download the release candidate.

Nacin has urged developers to test plugins and themes against the upcoming release for compatibility issues.

WordPress 3.7 was originally planned for release on October 14. WordPress 3.8 is expected to be shipped in December, with work on features as plugins already underway.

For a full rundown of WordPress 3.7′s feature, check out WordPress 3.7 Beta Now Available.

Have you tested WordPress 3.7? Have you tried automatic updating? Tell us in the comments below.

Image credits: Heisenberg Media.

How To Test WordPress On Tablets And Mobiles You Don’t Own

Whether you are a site owner, a theme developer or a developer, at some stage you’ll need to test a WordPress site on a variety of tablets and mobiles.

Whilst it would be great to have a wide sample of devices available, likely that’s not the case, and that’s where emulators come in.

In this article, I’ll walk you through your options including how to set up emulators for iOS and Android.

Screen shot of the iOS Simulator and Android Emulator running on OS X
Installing the iOS and Android simulators can be fiddly but is worth the effort

Testing WordPress sites on multiple platforms was always a pain. For a brief while there was light at the end of the tunnel as we designed for standards, with graceful degredation and that enabled us to stop worrying about so much about getting a site to look the same on IE6 as it did on the latest version of FireFox.

Then along came tablets and smartphones and the end of the tunnel became a distant speck on a far-off horizon.

Responsive has certainly helped but before launching or upgrading a site it still needs to be tested on the basic platforms to ensure that it’s not just usable but effective. It would be nice to be able to keep an up-to-date library of cool gadgets to be able to test on but not only is this expensive it would probably mean that we’d never get any work done.

Fortunately, there are tools available that can help us test various platforms that won’t take a hit on productivity or the bank balance.

iPhones and iPads – iOS simulation

The best way to check a site on the iOS devices is to use Apple’s own iOS Simulator app. The app is part of XCode, Apple’s “integrated development environment…for developing software for OS X and iOS”.

If that sounds a bit heavy then don’t worry because the simulator is a standalone application and can be dragged to the dock and run as required without needing to fire up XCode first every time. To get XCode (and the simulator) you’ll need to sign-up for an Apple Developer ID; this is straight-forward and free. To download XCode, go to Downloads for Apple Developers, perform a search on ‘xcode’ and pick the version that is appropriate for the version of OS X that you are running.

Once you have downloaded and installed XCode:

  1. Open a Finder Window and click on Applications
  2. Right-click on XCode and click on Show Package Contents in the context menu
  3. In the window that opens, Click on Contents > Developer > Platforms > iPhoneSimulator.platform > Developer > Applications
  4. You should see iOS Simulator listed – drag it to the Dock so that you have easy access.

When you open the app it will start as the last device you simulated (or an iPhone on the first use).

You can change the device by clicking on the Hardware menu item and rotate it through the same menu option or via shortcut keys.

To test a WordPress (or any site, of course) click on the Safari icon and simply enter the URL in the location bar.

Screen shot of this post in the iOS Simulator
The iOS Simulator allows fast and accurate testing for iPad and iPhone

I’ve tested a variety of websites on both the simulator and a real device and there’s practically no difference. And don’t forget, as the app is running on your Mac then it can access any site that your Mac can, including locally hosted websites.

Verdict: If you own a Mac then the simulator is well worth the effort to install. As you likely know, XCode does not run on any other platform which severely limits the options for non-OS X users and probably means that you’ll be better off looking at a cloud solution such as BrowserStack.

Android Simulation On OSX / Windows

Screenshot of this post running on the Android Simulator
The Android Simulator worth using despite fiddly
install and lacklustre performance

Accessing the Android Simulator is a similar, if slightly more convoluted, process to accessing the iOS Simulator but, again, is worth the effort.

This time we are going to install the Android SDK which is available on a range of platforms including OS X and MS Windows.

The following instructions are for OS X and MS Windows:

  1. Download the Android SK
  2. On Windows, run the installer, on a Mac unzip the download
  3. Go to the installed / unzipped folder, click on Tools > Android, a command prompt will appear and then the Android SDK Manager application will open
  4. Check the Android 4.3 Folder and click on Install (x) Packages, this will start the installation process. This can take some time.
  5. When the installation is complete, you need to set up virtual devices to simulate. Click on Tools > Manage AVDs in the SDK Manager menu.
  6. You can either create your own or click on Device Definitions, select a device and then click on Create AVD and then OK. Your device should now be listed in the List of existing Android Virtual Devices
  7. Highlight a device and then click on Start. Decide whether you want to Scale the display to real size (warning, it will likely be very small if you do!) and then click Launch

It can take a while for the simulator to get going as it starts up Android. In fact, if you don’t see Android  come up on the screen then something is wrong.

A few of the AVDs had this issue for me. Once Android is running you can find the browser and start browsing websites just as you do with the iOS Simulator, although there are no menu options for rotating the device which is a little annoying. Use the following key strokes to get rotation: Mac OS X : fn + control + F11 or F12  (you have to release all the keys and repeat for further rotation) Windows: CTRL + F11 or F12

Verdict: The Android SDK is a little more convoluted to get set up but once complete, you have all the same advantages of the iOS Simulator: running the actual operating system and access to locally hosted sites. The emulator can be painfully slow at times, though.

Geez, That Seems Way Too Complicated – Is There An Easier Option?

If the thought of installing the SDKs put your brain in a spin, you could always consider a web-based browser testing option such as BrowserStack.

The good news is that testing external websites requires no installs and you can test on a huge range of platforms and devices, including other desktop operating systems and browsers.

The catch is that the service is not free (plans start at $19 / month for 1 user, there is a free no-credit-card required trial that gives you 30 minutes of simulation) and that local testing does require installing a Java app which on Windows is probably a breeze but as most Mac users know, Apple doesn’t always play fair with Java.

The service works by hooking into virtual instances of the major desktop operating systems and then either running the required browser or, for mobile devices, running the simulator.

So, when you test a website on an iPad you are actually running the iOS Simulator on OS X!

Screen shot of BrowserStack in action
BrowserStack running a virtual instance of the iOS Simulator on OS X!

For this reason, the service can be a little laggy but it’s certainly acceptable.

The other issue I had with BrowserStack was their sign-up form’s insistence that my primary Gmail email account with two periods before the @ was invalid.

Surely, this must be fairly common nowadays?

So, Which To Choose?

Which option to choose will really depend on your self-confidence on installing the SDKs and which platform you are on.

BrowserStack does let you test everything through the one interface including an excellent range of desktop operating systems and browsers. They even have installed developer tools into the browsers, with Firebug installed on Internet Explorer 10 running on Windows 8, for example. At $19 a month, the service represents excellent value for money.

That said, my preference would be to run as many simulators for the better performance and easy testing of locally running websites.

It’s also easier to use the simulator to test multiple themes rather than using the device itself. For OS X Users, that means installing XCode and the Android SDK. Windows users, well, you appear to be stuck with just the Android SDK. Which means that the ultimate approach is, of course, a combination: locally installed simulators where possible and BrowserStack for those combinations that you cannot emulate locally (especially the other desktop operating systems).

This would certainly cover all bases and provide plenty of confidence that your site, your client’s site or your theme worked perfectly across all the major platforms.

How many platforms do you currently test against? What tools do you currently use? Let us know in the comments.