Month: April 2013

A WordPress local development environment with Vagrant

VagrantI’ve used XAMPP as my WordPress local development environment for the last couple of years, but as I’ve done a lot of development on the Smart Insights site recently, it’s been frustrating me that my development environment doesn’t match with the live server. So I started looking into alternative solutions.

I’ve recently migrated Smart Insights to Synthesis after considering most of the premium WordPress managed hosting companies such as WPEngine and Pagely. Synthesis run their platform on virtualized server instances running NGINX with a configuration tailored specifically toward speeding up WordPress. It’s fast – blindingly so if you use the custom W3 Total Cache rules they give.

Meanwhile, XAMPP is standard PHP/mySQL running on Apache. No optimisation for WordPress. No specific configuration for caching or anything else.

What this means is that I’m developing locally on a system that’s completely different to the live server, which isn’t a great idea. Chances are at some point, something that seems to work completely fine on my WordPress local development environment will fail to work on the live server when I launch. Not often, of course – WordPress pretty much runs on anything. But if you can negate the risk of it happening by mirroring the live server on your local development environment, it makes sense that you should!

A better solution for WordPress local development environments

A few months ago another developer introduced me to Vagrant;

Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.

To do its magic, Vagrant stands on the shoulders of giants. Machines are provisioned on top of VirtualBox, VMware, AWS, or any other provider. Then, industry-standard provisioning tools such as shell scripts, Chef, or Puppet, can be used to automatically install and configure software on the machine.

Virtualization is nothing new, of course, it’s been around for many years. What’s great about Vagrant is that once you’ve created your environment, you can package it up in such a way that it can be fully scripted and becomes portable. If you want to create a certain development server configuration that pulls a fresh copy of your client site from GitHub and sets it up every time you fire up the server, you can. If you want to import the latest version of the live database at the same time, you can do that too.

It changes the way you think about working locally. Instead of your own LAMP environment that you maintain separately to your development code, the two become entwined. When you need to work on a client site, just fire up the instance of their server on your local machine and get working straight away. If you want to bring another developer in to work with you, just give them a copy of the instance and they’re good to go immediately – no messing around with set up and configuration and dealing with inconsistencies between their local environment and yours.

The issue? Getting Vagrant set up and tweaked in the way you want it takes a lot of time.

Varying Vagrant Vagrants

Thankfully, after searching around to see if anybody in the WordPress community had considered using Vagrant for local WordPress development environments, I found that Jeremy Felt had not only considered it, he’d created a Vagrant configuration that was pretty much exactly what I needed – a development environment that included Ubuntu 12.0.4 with Nginx, PHP-FPM, MySQL and Memcached out of the box. This is exactly why I love the WordPress community so much!

Varying Vagrant Vagrants is an exploration into the world of of Vagrant and how it can help to make development efficient and in sync with production systems. It replaces the common MAMP or XAMPP setups that we have become familiar with and ensures that all members of the team can develop in the same environment for a project without worrying about the operating system on their local machine.

More at Evolving WordPress development with Vagrant

After setting it up and spending an hour tweaking, I now have a Smart Insights development instance that I can fire up within two minutes that pretty closely matches the live server environment.

Jeremy’s next step is to try and push the managed WordPress hosting companies to give a configuration for their hosting, so us developers can truly match the live server set up. Really hope he’s successful with this!

What’s next

I’m still figuring out the detail of tweaking the Vagrant config Jeremy provides. I’d ideally like the instance to pull a fresh copy of the Smart Insights database every time it’s started – as this is one of the biggest issues with WordPress development – how to keep your local development synchronised. Getting this to work would mean you don’t have to worry about it, and it’d save a lot of time.

I’d love to hear from anyone else using Vagrant for their WordPress local development environment – how are you finding it and what benefits has it brought you over MAMP/XAMPP?

Does WordPress delete expired transients from the database?

Just the other day in Caching using the WordPress Transient API, I explained about using the WordPress Transient API to cache data in the database temporarily, the idea being that you set an expiry date and time against each, and WordPress automatically expires them when this is reached.

So far so good, right? Not entirely. When I was checking to make sure that the expired transients were being cleared properly from the  Smart Insights database, I discovered that the wp_options table was now 130,000 records larger than it was when I launched the transient functionality back on Monday. A little more digging showed that every transient record created since Monday was still in the DB, including all those with an expiry date in the past.

WordPress does not seem to be deleting expired transients from the database.

So why are transients not being deleted automatically?

A little googling brought me to a post from WPEngine on the subject;

But with the WordPress Transients, you get different but still very undesirable behavior. Because the values are written to the database, not a fixed-sized block of RAM, they all stick around. Which means even with the heavily-loaded site, you still have your session data. Awesome!

Or so you thought. Because what isn’t said in the Transient API is what happens when you use unique keys like sessions. And what happens in with the built-in method is that the options table fills up indefinitely! Because: WordPress’s “old data clean up” only operates when you request the key (as we covered earlier). If you just leave the key, it’s left in the options table, forever. There’s no separate process that cleans these up!

More at A Technical Transients Treatise at WPEngine

In my case, since I’m appending the visitor’s PHP session ID to set or check for transients, that rarely happens. So my database gets filled up with lots of expired and redundant data.

What’s the solution to removing transients automatically?

Put simply, you have to remove them yourself – but never fear – the wonderful plugin community comes to the rescue in the form of a plugin to handle this for you. Grab the plugin Purge Transients from Github, put it in your plugins folder and activate it in your WordPress admin. Now any expired transients will be deleted from your database after 7 days.

If you want to force WordPress delete expired transients sooner (like me), open up the purge-transients.php file in a text editor and change the following line to your desired timeframe;

function purge_transients($older_than = '7 days', $safemode = true) {

Hooray! No more unnecessary redundant data clogging up the wp_options table.

Caching using the WordPress Transients API

The WordPress transients API offers a simple and standardised way of storing cached data for a defined amount of time in the database, after which it will expire.

SpeedoWhat is the WordPress Transients API?

Caching is an extremely important part of your WordPress development toolbox. If your site is running the same database queries again and again on each page load, you should take time to consider whether it’s really necessary. Is it really that important that your data is absolutely live to the second, or would it be okay to have this updated every hour? Serving from the transient cache makes your site load as quickly as possible without unnecessary database queries.

Why would I use transients instead of options?

WordPress savvy developers are probably aware of the WordPress Options API, which allows you to save custom name value pairs in the WordPress database, and are used frequently by plugins to store option settings. So why not just use this instead of transients?

The answer is that options do not have an expiry – they’re fixed and remain until updated or removed. Transients have a fixed expiry time and are removed automatically when the expiry time is reached. So if your data does not need to expire at any point, use an option. If it does need to expire, use a transient.

Another advantage of using a transient to store your cached data is that they’re sped up by using general WordPress site caching plugins such as W3 Total Cache, as explained by the WordPress codex entry for the transient API, whereas Options are not:

Also of note is that Transients are inherently sped up by caching plugins, where normal Options are not. A memcached plugin, for example, would make WordPress store transient values in fast memory instead of in the database. For this reason, transients should be used to store any data that is expected to expire, or which can expire at any time. Transients should also never be assumed to be in the database, since they may not be stored there at all.

How to create and use a transient

Recently I created and launched international pricing on the Smart Insights site. This functionality uses the IP2Location service to determine the geographical location of the visitor from their IP address, and then serve appropriate prices and currencies depending on their location.

During initial testing, I noticed that validating the user’s location to output correct pricing was adding an unsatisfactory overhead to the page load, so I began to look how I could cache this information in a transient in order to reduce the number of calls to the geolocation service.

In order to do this, when a new visitor lands on the site, I check their IP, find their location, then set a transient containing the pricing and currency information;

// Check to see if a transient exists for the current visitor
$smartins_geo = get_transient('smartins_geo_trans_'.session_id());

if (!$smartins_geo) {
$user_geo = // do geo lookup and return pricing information here
//set_transient( $transient, $value, $expiration );
set_transient('smartins_geo_trans_'.session_id(), $user_geo, 3600);
}

A quick breakdown of the above;

  1. First I check to see if a transient already exists for this user using the get_transient function. Because I need to set the value against each site visitor the first time they visit the site, I’m appending their PHP session ID to the end of the transient name. This allows me to retrieve the transient for them on next page load.
  2. get_transient returns false if the transient does not exist – so I use this next to decide whether I need to set_transient for the user. If I need to do this, I then perform my look up using the IP2Location service – code to do this not included above – but it returns an array $user_geo with all of the pricing information. I then create the transient for the user.
  3. I’m using an expiry of 3600 seconds, which is an hour. You could set this to as long as you like – I’ve used an hour as it’ll be the maximum amount of time a user will get a certain price in case we decide to change the prices.

On next page load when this code runs, it will find the transient already exists for the current user and retrieve the pricing information directly from it.

I’d be really interested in knowing what other developers are caching with the WordPress transient API – let me know in the comments!

Update: 24th April 2013 – Turns out that WordPress doesn’t automatically remove expired Transients from the database – read “Does WordPress delete expired transients from the database?” for a simple solution.

How to extend the WordPress cookie timeout for auto-login

We’ve had a number of support request on Smart Insights recently from users asking us why they have to keep logging back into the site, even after ticking the ‘remember me’ option on the login form. 

No entry

At first I approached this as a potential bug, but after a little digging discovered that WordPress cookie timeout is only set to 14 days for auto-logins.

For a site like ours 14 days isn’t really enough, so I did a bit of digging to see if there was a way to easily change the length of time it takes before WordPress to force users to log back in again.

There is a plugin available that will do this for you, but it hasn’t been updated in over two years – configure-login-timeout. To be completely honest loading your site with plugins to accomplish relatively small configuration tweaks like this isn’t a great idea – it increases the chances of you having conflicts throughout the site and you’ll have yet another admin screen to remember for something that you’ll likely only ever use once.

The easy solution to extending WordPress cookie timeout

After a bit of research I found a simple solution, so I thought I’d share in case it’s any use to anyone else. All you have to do is add the following to your theme’s functions.php file;

function change_wp_cookie_logout( $expirein ) {
 return 15552000; // 6 months in seconds
}
add_filter( 'auth_cookie_expiration', 'change_wp_cookie_logout' );

Should you want a different expiry time than six months, just work out how many seconds are in your desired duration, and change the value after return.

Hope that saves someone the effort of hunting for a simple solution to extend the WordPress cookie timeout for auto-login.

Code snippet – strip links from string in PHP

Ever wanted to quickly and easily strip links from a string in PHP, but don’t want to use strip_tags because it forces you to manually specify every tag you want to keep, and not letting you tell it which ones to strip?

The other day while doing some PHP development I had an issue with a custom WordPress template that was shortening a string to 100 characters on output. The HTML of the page was broken, which was causing content within a jQuery tab to not display.

I couldn’t figure out why at first. And then I realised that the shortened version ended before the link HTML was completed, which caused the browser to see it as a half closed tag and break.

Thankfully there’s a simple solution by way of a regular expression;

$string = "I am a lot of text with <a href="#">links in it"</a>";
$result = preg_replace('/<a href=\"(.*?)\">(.*?)<\/a>/', "\\2", $string);
echo $result; // this will output "I am a lot of text with links in it"

Hope that helps someone else out.

Protecting your site from WordPress brute force attacks

BotnetOver the last week there’s been a lot of noise on the web in regard to a 90,000 server botnet being the cause of an increase in WordPress brute force attacks. 

Today, the US-CERT (United States Computer Emergency Readiness Team) issued a statement on the subject, which goes to show how seriously the attack is being taken;

US-CERT is aware of an ongoing campaign targeting the content management software WordPress, a free and open source blogging tool and web publishing platform based on PHP and MySQL.  All hosting providers offering WordPress for web content management are potentially targets. Hackers reportedly are utilizing over 90,000 servers to compromise websites’ administrator panels by exploiting hosts with “admin” as account name, and weak passwords which are being resolved through brute force attack methods.

More at:  WordPress Sites Targeted by Mass Brute-force Botnet Attack 

Why is WordPress susceptible to brute force attacks?

Usually log in systems have the capacity to set the number of failed log in attempts that can be made before the user account is locked out, either by forcing the user to wait for a period of time before trying to log in again, or by resetting their passwords.

Out of the box WordPress doesn’t have any functionality to limit the amount of unsuccessful login attempts that can be made. This is causing some people to point the finger at WordPress being to blame for being generally insecure;

Truth is, though in general you really should consider installing a plugin like Limit Login Attempts (and yes, I do think that this functionality should be included in WordPress core) in this instance it’s irrelevant.

We’re talking about a pool of 90,000 servers attempting to brute force your WordPress install. That’s 90,000 IP addresses. So having a plugin in place to lock out user accounts for a time period is going to mean you end up locked out of your own site for a long time.

So what’s the solution?

Sucuri, the security company I blogged about recently published an investigation into one of the WordPress brute force attacks a few days ago, which seems to suggest that the vast majority of the attacks are using the default ‘admin’ username or derivatives thereof;

Diving deeper into our data we find a few interesting data points. For instance, we can see the top user names being attempted:

652,911 [log] => admin
10173 [log] => test
8992 [log] => administrator
8921 [log] => Admin
2495 [log] => root

In these cases, by the shear fact of having a non- admin / administrator / root usernames you are automatically out of the running. Which is kind of nice actually.

More at Mass WordPress Brute Force Attacks? – Myth or Reality

This seems to suggest that the best way of protecting your site is to make sure that you don’t have an administrative user with one of those usernames, something Matt Mullenweg, the original creator of WordPress agrees with;

Here’s what I would recommend: If you still use “admin” as a username on your blog, change it, use a strong password … Do this and you’ll be ahead of 99% of sites out there and probably never have a problem. Most other advice isn’t great — supposedly this botnet has over 90,000 IP addresses, so an IP limiting or login throttling plugin isn’t going to be great (they could try from a different IP a second for 24 hours).

More at Matt’s blog – Passwords and Brute Force

Can’t state it more clearly than that – take immediate steps to change any administrative usernames that feature in the Sucuri post using the blog post Matt mentioned, and at the same time give it a strong password. This is a solution that doesn’t require any development expertise, either, so there’s no reason for every WordPress site administrator to avoid doing it.

You may also want to look at the Better WP Security plugin – it parcels the ability to change the username with a lot of other security enhancements. And sign up for Sucuri – now more than ever that $90 seems like a sound investment!

I’d be interested to know what others think is the best way of protecting your WordPress site from an attack such as this in the comments.

Why do you need a WordPress managed hosting provider?

Now that WordPress powers 17.6% of the world’s websites, we’re seeing an increase in hosting companies that specialise purely in managed WordPress hosting. These can be very expensive – often over a $100/month when compared to your regular hosting. So what are the benefits above a normal shared or managed hosting provider?

What are the advantages of a WordPress managed hosting provider?

1. Performance

Managed hosting providers like this only host WordPress, so their hosting platforms are geared to run WordPress as quickly as possible. Often these will use;

  • Web server – Nginx rather than Apache for speed
  • Cache – Varnish or APC (Alternative PHP Cache), with a WordPress caching plugin such as W3 Total Cache to take the load off the database and serve your site from a cache as quickly as possible
  • CDN (Content Delivery Network) – a set of servers positioned all around the world which cache a copy of your content — usually statics like images, javascript, and stylesheets. This means that your users get their content served to them from the nearest location which reduces response times and increase loading speed
  • Clustering – running your site on a set of identical machines, simultaneously. If any machine goes down, your site is still served from the others. No single point of failure like on a shared host or dedicated box.

2. Security

As they’re WordPress focused experts, these companies will offer specific security tailored to WordPress;

  • Audited security policies – they will make certain that the server configuration is locked down to the correct permissions, ensuring that your site can’t be easily hacked
  • Plugin and theme curation – often they will monitor WordPress installs to check the effect of each plugin on the speed of your site and their systems. Some, such as WPEngine will actually prevent you from installing plugins that they believe unacceptable.
  • Intrusion detection, hardening and malware detection and removal – your site is monitored proactively for any malware attacks, often using software such as Sucuri. In most cases the WordPress managed hosting provider will state that they’ll fix any malware attacks as part of your hosting package
  • Managed backup and restore – though you can (and should!) have a managed backup solution in place using something like VaultPress or BackupBuddy, often these managed hosts will have their own system which offers daily (sometimes hourly) backup and more than likely a one-click restore of your site and database in case of issues.

3. Support, expertise and experience

Finally, but very importantly, you’re paying for premium support, expertise, knowledge and experience. These hosting companies know WordPress inside and out and offer much more than a regular hosting company would;

  • Monitoring and uptime – if your site goes down, chances are these guys will know about it before you do and will already be working on getting it back online
  • 24 hour support – many cheaper hosts will only respond to “non-urgent” requests within office hours. If you’re a UK company hosting in the US this can lead to a long lag between your requests being answered – often managed WordPress hosting providers will office full technical support on a full 24 hour a day basis
  • Code support not just server support – with a standard host they’ll support the server environment, but ask them to help you on a problem you’re having with any code and they’ll tell you it’s your problem. Managed WordPress hosting providers go out of their way to help you – even down to helping you fix your code if required.. providing you don’t take advantage, of course!

There are obviously many ways in which a WordPress managed hosting provider justifies the greater monthly cost over regular hosting. I’m currently migrating the Smart Insights site to one of these hosting providers – Synthesis. Once that’s done I’ll compare it with the other leading WordPress managed hosting provider, WPEngine from personal experience of using both for high traffic sites.

I’d be interested to know what other WordPress managed hosting providers are out there – let me know in the comments.

How to add an XML sitemap in WordPress

WP Beginner recently posted a great primer article on the importance of a XML sitemap in WordPress – they recommend Yoast‘s SEO plugin as being the best sitemap generator in WordPress. Well worth a read..

Why You Need an XML Sitemap

From a Search Engine Optimization (SEO) point of view sitemaps are extremely important. First we would like to clearly state that adding a sitemap does not affect search rankings. However, if there is some page on your site that is not indexed, then sitemap provide you a way to let search engines know about that page, so it can be indexed properly.

Sitemaps are very useful for new websites and blogs. As most new blogs usually don’t get many backlinks to their individual posts, it becomes harder for search engines to discover all of their posts and pages. Sitemaps allow those websites to help search engines crawl their sites more efficiently.

For popular websites, sitemaps allow your website to interact with search engines more effectively. Search engines can guess how often your site is updated, which parts of your website are more frequently updated than others, set crawl rate for your site, etc. This improves the overall visibility of your site to search engines….More at What is an XML Sitemap? How to Create a Sitemap in WordPress? Image by  via Flickr

When I launch a new WordPress site, Yoast’s SEO plugin is one of the first things I install, though I rarely touch the settings other to make sure that the XML sitemap is generated and has been submitted to Google and other search engines. It’s good to have such a comprehensive primer that explains why sitemaps are so important.

Since it’s so popular, I wonder of anyone actually uses anything other than Yoast’s plugin as a sitemap generator in WordPress?

How to choose a WordPress membership plugin

There are a lot of WordPress membership plugins out there these days, but which one is best for your site?

It’s important to first understand what you want your membership site to do – not all membership sites are the same. Chris Lema put together a comprehensive guide late last year which helps you to figure out what you need;

There is no point (at least in my mind) to score the plugins and tell you which one got the best score (though I did it and have the spreadsheet to prove it). And you know why already. Because what you care about and what I care about may be different. More than that, you may care about different things based on the site you’re creating. So it comes down to what you care about most. So what I’m not going to do is give you a sorted order of the best ones. Instead, what I want to do is give you the top two plugins you should check out based on the factor you care most about.

I’m going to cover four different drivers of your decision:

  • Price
  • Content Dripping
  • Pausing Memberships
  • Using Stripe

More at Comparing WordPress Membership Plugins

The first three I agree completely with. The fourth, well it depends on how you feel personally about PayPal. Chris clearly hates it, and as a result WordPress membership plugins that don’t use the Stripe payment system rate badly. The problem with that for us in the UK is that Stripe isn’t available for us over here. They recently announched they were in beta in the UK, but then denied it.

Another reason to perhaps not use Stripe – they have a flat fee per transaction and this doesn’t reduce even when you’re putting a lot of volume through. PayPal reduces the per transaction fee as your monthly sales rack up, and for us at Smart Insights that discount racks up. Stripe would cost us a lot more than PayPal each month. I’ll add that there are many things about PayPal I hate – their support and horrendous administration interface to name two, but when it comes down to price they’re better value than Stripe at the moment.

Chris also has a handy infographic to step you through the choices;

Guide to WordPress membership plugins
Guide to WordPress membership plugins
WPLift has a good breakdown of the range of WordPress membership plugins 2013 has to offer – focusing more on paid plugins, which I have to say I agree with – if you’re looking to charge for membership, shouldn’t you really pay for a solution that gives your customers the best experience? Here’s what they have to say;
Today we’re going to discuss some of the best WordPress membership plugins available in the market and compare their features. Kindly note that developing these plugins takes an insane amount of effort starting from writing code for PayPal integration to support forums. Thus, most of them aren’t free except two genuine exceptions….More at Complete Guide to WordPress Membership Plugins
At Smart Insights I tested a number of solutions before we settled on our solution;
  • WishList member ($97) – really didn’t like this – when it didn’t support custom post types and the code is obfuscated, which is against the WordPress license and a generally lousy thing to do
  • Magic Members ($97) – we actually went with this and spent a good month integrating it, only to throw it all away and start again as it made some of the bespoke functionality we wanted to add just too difficult – it was pretty fixed in the way it worked and didn’t have easy ways to piggy-back of their functionality
  • Justin Tadlock’s Members (free) – was going to be too much work to get it to do what we needed for content protection and payment

In the end I settled on the paid version of s2member ($69) – we needed the paid version as we wanted to use PayPal Website Payments Pro as it looks a lot more professional than sending users off to a nasty looking PayPal screen on payment. S2member have a comprehensive set of documentation and API which has allowed us to use it in the background, but essentially change the way it works on the Smart Insights site. Their support has been fantastic on the couple of occasions I’ve had to use it as well. It comes very recommended – provided you don’t mind working with PayPal!

When it comes down to it, your choice of a WordPress membership plugin depends a lot on your specific requirements. I’d love to hear about other people’s preferences.

WordPress mp4 videos supported without plugins in 3.6

Following on from my last post on WordPress 3.6 and post formats comes the news that mp3 audio and mp4 videos are now supported directly via new video and audio shortcodes.

WordPress audio/video embed
WordPress audio/video embed

Previously you needed to install separate plugins to embed these formats, as they weren’t supported by the standard WP_embed shortcode. Here’s the full details directly from the Make WordPress core blog;

Audio / Video support in Core

Post Formats are a big feature in WordPress 3.6. What you may not know is: there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.

How does this work?

At the core of the experience is the fantastic library, MediaElement.js. MediaElement is the facade layer that gives us maximum file support and cross-browser compatibility. While some libraries require a Flash-only solution to make your media work cross-environment, MediaElement lets you use HTML5 audio / video tags in every browser, and, only when necessary, will use a Flash or Silverlight plugin in the background to make incompatible media work. Translation, things like this: <audio> tag works in old IE, Windows Media files work in Chrome.

MediaElement uses the same HTML markup, regardless of playback implementation, and you can use CSS to skin the players.

More at Make WordPress Core

This is a great step forward for WordPress media handling, and a timely one for me as I’m just starting to build a new online digital marketing course extension for the Smart Insights site – this will be using mp4 as the video format so it’s nice to know that using core I can add WordPress mp4 videos natively now!