Pay With A Like? Share Before You Can See Content?

I’m always looking for new ways to bring traffic to our network of sites, but the new “Pay With A Like” plugin from WPMU feels socially dishonest to me.

The Pay with a Like plugin lets you leverage the power of social currency in order to give access to content or a download. You know your content is share-worthy, but how do you get those lazy visitors to take a minute to share with their friends? Make them pay with a Like on Facebook!

Content becomes visible after a user pays by sharing your post. And it’s not just for Facebook Likes – users can also pay with a Tweet, a Google +1, or a share on LinkedIn.

The plugin is also very easy to use. It comes with a built-in button to protect specific content within a post through use of shortcodes:

Don’t get me wrong, we’re never above asking people to like us when we run a competition or something, but asking people to share your site or post before they’ve even seen the content, before they even know if it’s share-worthy, well that just flies in the face of what social sharing is about in my opinion.

Also, I wonder if this wouldn’t have the potential to backfire?

When we rolled out changes to our sites recently that had 12 excerpts on the front page instead of 3 full posts, the backlash from readers had us scrambling to change the format because a lot of users just won’t make that extra click see the content. Call it laziness or whatever you want, some folks just won’t do it.


The WordPress Plugin API Needs To Learn How To Communicate

The WordPress plugin update system isn’t verbose enough and needs to learn how to communicate with end users.

When updating plugins only the barest amount of information is passed on to the end user and in many cases hitting the “view version details” link and looking at the changelog before committing to the update provides you with only the scantest of information, if any at all.

We’re all used to backing up our databases before updating in case a plugin goes haywire, but a lot of the time we have no control over or warning about intentional changes being made by plugin authors.

Today I upgraded the Digg Digg plugin from version 4.2.2 to the latest version 4.5. A lot has changed between those two releases but you would not think it, by looking at the information I was presented with from the WordPress upgrade panel.

Digg Digg Update 1

Even after the upgrade was completed,  checking the details of the upgrade yields no useful information about what actually occurred or what was changed during the upgrade.

Digg Digg Update 2

The upgrade to 4.5 was a disaster. The new version retained none of the settings of the previous version and also stopped working on WP 3.01 multisite which was something 4.2.2 was capable of. Even on a stand alone WP 3.01 (not multisite enabled) it lost all of it’s settings.

This is something which the average user isn’t prepared for. They’re left flailing around wondering what broke? Was it something they did? Did they screw up the upgrade? All questions, which could be easily answered if the upgrade had simply output some useful information such as:

This upgrade will perform the following tasks:

Overwrite files X-Z. Delete DB table entries A-F. Creating new tables for G-H.

This will result in a loss of your current settings.

Do you want to proceed (Y/N)

Simple, easy and everybody understands exactly what is happening before they commit to those upgrades.

I understand that this will mean a bit more work for plugin developers as they would have to pass information to WordPress in order to let it know what will take place, but is that really too much to ask?

It might get plugin developers to think about the upgrade process in a bit more depth and actually start deleting the unused information that they left lying around in the DB.

Not wanting to pick out any one plugin as an example here, but the Digg Digg plugin failed on exactly this point today.

Once the upgrade was complete it had lost the settings. When I performed a downgrade to 4.2.2 all the settings were magically restored. Well it wasn’t magic really. What actually happened was that the plugin author had decided to use a new table for the latest version of his plugin and simply neglected to remove and/or port the settings to the new one.

This my friends is why your DB’s bloat and need to be manually checked for defunct tables from time to time. Just like that lazy housemate of yours that never cleans up after himself, plugin authors often forget or neglect to clean up the dirty footprints of their plugins after upgrades and removals.

Maybe instead of relying on the good intentions of developers, if information about file deletions and database changes were a requirement of the upgrade process then maybe we’d see devlopers adopting better practices instead of hoping that we’ll magically start implementing them without incentive.

Not to mention that this information could help lower the blood pressure of many WordPress newbies.

New Beta Of NextGen Gallery Supports WordPress Multisite

WordPressSince the upgrade to WordPress multisite the gallery section of my blog has been strangely empty as NextGen Gallery (the WordPress gallery plugin we use) was multisite incompatible.

All issues have been fixed now and thanks to the latest beta (1.6.0b1) they are alive and kicking again.

Please note, that this is a beta and is not available from the WordPress plugins download site yet.

The Problem With Social Buttons, URL Shorteners And WordPress Networks

There Can Be Only One

There Can Be Only One

I love the network features of WordPress 3. This blog is one of 11 running from a single WordPress install using the multisite feature with domain mapping.

While the feature is excellent I do have a concern when it comes to the use of URL shorteners and plugins that create short URLs for posts on creation and then send the off to places like Twitter and Facebook.

When you create a post on a network blog the original URL looks something like this:

After domain mapping kicks in this URL is changed to something like:

This is all well and and good, but all of the plugins I’ve tried that tweet out that my next epic post is available for you to drool over, shorten the URL before the domain mapping kicks in.

As a reader this behavior has no effect on your experience. The WordPress backend cleverly does a little 301 redirect to ensure you always end up at the URL I want you to be at, but it does have an effect on URL shortening services which may end up creating 2 short URLs for every page on your site.

2 short URLs by the same service that eventually end up at the same page may not sound like much of a problem but it can lead to some issues.

The most obvious problem comes when tracking clicks on 3rd party URL shorteners like You now have to track 2 urls and add the numbers to see the correct amount of traffic driven by a specific short URL.

Social buttons such as the new Twitter button and other retweet buttons can report numbers that are significantly below what they should be.

As an example, consider this post you are reading now. If it gets tweeted out automatically and the short URL is generated against the non-mapped URL, the short URL will be SHORT URL 1.

Now lets say that 15 of my followers retweet me (in the old sense – RT @pauloflaherty) and the SHORT URL 1 is included. That should, in theory, make the retweet button on this page read 15. The problem is that it won’t read that, it will read zero.

The reason for this is simple. When the retweet button is generated on the page it polls for the URL of the post and with domain mapping enable it receives the mapped URL. When it polls Twitter, (Tweetmeme or Topsy) to check how many retweets were made, it finds nothing because of the difference between the two URLs. The service providing the social button treats the second URL as a new site.

When this happens retweets are only counted on your site from when someone clicks on the retweet button on the post and using the mapped URL generates a new short URL: SHORT URL 2.

The numbers for displayed for SHORT URL 2 are going to be signifcantly reduced as they will always be minus those of SHORT URL 1.

So now that we know what the problem is, how do we go about fixing it?

The answer is rather simple yet beyond the control of the average user.

The plugin that you use to generate a short URL and tweet or Ping it out needs to be aware of the domain mapping.

Considering that the network feature relies on a plugin for domain mapping, it should be possible to check for the presence of this plugin, then poll the database to find out the domain mapping for the current blog, and adjust the URL being sent to URL shortening service accordingly.

As I said above, this is beyond the capabilities of the average WordPress user, but is something that developers need to take into consideration going forward.

If your favorite URL shortening plugin doesn’t already support this, it’s time to drop by the developers site or forum and let them know that you need this fixed (and don’t forget to donate accordingly when they do).

You Get What You Pay For? What Bollocks! Or Why Cash Doesn’t Equal Quality

I’m deliberately not weighing in on the entire Thesis Vs WordPress GPL debate, but while reading some of the commentary on it, I came across this statement made by Dave of “Think Dave”.

I’d like every single plugin and theme developer to release their work outside the GPL, and charge money for it. This would instantly get rid of 90% of the crap plugins, themes and add-ons that don’t work and aren’t supported. And it would leave behind a core product offering that is easily robust enough to be used for any Enterprise web project.

Sorry Dave, but that is a very misguided and naive statement. Want proof? Look at Apples App store. The vast majority of apps are crap and you pay for them.

When everybody charges for everything, the vast majority of people end up trying to charge you for crap and a lot of folks operating in that environment attempt to charge you for stuff that normally they would be embarrassed to give away for free.

It doesn’t get rid of crap plugins (or crap apps) it encourages people to attempt to make a quick buck on the back of crap product.

WordPress Plugin Developers: Can We Standardize Where Menus Appear?


Confused and Frustrated?

Dear WordPress Plugin Developers,

I know you’ve spent a long time working on your plugin and I am very grateful for the work you have done. However, as someone who spends a lot of time trying out different plugins for use on a number of sites can I ask that you standardize where the menu for your plugin is going to be located.

Sometimes I install a plugin and find I have difficultly tracking down the link to the options page for that plugin. Sometimes it is in the Settings tab, other times it is in the the Plugins tab and quite often it has even created a tab all of it’s own on in the WordPress interface.

I must say that this is all very counter intuitive and disrupts the work flow for those of us who expect access to plugins settings to be located in an obvious place such as the “Settings” tab.

Hoping that you will all take that into consideration in the next release of your wonderful plugins.



P.S. Can you pass the word on to your theme developer friends as well, as some of them appear to be confused as to where the link for a themes options should be located. After all, what’s the point of a nice sidebar with everything broken into specific areas if we stick in links where ever we want?

Hack Sociable to work with YOURLS – Quick and Dirty



Since we’ve created and started using our own custom short URLs for our domains we’ve run into a few issues with other WordPress plugins not working quite the way we would like them to.

The biggest issue we’ve had is with the awesome sociable plugin by Joost De Valk (now taken over by BlogPlay) which adds social bookmarking buttons to all your posts. It’s an amazing plugin and even allows you to use it with URL shortening service, but of course we wanted to use our own service which runs on Yourls.

When I first made the modifications to Sociable I didn’t realized that some services, such as StumbleUpon, would throw a fit when they got passed the URL. Essentially they were having problems with the 301 redirect, so I went back and did it a second time.

I didn’t want to strip out the shortening functionality (in case I ever needed to fall back on it) from the script and wanted to be able to selectively decide which services to send a short URL to and which to send the original URL to.

My solutions isn’t exactly elegant and there are certainly other ways to approach it, but it works.

First working with version 3.4.4 of Sociable, open the file “sociable.php” in your favorite editor (I’m working in Dreamweaver) and find line 605.

Line 605 should look like this:

$permalink = urlencode(get_permalink($post->ID));

Replace it with the following:

$permalink = urlencode(get_permalink($post->ID));
$shortlink = urlencode(wp_ozh_yourls_raw_url());

Next find line 679 which reads:

$url = str_replace(‘PERMALINK’, $permalink, $url);

Replace line 679 with the following:

$url = str_replace(‘PERMALINK’, $permalink, $url);
$url = str_replace(‘SHORTLINK’, $shortlink, $url);

All that we’ve done here is create new variable called “$shortlink” which grabs the short URL via a call to the YOURLS API (more info on the API here) and allows us to place the short URL into the array which is used to construct the URL used in the bookmarks.

The array for constructing the URLS is between lines 62 and 552.  The section for posting to Twitter looks like this:

‘Twitter’ => Array(
‘favicon’ => ‘twitter.png’,
‘awesm_channel’ => ‘twitter’,
‘url’ => ‘’,

As it is above, the twitter bookmark that appears on the bottom of your post will send the full URL of your post to twitter along with the title. In order to make it work with your short URL just swap out “PERMALINK” for “SHORTLINK”:

‘Twitter’ => Array(
‘favicon’ => ‘twitter.png’,
‘awesm_channel’ => ‘twitter’,
‘url’ => ‘’,

Now all you have to do is decide which services you want to send short URLs to and which you want to get the full URL and replace as necessary inside the array.

As a note, we’re using the short URL for Facebook, Twitter, Email and Friendfeed and using the full URL for Digg and StumbleUpon. You may need to test which ones work for you, depending on the services you use, as they don’t all accept the short URL.

A Few Changes

I just wanted to bring your attention to a few minor change I’ve made to the blog this morning.

First I’ve turned on the sociable plugin again to make it easier to share and bookmark any posts you may find interesting.

I’ve recoded the plugin so that it now shares using short URLs (rather that the full URL of the post) which should save you a lot of space and the bother of shortening the URL if you post to Twitter or another service with limited space.

Second I’ve added a small link to the information section at bottom of each post (just before the comments) where you can see and copy the short URL if you need it.

That’s it, short and sweet :)

How Tim Burton and WP Super Cache brought my sites to their knees

We felt like Alice tumbling down the rabbit hole last night. News broke that the the trailer for Tim Burton’s Alice in Wonderland had leaked onto the internet, Sara nabbed a copy, threw it up on Daily Shite and then all hell broke lose.

I didn’t think much of it at first, but then the traffic started flowing in and things started to go haywire.

All of our sites are hosted with DreamHost on various accounts, but O’Flaherty, Suburban Oblivion and Daily Shite are all hosted under the same account, which means they’re all residing on the same server (along with hundreds of other customers sites I would presume), so when my site started throwing 500 errors as Daily Shite came under heavy traffic I knew I’d done something wrong.

The worst thing about being on a hosted server is that it only takes one of your sites to be poorly configured in order to go over your resource allotment and take the others down as well.

So as the traffic spiked on Daily Shite I was left confused as to what was happening. The sites had been working fine under reasonable load, I had WP Super Cache installed so what could it be?

To make matters worse, getting into the admin panels of the sites to change settings was proving difficult as they all kept throwing “Internal Server Errors”.

I’ll cut a long story short and get to the chase, after a quick SSH login it became evident that the reason the sites were throwing wobblies was the very plugin that was installed to help the sites deal with heavy loads – WP Super Cache.

In my eagerness to get everything running smoothly and quickly, I’d enabled Gzip compression on all of the sites. Bad move on my part.

While Super Cache was doing what it should and serving only cached versions of the pages, instead of the whole batch of database calls it’s supposed to prevent by not recreating the page for every user, it was now using CPU cycles to compress the data being sent to readers browsers.

Now this is fine on an average load day, the extra CPU load from compression is negligible and provides a minor speed increase in load times for anyone viewing the site.

But when you’re seeing a spike like we did yesterday, it just brings the entire system to its knees.

Once I had Gzip compression, as well as “Coarse File locking” disabled everything came back to life and ran like a dream throughout the entire 2-3 hour traffic spike.

So, if you’re expecting or hoping for a huge traffic load on your site and are on a hosted server here’s my recommended settings for WP Super Cache:

WP Super Cache config

  • Don’t cache logged in users – Disabled (no check mark) If a logged in users visits the site with this enabled they force a rebuilding of the cache which uses up valuable resources under a heavy load.
  • Clear all cache files when a post or page is published – Disabled (no check mark) This can significantly increase posting time as a the cache is cleaned out.
  • Cache Rebuild – Enabled (checked box) – Serve a supercache file to anonymous users while a new file is being generated. Recommended for very busy websites with lots of comments. Makes “directly cached pages” and “Lockdown mode” obsolete.
  • Coarse file locking – Disabled (no check mark) You probably don’t need this but it may help if your server is underpowered. It can cause some server configurations to lock up so best to leave disabled.
  • Mobile device support – Enabled (checked box)
  • Super Cache Compression – Disabled

One final tip for working with WP Super Cache: Don’t forget your .htaccess files. When you set up, or upgrade the plugin you have to insert (and check for changes in) rules in not just your root .htaccess file but you must also create a .htaccess file in “wp-content/cache” and manually populate it with the rules given in the plugins admin page. Also, don’t forget that adding mobile support requires and additional set of rules to be added manually.

Forgetting to add the rules can lead to trouble and the plugin will not work as it should.

Now you should be prepared to be dugg or any other massive traffic spike and won’t be caught with your trousers down like I was :)