BlogmyQuery – BMQ

We all know that WordPress is awesome — but being awesome isn’t always enough. Does it perform well under pressure? Can it deal with traffic from millions of visitors every month? There’s no question that WordPress can be used for your or my blog, but what about multi-author blogs with thousands of comments? How do developers make it scale and perform?

I spoke with the developers behind some of the biggest WordPress blogs on the planet and asked them to tell me their secrets. Now I get to share them with you.

The Blogs

In The Beginning

The first thing I asked the developers was whether they prepared for the heavy traffic that now flows through their website. In almost all cases, the answer was a resounding no. From The Next Web, CTO Arjen Schat and lead developer Pablo Roman said they had planned for growth but didn’t expect growth to happen on such a large scale. “There were few large WordPress sites at the time, so we learned as we went along.�

Neatorama started out in late 2005 on cheap shared hosting until it got kicked out. It moved to a VPS and got kicked out again. In 2007, it moved to a dedicated server with a CDN, which eventually was insufficient, until finally it moved onto load-balanced servers with a CDN. Similar stories are echoed by iPhoneClub.nl and Laughing Squid.

Hot Air’s developer, Mark Jaquith, also a lead developer at WordPress, had to migrate his website to a new server within 48 hours of launching. Only SlashGear planned for a 30% increase in traffic per year.

Digital Trends started out with around a million uniques a month and has since risen to 10 to 12 million uniques. Tom Willmot, of Human Made, the development shop behind Digital Trends, said this of starting out:

When I started work on the website, there were some pretty big performance sinks in the code base that needed ironing out. A clean code base takes you only so far, however. I don’t think it’s something that should be too heavily focused on at the outset as you don’t know what specific features will need performance considerations. Coding well plus some persistent object caching are enough to begin with.

Server Shred And Burn

High-traffic blogs have to deal with things that regular bloggers only dream of: loads and loads of visitors, eager to read all of the latest news. Neatorama held up when it was featured on the front page of Digg, but was shredded within a few minutes of being featured on Yahoo’s front page — over 2 million visits in the space of a few hours. To deal with that, it had to make a static page on a CDN and redirect traffic there.

Other blogs face challenges related to major events. Visitors flock to their websites to follow what’s happening and hear the news. iPhoneClub.nl and SlashGear are particularly affected during Apple’s live broadcasts. SlashGear experiences traffic of more than 4 million uniques within the two hours of a broadcast’s duration; to deal with this, it adds Amazon EC2 to its normal infrastructure.

Jean-Paul Horn, whose iPhoneclub.nl started out on WordPress 2.0.5, had to learn to deal with these problems on the fly:

We used to run a standard LAMP stack with WP Super-Cache, since the site was already growing rapidly when the iPhone started to get really popular. Our main problem was that the server ran perfectly fine on normal news days, but almost literally burned whenever Apple had a keynote or another big iPhone-related announcement. We tried preparing for these short avalanches by temporarily adding more cores and RAM, but it was never really enough, and I wasn’t really keen on investing in a big-ass server just for two to three days of insane amounts of Web traffic a year.

While moving to a Web server and database server with MySQL stored on a separate server helped in its continuing growth, it was still dealing with the same issues when Apple held a press conference. Enter Frederick Townes of W3 Total Cache and Mashable fame. Jean-Paul met Frederick at WordCamp Netherlands, and Frederick went on to help them set up their current configuration:

• The app server hosts the Varnish front end.
• They use two nginx Web servers: one with PHP-FRM, the other with static content, like a CDN.
• The database server runs a highly tuned MySQL server, in which some of the WordPress tables, such as wp_posts, have been transitioned from MyISAM to InnoDB. Because InnoDEV doesn’t have full text search, Sphinx Search was implemented.

Jean-Paul has been using this configuration since November 2011 and has survived two major Apple events without any of the previous load issues or other performance troubles. They’ve also been able to accommodate more traffic and have beaten all of their previous traffic records.

Dealing With Growth

Hot Air

US political blog Hot Air has gone through some major performance and scaling sprints, particularly in advance of US election years. An election guarantees a larger than average flurry of activity around politics. Given that politics is already one of the most popular topics on the Internet, this means some hardcore scaling. Mark Jaquith explained to me the steps he has taken to cope with scaling:

• Deliver all static assets through a CDN.
• Set up a load balancer, with multiple Web back-ends behind it.
• Cache the front page proactively
• Cache page fragments (such as sidebars) proactively, so that they can be loaded statically.
• Cache recent posts proactively (mostly the ones displayed on the home page). Every time a post is updated or a comment is left, a back-end process generates a new static snapshot of the page and distributes it to the Web machines.
• Eliminate the cache differentiation between logged-in and anonymous viewers. Most caching plugins don’t cache pages for logged-in users, or if they do, they cache a different version for each viewer. Hot Air’s templates are modified so that there is no difference in the HTML generated for logged-in and anonymous users, so there can be one shared cache pool.
• Use Batcache (with a Memcached object cache back end) to cache views of old content.

The Next Web

As with most of these other blogs, scaling was forced upon The Next Web. The founders did plan for growth, but not on the scale they encountered. Arjen and Pablo went into detail on how they dealt with it.

The team’s essential tools are:

• Varnish as a reverse proxy and for ESI (Edge Side Includes);
• Memcached to store the results of heavy queries, such as popular stories;
• Munin for monitoring.

Setting this up wasn’t enough, though. All of this had to be tuned, and poorly performing plugins and code had to be identified. To do this, they did the following:

• Use MySQL slow query log with no-index enabled.
  Keeping your MySQL slow logs empty is essential. Your key cache suddenly might not be sufficient anymore if your data is growing.
• Use XHprof for code path analyses.
• Keep Apache logs clean.
  External referrers will link to pages on your website that don’t exist anymore. If a WordPress 404 page is loaded every time, then you’re doing work that can be avoided. Generating a 404 page can be heavy, so it needs to be cacheable in Varnish as well.

The team at The Next Web also uses additional tools with Varnish to improve cache hit rate. These include:

• varnishtop
  Lets you look into Varnish.
• varnishtop -i txurl
  This shows you all of the requests that make it into Apache that aren’t cached by Varnish. This helps you to identify different cases:
  • Whether the back end sends a header that Varnish can’t cache;
  • Whether the back end starts a session that isn’t needed;
  • Partially malformed links to your website, such as http://thenextweb.com/apple/http://referrer.com/my/cool/article;
  • Small variations of a normal request that you can normalize in Varnish, so that you can serve the standard page, such as http://thenextweb.com/correct/article/link?utm=campaign.
• WP-VCL
  Their basic VCL, which normalizes many different request into the standard versions.

An essential step for The Next Web was developing the ability to serve cached content to logged-in users. To do this, it pulls in all of the user-specific parts of the page and loads these through an AJAX call. This means that content doesn’t need to load all of WordPress. The developers have duplicated all of the code that is needed to handle logging in and basic user-profile stuff in WordPress into its own tiny login class. The class takes 1 millisecond to load, instead of 100 to 200 milliseconds to load through the whole WordPress stack. This prevents WordPress from loading for a trivial request, which can degrade the overall performance of your website by eating CPU cycles that should be used to render pages that are not cached. An added benefit is that WordPress can render all pages in non-logged-in mode.

This is used simultaneously as a feature of Varnish called ESI, which lets the team cache different sections of a page separately with different expiration times. This lets them show fresh content in the sidebar widgets even if the main content has a long expiration time.

Essential Plugins

• W3 Total Cache: iPhoneClub.nl, The Next Web, Digital Trends
• WP Super Cache: Laughing Squid
• WP Widget Cache: iPhoneClub.nl
• Plugin Output Cache in conjunction with Similar Posts, Recent Posts and Recent Comments: iPhoneClub.nl
• Clean Options: iPhoneClub.nl
  To keep WordPress’ easily bloated options table tidy.
• WordPress Sphinx search plugin: iPhoneClub.nl
  To connect WordPress with the open-source Sphinx search project.
• WPVarnish: The Next Web
  or cache busting.
• Term Management Tools by Scribu: Hot Air
  Useful for merging duplicate tags.
• Memcached Object Cache Plugin: Digital Trends
  Lets you run a persistent object cache outside of PHP-APC. This is important if you’re running multiple servers.
• Varnish: Digital Trends

Essential Tools And Services

• VaultPress: Hot Air
  Real-time back-ups.
• WordPress.com stats: Hot Air
• Google Analytics: Hot Air
• Chartbeat and Newsbeat: Hot Air
• A CDN: everyone
• SoftLayer: Slashgear
  A dedicated hosting company that Slashgear has been with for seven years.
• Cloudflare: Laughing Squid
  Provides Web performance and scalability services.
• Disqus: Slashgear
  Helps to socialize engagement and offset comment loads from its servers.
• Solr: The Next Web
  For search.

Challenges

High Levels of Caching

All of the blog owners I spoke with have high levels of caching. Digital Trends deals with this by using Akamai Distributed, Varnish and Memcached. When this is combined with user log-ins and registrations, it can be difficult to make sure that everyone is seeing what they should be seeing while caching as many things as possible.

Mobile

iPhonclub.nl has to deal with a relatively high number of mobile visitors. In the past, it used WPTouch for iPhone visitors (along with its native app). The server team had to do major work with Varnish, nginx, and W3TC to keep the caches for desktop and mobile visitors separate, thus making user configuration more complex. However, later this year iPhoneclub.nl will merge with iPadclub.nl to become iCulture.nl. In addition to the merge, they are moving to a responsive design, which will better suit the new website and solve the issue of dealing with mobile visitors.

Built to Work, Not to Perform

A challenge raised by The Next Web is the actual architecture of WordPress. While using all of the options and all of the plugins is easy, they are built to work, not to perform. With every code change, you have to make sure it doesn’t cripple performance.

Security

Security is a big issue for every WordPress user, particularly for high-visibility websites. As Neatorama points out, keeping WordPress up to date isn’t always enough. You also have to keep your server’s operating system up to date as well.

Some websites need a huge server. (Image: Skimaniac)

Scalability

Slashgear has found it challenging to scale WordPress without chucking more hardware at it. It uses a caching system, but WordPress is built to be dynamic, and caching in a dynamic environment does not always work smoothly. The developers have overcome this by modifying their plugins to use AJAX to pull live data on statically cached generated pages.

Comments

A website like Hot Air can receive hundreds or even thousands of comments for a single post. There are dozens of posts every day, and the website has been live for six years. “With that many comments,� says Mark, “you really have to look at database optimization. We have a few custom plugins that intercept comments queries and rewrite them to be simpler. And you want to limit the number of queries you make against that table. For instance, I killed the ‘Right Now’ and ‘Recent Comments’ sections of the Dashboard.�

Events

As discussed regarding iPhoneclub.nl and SlashGear, Hot Air has to deal with its own major events. When a big political event is happening, just a few minutes of downtime can do damage. Mark has warning systems and automated responses in place. In the event of an problem, he can set up something to automatically fix it if it recurs or to notify him when something indicates that a performance issue is imminent.

Would You Say Goodbye To WordPress?

I asked all of the blogs whether they’ve ever conceived of a situation in which they would have to move beyond WordPress. Here’s what they had to say.

Tom Willmot, Digital Trends

I really don’t like the whole “WordPress is slow� rhetoric. It’s just PHP plus MySQL — so is Facebook. It is possible to move beyond certain things that WordPress does (for example, perhaps you replace the rewrite engine with something more efficient), but to decide fundamentally that WordPress is somehow slow and needs to be gotten rid of is probably avoiding the specific issue that is the problem. Sure, there are aspects of WordPress that can be slow if you don’t do anything about them, but this is far outweighed by everything that you do get.

Writers love the WordPress back end; WordPress.com runs some of the largest websites in the world. Digital Trends servers 33 million pages a month for a website that is hugely more complicated (from a technical point) than a blog.

Jean-Paul Horn, iPhoneclub.nl

I can’t for the life of me think why I would want to do this. I have been using WordPress since early 2.0. My wife started iPhoneclub.nl in December 2006 on WordPress 2.0.5 and we haven’t looked back since. I had some previous experiences with PHP-Nuke and Joomla, but WordPress has really grown on me for its simplicity and huge developer community.

For almost every missing piece of functionality in core, a plugin is available or so easy to patch that you could write your own theme-specific function. I evaluated both Drupal and ExpressionEngine (then called pMachine) when we faced our performance issues, but stuck with WordPress because of its extensibility and there was already a clear vision laid out for WordPress becoming more of a full-featured CMS.

The Next Web

I don’t see a situation where you need to move beyond WordPress, as long as you don’t fall into the trap of thinking you can do everything with a plugin.

Laughing Squid

WordPress continues to evolve along with us and is still the best platform out there for blogging. There is every indication that it will continue to be so in the future.

SlashGear

[We would leave] when WordPress becomes too bloated. As you can see, each major WordPress version comes with more hooks (WordPress 3.0 had a little over 750 hooks, and 3.4 has over 1500 hooks). At this point, we prefer scalability and platform robustness over features that are not commonly used.

Mark Jaquith, Hot Air

No way. Comments are the hardest thing to scale, and there are solutions for that, such as using an external service or even sharing comments between multiple tables. I haven’t yet come across a problem that I didn’t think could be solved, and the flexibility and extensibility of WordPress have proved invaluable.

Saying Goodbye

Why would anyone ever want to leave WordPress? One of the blog owners I spoke with was in the process of doing just that. Neatorama’s e-commerce operation, NeatoShop, has grown, and it has decided to integrate the blog and the shop into one platform. This makes it possible for it to tailor its publishing process to fit its particular needs, such as scheduling and queueing multiple posts, maintaining multiple blogs with a single dashboard, cross-posting and having an inline commenting system. For Neatorama, the problem wasn’t WordPress itself, but that they couldn’t implement large-scale e-commerce.

I asked Alex Santoso of Neatorama why he hadn’t considered using a WordPress e-commerce plugin such as WooCommerce or WP E-Commerce. Here’s what he had to say:

Because e-commerce isn’t just a shopping cart — there’s a whole other logistics fulfilment and shipping back end to it. We grew NeatoShop from selling just 12 t-shirts to over 5,000 items today, and we had to write our own software to enable us to process (i.e. ship) orders efficiently.

I’m doubtful that you can do large-scale e-commerce with plugins. Selling a dozen items or so should be no problem, but keeping track of thousands of items in inventory, minimizing fraud, automating, and the logistics would be.

It’s interesting that Neatorama feels that plugins aren’t sufficient to carry out large-scale e-commerce. But how does Alex feel about WordPress as a publishing platform?

We’re not moving away from WordPress because it’s failing us as a blogging platform. Rather, our business evolved from being a pure publisher into a side-by-side e-commerce and blogging operation. WordPress and its vibrant community continue to be a great choice for most publishers big and small.

Learning From The Pros

It’s great to hear about what all of these websites are doing, but what advice can they offer you?

Servers

Learn how to deal with servers, or get someone who does. You should know how to configure nginx and PHP-FPM, MySQL slaved with HyperDB, Varnish VCLs, and NFS. “If you don’t know how to deal with the stuff in between a browser sending the request and your code running,� warns Tom Willmot, “it will seriously limit you in terms of how things can be improved and also debugging issues. Server issues can be extremely frustrating; if you don’t have a handle on it, it will come back to bite you.�

Read and Learn

Jean Paul Horn advises that you should keep up with the latest performance recommendations, and he particularly recommends the following:

• Steve Sounders,
• Web Performance Today,
• Articles about performance right here on Smashing Magazine,
• A saved Twitter search with the #webperf hash tag.

Ask for Help

“Don’t be afraid to ask for help,� says Jean Paul. “The community out there is exceptional and truly supportive.� Spend money hiring WordPress performance experts. This provides an excellent return on investment. If your website goes down or is unreachable, potential readers could end up with the competition. Trying to visit a website that is constantly down is frustrating for the visitor, and they won’t stick around.

Shop Around

Alex Santoso suggests that you “Shop around for hosting costs. Similar hardware configurations can have vastly different pricing from different hosting companies.�

Trail and Error

SlashGear suggests that you use trial and error to get your configuration right. Decide whether a plugin is really necessary. Many plugins use many resources for a simple function that could be hard-coded into the theme. “Adding new hardware and server resources isn’t always the solution,� said Ewdison Then, “but sometimes it’s the only solution.�

Optimize What Matters

Mark Jaquith recommends that you don’t optimize blindly. “Find out what the biggest bottlenecks are and eliminate them. Rinse and repeat.�

WordPress Performance Resources

If you feel inspired to start scaling, here are some resources to check out:

• “Scaling, Servers and Deploys, Oh My!â€� (video), Mark Jaquith
• “High Performance WordPressâ€� Themes Forge
  A three-part series.
• “WordPress Performance Server: Debian ‘squeeze’ with Nginx, APC and PHP from the Dotdeb repos,â€� Chris Olbekson, C3M Digital
• “Do-It-Yourself Caching Methods With WordPress,â€� Milan Petrović, Smashing Magazine
• “Performance Optimization for Websites,â€� Rene Schmidt, The Smashing Book
• “Scaling WordPress”
  WordPress experts share advice on scaling

Many thanks to all of the people who contributed their knowledge to this post:

• Tom Willmot (Human Made) for Digital Trends;
• Jean-Paul Horn for iPhoneclub.nl;
• Zee M Kane, Pablo Román and Arjen Schat for The Next Web;
• Alex Santoso for Neatorama;
• Ewdison Then for Slashgear;
• Mark Jaquith (Covered Web Services) for Hot Air;
• Scott Beale for Laughing Squid;
• And thanks to Simon Wheatley (Code for the People) for a final sanity check.

(al)

© Siobhan McKeown for Smashing Magazine, 2012.

Today I get to write about something close to my heart: documentation. The emails I love the most start with, “I’ve got this new product. Please, document it!� I get a lot of pleasure from learning about someone’s code and making it as clear as possible for users. I love taking a great product and making sure that people get it.

In this article, we’ll look at writing documentation for a WordPress plugin, theme or product. Most of the information can be applied to documentation for other software types, but we’ll look at some WordPress-specific aspects.

In my experience, the quality of documentation in WordPress plugins and themes varies widely. From poorly documented plugins with one-line readmes to products with user guides, developer APIs and in-depth screencasts, you’ll find every type of documentation in the WordPress ecosystem. Many plugins and themes are built by developers who don’t have the time to write documentation or don’t have the money to pay a technical writer.

Unfortunately, the person who suffers the most from this is the developer. In a blog post, author and front-end developer Nicholas Zakas gives his number-one reason why good JavaScript libraries fail (quoted here — the original is no longer online):

Lack of Documentation:

“No matter how wonderful your library is and how intelligent its design, if you’re the only one who understands it, it doesn’t do any good. Documentation means not just autogenerated API references, but also annotated examples and in-depth tutorials. You need all three to make sure your library can be easily adopted.”

Taking Zakas’ statement as a starting point, let’s look at how to make sure your WordPress product can be easily adopted. We’ll look specifically at how to provide useful documentation to end users, with a brief diversion to writing for developers. But first, let’s dive into some learning theory.

Learning Preferences

A few years ago, I took a teacher-training course while teaching writing to adults. While I don’t teach much anymore, I still integrate an aspect of learning theory into my process when writing documentation. VARK is a theory of learning preferences. It’s an acronym of visual, auditory, read/write, kinesthetic.

VARK captures various preferences for taking in and implementing information where learning is the objective. This makes it extremely useful for writing documentation. Thinking about how your users process your information and how to make it as easy as possible for them is helpful. When writing, think about the different ways that people engage with and process the information your provide; VARK argues that there is a spectrum for the way people do that.

The VARK diagram.

To discover what your VARK learning preference is, you could take a short questionnaire. The results will place you in one of the four different modes — or you could be multimodal, meaning that you prefer a number of styles. There are different learning theories, but I find this one useful for thinking about the different types of documentation that I’ll need when working on a project.

In essence, VARK tells us that people learn in different ways, and in any pedagogical exercise we ought to think about how to make those ways as useful as possible. Let’s look at the different learning preferences and how to make sure you’re making full use of them.

Visual

Visual learners prefer to take in information that appeals to the eye. The VARK website lists the following as relevant techniques:

• Presenters who use pictures or gestures;
• Pictures, posters and slides;
• Books with pictures and diagrams;
• Flow charts and graphs;
• Highlighted text, multiple colors and underlining;
• Symbols and white space.

These suggestions relate to the classroom, but translating them to documentation is not difficult. Visual learners take a holistic approach, trying to see the whole picture rather than breaking it down into discrete parts. They might scan a whole tutorial or section of documentation before getting started to get a sense of the overall picture. Here are some suggestions for reaching visual learners:

• Use call-outs to draw attention to important tips and notes in the text.
• Include a lot of useful screenshots, writing on them and using highlights and call-outs.
• Use a flow chart to demonstrate a process.
• Highlight important pieces of text, and place key phrases in bold.
• Incorporate graphics that highlight your point.
• Create a screencast like SEOmoz’ Whiteboard Friday, which features a person speaking in front of a whiteboard.

Recommended documentation types: in-depth tutorials, screencasts, graphics, infographics

Aural

Aural learners absorb information through talking and listening. The VARK website suggests the following for these learners:

• Attend classes;
• Get involved in discussions;
• Explain ideas to other people;
• Use a tape recorder;
• Engage with interesting examples;
• Describe things to someone else second-hand.

Because online documentation is such a visual medium, figuring out strategies that would appeal to these learners is more difficult. However, with a little lateral thinking, including them is possible, too:

• Podcasts;
• Screencasts with detailed narration;
• Interesting, practical examples;
• A chat room such as WordPress’ IRC chat, support forums and screensharing on Skype (even though these are not documentation);
• Webinars.

As the list shows, even if your documentation is highly detailed, there will always be people who prefer to ask questions and have a discussion to find out what they need.

Recommended documentation types: tutorials, screencasts, podcasts, webinars

Read/Write

As you can imagine, read/write learners are pretty easy to target with documentation; they really love to learn by reading. But rather than just come up with big chunks of text, you should use variety to make things a little more interesting. Here are some suggestions:

• Lists;
• Headings;
• Dictionaries;
• Glossaries;
• Definitions;
• A large block of text;
• Essays;
• Manuals (computing, technical and laboratory).

While long pieces of documentation are a great way to engage these people, you could do a bit more work to really get them on board. Here are some suggestions:

• Use ordered and unordered lists;
• Make use of all heading tags;
• Include definitions in call-out boxes;
• Link to definitions elsewhere;
• Write a user guide;
• Write a glossary (the one in the WordPress Codex is a great example);
• Produce an eBook or manual.

Recommended documentation types: tutorials, eBooks, manuals, glossaries, references

Kinesthetic

Kinesthetic learners learn best by doing things. Rather than watch a demonstration, they want to get their hands dirty. Here are some methods from the VARK website:

• Using all senses (sight, touch, taste, smell, hearing);
• Going on field trips;
• Practical examples of abstract principles;
• Real-life examples;
• Hands-on approaches;
• Trial and error;
• Looking at collections of things (e.g. rock types, plants, shells, grasses, case studies);
• Exhibits, samples, photographs;
• Recipes (e.g. solutions to problems, previous exams).

Figuring out what types of documentation these people would like doesn’t take much imagination — tutorials would be a big hit. But go a bit further and you’ll find that producing documentation for kinesthetic learners can be really fun:

• Step-by-step tutorials;
• In-depth use cases;
• Links to practical examples;
• Real-life (rather than abstract) examples;
• Interactive learning tools, such as Codecademy;
• Short, practical tutorials such as those on WpRecipes;
• Webinars that walk participants through something practical.

Recommended documentation types: practical tutorials, tips and hacks, use cases

Multimodal

Around 60% of the population don’t fit neatly into any of these boxes. If this is you, then you are multimodal (i.e. you prefer two, three or even four categories). You tend to adapt your learning preference to the learners around you and to the medium you are presented with.

Also, it’s possible for your learning preferences to change, according to your life experience. A developer whose head is stuck in code, APIs and references all the time could easily start leaning towards read/write and kinesthetic learning.

The Point

The point of this diversion into learning theory is simple: to show that people learn in different ways; so, make sure your documentation appeals to all of them.

Sometimes clients tell me they just want screencasts. I ask if they have anything else, and if the answer is no, then I strongly recommend they look at other forms of documentation as well. Personally, I find screencasts very difficult to learn from; I prefer to scan tutorials for an overview before getting started. Everyone is different, and if you want your product to be usable by as many people as possible, then you need to think about all of these different learning preferences.

Thankfully, this is very easy to do. A walkthrough tutorial is a great way to appeal to every learning preference.

• Give kinesthetic learners something practical to do;
• Appeal to read-write learners with ordered and unordered lists, headings and call-out boxes for definitions;
• Call-outs are also appreciated by visual learners, and you can keep them even happier with a lot of graphics, diagrams and images;
• Practical examples will be helpful to aural learners; and to really tick off all of the boxes, you could include a brief screencast.

Don’t spend a lot of time agonizing about this when you get started with the documentation. Just be aware that variation is crucial.

What Types Of Documentation Are There?

As you’ve probably guessed, the umbrella of documentation is pretty large. Anything that documents your plugin, theme or product is documentation. Here are some examples of the types you might find yourself writing:

• Reference
• API reference
• Inline documentation and comments
• List of requirements
• Glossary
• Architecture or design overview
• Tutorial
• Manual
• Readme
• WordPress help menu
• FAQ
• Tooltips
• User guide
• Troubleshooting guide
• Screencast
• Book and eBook
• Quick hacks and tips
• Infographic
• Screencast
• Webinar

The types of documentation you adopt will depend largely on two things:

• Your product type,
• Your audience.

Many WordPress plugins and themes are developed specifically for end users, rather than being developer tools. With that in mind, let’s look in depth at how to produce effective documentation for end users.

Getting Started

Before getting started with any type of documentation, think about these things:

• Have you frozen the features?
  Don’t write the documentation while you are still adding features and making major changes to the code.
• Do you have a plan?
  Write down a structure. Just as a designer would create a wireframe, it would be helpful to sketch out the structure of your documentation, both for individual pieces and for the overall architecture. It will bring a lot coherence to the documentation.
• How steep is the learning curve?
  If your product is complex, then you’ll need to guide users through the documentation, getting them to the beginners’ information first, through to the intermediate, then to the advanced.
• Do you have access to the developer?
  If you are the developer, then great; but if not, this is really important. Your first job will be to learn a product that likely does not have documentation, so you will need to ask the developer questions. There’s no point in starting a documentation project if the developer is about to go on vacation.
• What is the purpose?
  Is the documentation purely to assist users, or is it for marketing, too. A reference doc will be useless for sales, but you might want a tutorial to show off the product to potential customers.

The written word (Image: Arslan)

Here are some practical writing tips to keep in mind once you get started.

• Keep it simple.
  It’s not an opportunity to get poetic or clever. The best technical documentation is clear, concise and engaging.
• Refer to the user in the second person.
  For example, “When you have logged into WordPress, navigate to the plugin’s admin screen.� Write as though the reader is sitting beside you and you are talking them through the process.
• Stick to the point.
  Don’t meander off topic because this can distract users.
• Think about formatting.
  Perhaps you want to use bolding for the key point in each paragraph, or perhaps for instructions. Be consistent in your formatting across the documentation.
• Write in the present tense.
  Again, as if you were talking to someone who is sitting beside you.
• Think about tone.
  I recommend friendly and engaging, but you might want the tone to match the rest of your website’s content.
• Don’t be afraid of short paragraphs.
  Stick to one major point per paragraph so that messages don’t get confused.
• Be logical.
  Drip-feed your information in a logical order to ensure that readers are able to follow.
• Proofread.
  And ask someone else to proofread for you. A fresh pair of eyes will pick up things you miss.

End-User Documentation

The end user is the person who will use your product. In the WordPress environment, I get asked to produce documentation for this type of user the most. There is a wide variety of end users, from total novices to savvy users to people who are developers themselves. If they are using (as opposed to developing) the product, we can consider them end users.

When writing documentation for end users, I always recommend aiming for the absolute novice. By doing this, you ensure that everyone is included. More advanced users can skim the doc and take what they need.

1. Research and Prepare

Before putting fingers to keyboard, spend time preparing what you are going to do and how you are going to do it. At this point, your software should be stable and just about ready to go. Rushing through the documentation process just to get it out there is tempting. But here’s some advice from Mike Pope, a technical editor at Microsoft:

“We’ve been known to tell a developer “If it isn’t documented, it doesn’t exist.â€� […] Not only does it have to be doc’d, but it has to be explained and taught and demonstrated. Do that, and people will be excited — not about your documentation, but about your product.”

Keep that in mind: good documentation makes the best of your software.

• Do you need an installation guide? If your product isn’t in WordPress’ theme or plugin repository, then I recommend preparing a generic guide to show users how to install the plugin or theme via the upload function in WordPress or via FTP.
• Plan everything beforehand. If your documentation will be big, think about the architecture. How will users navigate it? How will you present it?
• Draw a list of all of the resources that users will need (such as an FTP client or text editor). Link to the tools that you recommend.
• Choose the most appropriate documentation type for the product. You might want a general set-up guide or a specific tutorial. For an e-commerce plugin, you could have the following sections: “How to set up this e-commerce pluginâ€� and “Selling your digital product with this e-commerce plugin.â€�
• Provide easy access to all of the resources and references your users might need. For example, when introducing a new concept, link to a relevant page either on your website or in the WordPress Codex.
• Anticipate questions users might have. If your users are diligent and read the documentation, then they will spend less time bugging you in the support forums.
• Think about how to integrate your documentation in WordPress’ administration screens. In WordPress 3.3, for example, the contextual help screens were improved, becoming a great place to assist users.
• Figure out your point, and stick to it. Don’t meander off topic, or else your message will get confused. The reader should come away with the key message.
• Do, however, offer examples and anecdotes that will help the user think about the main message from a different angle. This is a great way to emphasize a point.

2. Getting Down to Writing

Remember that the purpose of documentation is to help users use a product quickly and effectively. Step into the shoes of the layman end user and identify what they will need to do just that. Ask questions that an end user would have, and get confused and have doubts like an end user. Never assume that the end user should just know something; your job is to tell them.

Think of your documentation as a story. Like every good story, it needs a beginning, middle and end. Below is an overview of what to include in each part.

The introductory paragraph is crucial. It sets the tone for the documentation and should include the following:

• Introduces what you’re going to do;
• Tell the reader how you’re going to do it;
• List requirements (e.g. WordPress 3.3+);
• Summarizes what the reader will achieve by the end (if it’s a practical tutorial);
• Lists resources that the user will need to complete any practical sections.

The main body is the meat of the document. It’s where you get to the point and where your readers start to learn. Here are some tips for writing the main body:

• If you’re writing a user guide, break up the body into self-contained sections on different topics. Give each section a clear, relevant heading. A user guide on setting up a payment gateway could be broken down into “PayPal,â€� “PayPal Pro,â€� “Authorize.net,â€� etc.
• Tutorials should be laid out with clearly numbered steps, using headings. Each step should deal with one primary task and logically follow from the previous step. Include everything a user would need to complete the task. Ideally, an advanced user should be able to achieve what they need to do by scanning the headings, while novices can read through. A tutorial for installing a WordPress plugin via FTP might follow these steps:
  1. Download the plugin,
  2. Upload the plugin via FTP to wp-content/plugins/,
  3. Activate the plugin.

  That would be enough for an intermediate user, while the main body text would help the novice.

• Use call-out boxes to highlight useful pieces of information. I tend to use them for these:
  • Useful tips,
  • Definitions and references,
  • Important pieces of information that I don’t want people who scan to miss,
  • Advanced tips for more experienced users.
• Use screenshots liberally. These are really useful for visual learners and people who like to scan.
• Think about including a screencast to provide either a demonstration or walkthrough tutorial.
• Use a variety of methods in one section of documentation to reach a wide audience: visual, read/write, kinesthetic and aural. This will save you from having to produce a different version for each learning preference.
• Use a syntax highlighter to improve code readability. If you’re writing your documentation in WordPress, a popular plugin is Syntax Highlighter Reloaded.

The conclusion sums up what you’ve done and provides any additional information:

• If the guide is massive with a lot of in-depth material, then the conclusion is a good place to remind the user what you’ve covered and what they should now be aware of. This could be a list of main points or takeaways.
• A practical tutorial could simply finish with a screenshot of what the user should have achieved or with a link to an example.
• Provide a list of resources or further reading.
• Provide a list of tutorials to take things further.
• Link to your support forums or feedback form.

3. Test, Revise, Update

Now that you’ve written the documentation, it’s time to test, revise as necessary and keep it updated.

If I’m writing documentation for a particularly challenging product, I’ll get a representative end user to test it for me. This is usually someone who is familiar with WordPress but not a developer. If it’s a tutorial, I’ll ask them to work through all of the steps as laid out and to highlight anything that’s confusing or that they struggled with. If you are using code snippets, they must be accurate, so explicitly ask your tester to implement them. For a user guide, I’ll ask questions that the tester should know the answers to.

Armed with the suggestions of the tester, I’ll move on to the next phase, revising, and I’ll also have a nice list of questions to include in the obligatory FAQ.

Read through your document and revise. Here’s what to look out for:

• If you have tested the documentation, incorporate any resulting changes.
• Get rid of wordiness. For example, “Now it’s time for you to visit the WordPress administration screensâ€� could be revised to “Visit WordPress’ administration screens.â€�
• Fix all typos and grammatical errors.
• Add any links you may have missed.

The final step in the process is to update. This could be weeks, months or years after the documentation’s original production. In the world of WordPress, it is more likely to be months. Update the documentation to reflect changes in any of the following:

• WordPress’ UI (update screencasts and screenshots);
• New features or functionality in your product;
• New features or functionality in WordPress;
• User feedback.

A helpful plugin that I use to track documentation updates is Content Audit. It uses custom taxonomies to help you categorize your content. Being able to mark sections as needing updating straight from WordPress’ UI is helpful. You can also assign WordPress users to be responsible for various pieces of content, as well as write inline comments.

Let’s look at a case study of an end-user documentation project that I recently completed.

Case Study: ManageWP

I was approached by ManageWP at the end of 2011 to rework its documentation. At the time, the documentation was pretty thin and contained numerous grammatical and spelling errors. Here’s what Vladimir Prelovac had to say about it:

“Our initial documentation left a lot to be desired. We did not have it organized in a systematic way, and most topics were added ad hoc. It was hard to search, and it contained a lot of errors as it was sometimes not written by a native speaker.”

At a glance, the documentation looked to be in need of a total rewrite. Here’s the workflow I adopted:

1. I carried out a full review of the existing documentation and listed challenges and recommendations:
   • The documentation was listed alphabetically. This meant that a new user had no logical order to follow. Everything was jumbled together, making items difficult to find.
   • Many of the paragraphs covered multiple points, making them difficult to follow.
   • There were no screenshots.
   • The formatting did not vary, making the text difficult to read.
2. I recommended restructuring the documentation to make it more logical (for example, starting with “Getting Started� and then moving through different sections).
3. I put together a Google spreadsheet listing all of the existing guides, noting the new ones and splitting them up into sections. Vladimir, CMO James Mowery and I reviewed the order to make sure we were all happy.
4. All of the user guides were rewritten according to the principles outlined above.
5. We reviewed the docs to add sales and marketing content.
6. We made the layout and design of the user guide more intuitive for novice users.

You can see the result by checking out ManageWP’s user guides. In the future, we’ll improve the documentation by adding videos that complement the text.

The current incarnation of ManageWP’s user guides.

A Note On Developer Documentation

While end-user documentation is for the people using your plugin or theme, developer documentation is for the people who will be developing, forking or extending it. I get many fewer requests for WordPress developer documentation; I suspect this is primarily because most WordPress developers and designers are producing for end users. Occasionally I am approached to work on documentation for a project for both developers and end users, and I’ll look at such a case below.

My strongest recommendation is to keep the documentation for end users and developers separate. End users don’t need to see developer docs; that would only confuse and, in some cases, intimidate them. Of course, nothing prevents each group from using the other’s documentation, and the groups are not mutually exclusive, but clearly delineating between the two types is important, even if just with a prominent notice, as the WordPress Codex does.

A beautiful example of developer documentation is the recently launched QueryPosts, which is an easily searchable repository of WordPress code.

If you are generating extensive documentation for developers, check out some of these tools:

• phpDocumentor,
• Pears (a WordPress theme).

bbPress and Its Beautiful Inline Documentation

The bbPress plugin has one of the best examples of inline documentation. Below is an extract from the bbpress.php file, which loads the translation file for the current language.

	/**
	 * Load the translation file for current language. Checks the languages
	 * folder inside the bbPress plugin first, and then the default WordPress
	 * languages folder.
	 *
	 * Note that custom translation files inside the bbPress plugin folder
	 * will be removed on bbPress updates. If you're creating custom
	 * translation files, please use the global language folder.
	 *
	 * @since bbPress (r2596)
	 *
	 * @uses apply_filters() Calls 'bbpress_locale' with the
	 *                        {@link get_locale()} value
	 * @uses load_textdomain() To load the textdomain
	 * @return bool True on success, false on failure
	 */
	public function load_textdomain() {

		// Allow locale to be filtered
		$locale = apply_filters( 'bbpress_locale', get_locale() );

		// Get mo file name
		$mofile = sprintf( 'bbpress-%s.mo', $locale );

		// Setup paths to current locale file
		$mofile_local  = $this->lang_dir . '/' . $mofile;
		$mofile_global = WP_LANG_DIR . '/bbpress/' . $mofile;

		// Look in local /wp-content/plugins/bbpress/bbp-languages/ folder
		if ( file_exists( $mofile_local ) )
			return load_textdomain( 'bbpress', $mofile_local );

		// Look in global /wp-content/languages/ folder
		elseif ( file_exists( $mofile_global ) )
			return load_textdomain( 'bbpress', $mofile_global );

		// Nothing found
		return false;
	}

This kind of inline documentation would be helpful to you and to other developers using your code. At a glance, a developer can tell what the code does and see specific instructions (such as to place custom translation files in the global language folder). For an open-source product, this makes the code much more usable to a wider array of people. Read what developer John James Jacoby has to say about this on his blog.

The developers I have spoken with who take inline documentation seriously stress that you should write inline documentation as you are coding, for several reasons:

• If you are developing alone, you will write the documentation faster;
• A third party will find it much easier to write the documentation;
• You can return to the code in the future and instantly remember what you did;
• Other developers will be able to easily fork your code.

Case Study: Infinity Theming Engine

I was approached by PressCrew to help out with the website content and documentation for its Infinity theming engine. From the start, the developers, Bowe and Marshall, and I knew that it would be a challenge. Unlike everything else I’ve used in WordPress, Infinity uses configuration files to turn features and options on and off. It also supports crazy features such as infinite child themes, which took a mental leap to conceptualize how it could be used.

We spent a considerable amount of time identifying our audiences and figuring out what features to pitching to each. We asked ourselves some questions:

• What would the average WordPress user use Infinity for?
• Do we want average WordPress users to be able to make use of Infinity’s most powerful features?
• What information will developers need in order to make full use of Infinity?
• How can we make the documentation useful to developers?
• How do we give developers confidence in Infinity?

With our users identified, we also needed to provide them with two sets of documentation, each with its own strengths:

• Demonstrative
  Because we needed to introduce developers to a different way of thinking about WordPress — using .ini files instead of messing directly with PHP — we wanted to introduce the concept in a fun way. Bowe came up with minions; a cast of characters each of whom would introduce a configuration file. We used humor and pop culture to make Infinity fun to learn about. Check it out.
  
  Infinity’s minions.
• Practical
  Once the developer has learned what Infinity can do, they need to be able to easily do it. Marshall documented every function and then used phpDocumentor to create documentation from all of the source code. The documentation is written in Markdown and then parsed to both the theme and the library, so it has to be updated only once. As well as offering access from the library, Infinity includes documentation in the dashboard so that developers can access it while working on their theme.
  
  Infinity’s UI

A major difficulty has been the speed at which Infinity is updated. Bowe and Marshall asked me to come on board in the beta phase, which saw massive changes. Any docs I wrote would be out of date within a few weeks. I asked Bowe and Marshall what advice they would give to other developers in a similar situation:

“Our advice would be to write down a basic outline of the feature you want to create. When the feature has made it into your product, really take the time to properly document it based on your outline BEFORE you move on to the next feature.”

With a major project like Infinity, an iterative approach is best, documenting as you write the code. Then, after the features have been frozen, you would create the demonstrative documentation.

Conclusion: Sisyphus and I

In Greek mythology, Sisyphus is a king who was condemned to roll a boulder to the top of a hill. Every time he is about to reach the top, the boulder rolls back to the bottom. Up he goes to the top, only for it to fall back down again, and again, for eternity. That’s documentation writing.

With WordPress constantly changing, the documentation for WordPress constantly changes, and so the documentation for anything based on WordPress has to change, too. This could be anything from documentation for full-blown new features to screenshots to reflect UI changes. For me, the most painful moment is when WordPress releases a major UI change. I have to replace all of the screenshots — and screenshots are the most time-consuming part of documentation. Having a process in place, however, takes a lot of the pain out of it. But updating is important indeed because out-of-date documentation gives the impression of out-of-date code.

Don’t assume that your documentation is finished. It’s never complete!

Further Resources

• “Writing End-User Documentation in an Agile Development Environment,â€� Anne Gentle
• “The Six Pillars of Complete Developer Documentation,â€� Pamela Fox
• “If It Isn’t Documented It Doesn’t Exist,â€� Jeff Atwood

WordPress-Specific

• “Incorporating Contextual Help and Support into WordPress Themes,â€� Chip Bennett
• “New in WordPress 3.3: More Useful Help Screens,â€� Otto on WordPress
• “How to Improve Your WordPress Plugin’s Readme.txt,â€� Siobhan McKeown
• “Inline Documentation,â€� John James Jacoby

(al) (il)

© Siobhan McKeown for Smashing Magazine, 2012.

In a post on her blog last year, WordPress designer, business woman and author Lisa Sabin Wilson, talked about how thankful she is to be part of the WordPress economy. It’s an economy that thousands of people, the world over, are benefiting from (including me!). It is an economy built on free, open source software. In this article I’m going to talk to people who are active in the WordPress economy, people from all over the globe. It’s amazing to see how even in the past few years the economy around WordPress has grown, and what new, innovative, enterprises it’s composed of.

Contents

This is a long, two-part article so if you want to get where you’re going quickly, these are the sections:

• The Stats
• Some Words from the Founders
• Themes
• Plugins
• Services

The Stats

Last year WordPress carried out a global survey, asking basic questions about what people are doing with WordPress. Over 18,000 people responded from all over the world, making it a good indicator of how people are faring in the WordPress economy. Here’s the global map of the respondents:

You can check out the results in detail by watching Matt Mullenweg’s State of the Word address from 2011. Let’s take a quick look at some of them:

• 53% of respondents described themselves as WordPress developers.
• 36% described themselves as self-employed WordPress developers.
• 170,000 websites had been built by survey respondents.
• 61% of respondents use WordPress just as a CMS, 31% as a CMS and a blog, and only 8% as just a blog.
• Respondents reported being paid between $5 – $2000 per hour (sadly, the $2,000 per hour report is not from me).
• The average hourly rate is $58 and the median is $50.
• 2,800 people use WordPress as their primary source of income.

Those are some exciting stats. And with 14.7% of the internet running WordPress, and 22% of new domains running on WordPress (as of August 2011) we can expect exponential growth.

Before we get to the people using WordPress, let’s hear from the two guys responsible for its creation.

Some Words From The Founders

Way back in 2003 (feels like a century in internet terms), Matt Mullenweg expressed his frustration with b2/cafelog and wondered if it was time to fork it. Mike Little commented about this, and WordPress was born.

It’s an important moment for all of us who make our livelihoods from WordPress; people like me who get to wear pajamas all day while meeting awesome people from all over the world.

I asked Matt and Mike some questions about the WordPress economy. Here’s what they had to say:

When you first talked about forking B2, could you have imagined where it would end up?

Matt:

“Not in a million years.”

Mike:

“No, not at all. We were really just looking to fix some bugs and add some improvements to our blogging software.

I was also interested in getting involved in another open source project. I’d been on the fringes of a few different ones over the previous few years, MySQL, CVS, Cygwin, and others, but mostly bug reporting and forum / mailing list support.

So I thought this would be a good opportunity to really get stuck into a project. I had already been providing people with code and other solutions in the forum (as had Matt), and had already written a couple of extensions for B2/Cafelog and bug fixed / modified a few more.”

WordPress provides people with jobs all over the world, and is the foundation for hundreds of businesses. How does it feel to have been a catalyst in that?

Matt:

“We know of tens of thousands of people directly making their living from WordPress, and probably many more indirectly. I think when this community coalesces around a cause, like improving core WP development or charity work, it’ll be something to see.”

Mike:

“It’s not something I’d thought about too much until recently. I was more interested in the fact that WordPress empowers so many people to have a voice on the internet.

But when some of the results from the big WordPress survey started filtering through last year, I began to realize just how big the economy around WordPress had grown.

And I feel great about it. It is tremendously satisfying to know that I was involved in that at the start. It’s also a fantastic advert for the power of Free/Libre software: You can sustain an economy giving away the core product.”

The WordPress economy is booming and seems to be recession-proof. Why do you think that is?

Matt:

“WordPress is often replacing an existing proprietary or inflexible CMS, usually at a tenth of the cost. People want more direct control over their websites.”

Mike:

“Firstly, because WordPress is so very flexible: It means that the same product can be used as the basis for a wide range of jobs, from a simple ‘make me a website’ that might be as little as $25 or $50 and something a relative beginner can do, to complete customised, complex, fully functional, corporate websites that might run up to a $150K+ build for a big agency.

Secondly, because it’s simple enough that many people can get started in a career built around WordPress, yet powerful enough that the most sophisticated websites; those that require highly skilled and experienced teams, can be built with it.

Thirdly, it fits in extremely well with the whole internet-based economy thing. Everyone from designers to marketeers, SEO experts to entrepreneurs (and many others), can do what they do best without having to worry about the building-the-website part, or having to learn many skills that are unrelated to their main skills.”

That’s what the the guys behind WordPress had to say. Now it’s time to hear from people who have built businesses around WordPress—people long-established, as well as those who are just starting out.

Reading through them, you’ll see a pattern emerging. Many came from a personal need, and transformed that need it into a business. It’s this prescience that makes so many of them successful.

Themes

Theme Shops

Allure Themes offers WordPress themes for women.

The first type of business that springs to mind when thinking about WordPress is the theme shop. Think theme shop and names like WooThemes, Elegant Themes, Thesis and StudioPress all immediately spring to mind. But there are 100′s of WordPress theme shops. This post lists only 90 of them, but I can think of countless more that aren’t included on this list.

Theme shops are based all over the world. From my own personal experience I’ve worked with theme shops in America, the Far East, the Middle East and Europe, and that’s just me and my little business. The theme shop market is saturated, but that doesn’t stop new theme shops from popping up all the time.

I talked to Lisa Sabin Wilson, who launched her own theme shop Allure Themes last year. I asked Lisa whether theme shops, in such a competitive market, continue to be a viable model for WordPress startups. Here’s what she had to say:

“The fact is, it’s not as easy to put a theme shop up on the Web and start selling themes as it was 2-3 years ago. The internet is flooded with WordPress theme shops these days and you’ve got your big names as well as a smattering of younger, smaller groups trying to make it happen. I think a niche shop that targets a particular industry or demographic will help you standout in the crowd, or try tapping into existing marketplaces by offering child themes for the popular theme frameworks like Builder, Headway or Genesis. Those markets have hundreds and hundreds of users, and people like the variety and choice.”

It has become much more difficult to launch a theme shop, but that doesn’t make it impossible. If you’re thinking of launching a theme shop, Lisa has this advice:

• Recognize that it’s going to be a slow process. It may take several months to a year before you start seeing a decent return for your work.
• Have a strong marketing and PR plan in place to make sure you get noticed.
• Approach WordPress news sites such as WPCandy and WPMU.org for coverage of your new venture.
• Have drive and passion; eventually if your work is good, you’ll get noticed.

Theme Marketplace

Shopping for themes in the marketplace (image CC license Michael Osmanda)

A Theme Marketplace is a variation on a theme shop. While a theme shop sells themes that it has developed in-house, a marketplace provides a platform for designers and developers to sell their themes, while the marketplace takes a cut. The most well-known of these is Envato’s Theme Forest. However, it’s by no means the only theme marketplace around, with Theme Garden currently undergoing a redesign and Mojo Themes going strong.

I spoke to JR Farr who first came up with the idea of a theme marketplace back in 2006 (but at that time he was unable to get it off the ground). Later he teamed up with his co-founder to create MOJO Themes. I asked him how he felt about competing with such a huge company such as Theme Forest:

“The network that the Envato crew has built is amazing and we have so much respect for them. They do a great job over there. It’s been exciting to compete and personally I think the competition is good. It brings innovation and also keeps things in check.

Since day one we’ve had the same goals in mind and we’ve tried to stick to being consistent with those goals. We try to just focus on what we’re doing and being the best at that. The last two years we had a few growing pains and we also unveiled some features in our marketplace no one else has, like JOINT FORCES.”

They have grown every month since launching: new users, new items, higher sales and higher payouts. This has meant that their team has had to grow, with the marketplace expanding to make sure everything gets done. Now in their third year, the growth rate is getting even higher. In 2011 alone they tripled in size. They’re hoping to expand their Mojoness network and look into customized solutions for new niches.

Theme Design

Theme design is one of the most in-demand WordPress skills. As long as people want gorgeous WordPress websites there’ll be a market for theme designers. Chris Coyier is a designer who has found himself reaching again and again to WordPress to power his clients’ websites.

I asked Chris about the difference between traditional Web design and designing for WordPress. As he pointed out, it’s rare these days for a website to run without a CMS, so we’ll soon be in a situation where traditional means a regular CMS design. Here’s what Chris said to keep in mind when designing for a CMS:

• As you’re designing around dynamic data, be sensitive to things like the fact that the size of an area can change depending on the amount of text.
• Remember that content creators may want to be able to customize different elements of their website.
• Be aware of how media integrates.
• The addition of a database means you need to consider page load speeds.

I asked Chris what a theme designer has to do to get ahead in a busy market:

“I know there are loads of small businesses trying to sell WordPress themes. So that market is pretty saturated and probably pretty difficult to get into. As with any other industry, getting ahead means competing on either quality or price. Since it’s hard to compete with free (what the majority of WordPress themes are), you gotta go for quality, and the bar is set pretty high there. If you are a freelancer, I think there is always room for good designers who are also good business people and know how to treat clients well, and deliver to them what they need.”

However, this busy market doesn’t mean that there is no room for new designers. More and more people are using WordPress, ranging from big corporate clients to small businesses and individuals. With the market constantly growing, there’s more scope than ever for a wide range of designers.

Theming Engine

The Infinity Theming Engine wants to give more power to WordPress (image CC license Trey Ratcliff).

As WordPress expands, the number of designers who want to design for it is growing. But not all of them have the skills necessary to make really complex websites. This means that developers are looking for solutions targeted specifically at making life easier for designers. The Infinity Theming Engine is about to launch. It seeks to differentiate itself from traditional WordPress frameworks by being a toolkit for designers. The developers describe it as “a powerful layer of re-usable and highly extensible theme development features that sits between WordPress and your theme(s), without locking you in to a specific design model.” It’s an engine because it adds additional power to WordPress and makes it easier for designers to design.

Rather than having a whole load of functionality stuffed into functions.php, Infinity uses a configuration file to let designers turn on and off whatever functionality that they need.

Infinity is being developed by developer Marshall Sorenson and designer Bowe Frankema. They’ve decided to adopt a Freemium model for when they launch it. Here’s what Marshall had to say:

“We’re the type of guys who are so obsessed with writing code and adding features, it took us a long time before we even got thinking about a business model. Our most important focus has always been making something that we could use for ourselves, and sharing it with the community. Luckily for us, there are a lot more WordPress devs who are in the same boat as us, and the rise of the ‘Freemium Model’ over the last two years, was a real outcome.”

The main product will be given away for free and the pair plan to monetize it by selling themes, extensions, installation and support services. This model has been tried with other traditional frameworks, so it’ll be interesting to see how it works with a different type of theme development tool.

I asked Bowe what he thought the benefit was of working with WordPress:

“Where to start? Seriously, these are very exciting times to be part of the WordPress community. There’s a flood of new people discovering WordPress every day, and they are welcomed by great resources across the Web to help get them started. There are WordCamps all over the planet, and it’s never been easier to start using WordPress.

We’re blown away by the amount of interest we’ve seen for Infinity. We never expected the amount of attention we got from all kinds of people. It comes with some challenges in terms of documentation and managing expectations, but that’s a luxury problem, really. People want to use WordPress, are not afraid to try out new solutions to help solve their problems, and most importantly: they trust WordPress to power their websites/businesses. Without that trust, we (all the WP devs trying to make a living of doing the stuff they love) would be doomed from the start. Thank you WordPress Community :-) “

Plugins

Plugin Developer

The commercialization of plugin development has often proved to be a more contentious issue than the commercial theme market. A divide emerged between design and functionality, with WordPress users happy to pay for theme design but not for plugins. But that doesn’t mean that plugin development isn’t a lucrative and growing market, and some plugin developers have focussed their development efforts on a single plugin, and with great success. Seth Shoultes is the developer behind Event Espresso, an event management plugin for WordPress.

Event Espresso started out as a plugin that Seth developed for a family member. She needed a way for people to register for her online scrap-booking classes, and to let them make payments through her WordPress website. There wasn’t a plugin available, so Seth built Event Espresso.

Like many commercial plugins Event Espresso began its life as a free plugin in the WordPress repository. The support requests started to flood in. Like many plugin developers, he found it difficult to provide support, upgrades and development for a free product. It seemed like a good idea to start selling it on a plugin marketplace.

“We started off with one sale per week, then two and then a few per day, and it steadily doubled each month for about the first year. After about 12 months of growth our trend started to become more conservative, but consistent, so we’ve become more aggressive about marketing and releasing new products.”

In 2011, Seth entered the Utah Entrepreneur Challenge and after three rounds of judging was awarded the Grand Prize of $40,000. You can check out the ABC news item right here:

I asked Seth what the advantages are to being part of the WordPress economy. As well as mentioning the huge adoption rate of WordPress, he also said:

“The WordPress economy is innovative. Certainly developers have to function on the platform they’re given, but WordPress is open so they can change it and contribute to it. Yet within that framework you can find new and inspiring work daily. Some of that creativity can be monetized by the developer and sometimes it can’t, but in either case the WordPress community is pushing the envelope.”

Seth has big plans for Event Espresso, and in the coming years, hopes to see the plugin (which started out as a favor for a family member) become a foundation for expansion into larger and newer markets.

Services

WordPress Hosting

Servers the world over host WordPress (image CC license Skimaniac).

If you’ve used WordPress (and if you’re reading this, it’s probably safe to assume that you have), you know what an issue finding a good hosting provider can be. Late last year, Alex at WPShout published the results of his hosting review and the outcome was not great for the big hosting providers (Note: if you want to have your say about a hosting company, Joost de Valk is running a similar hosting survey on his blog right now). But what about finding a company that just provides WordPress hosting? That’s what the guys at WPEngine provide.

Like many of the other WordPress businesses I’ve talked about so far, WPEngine grew out of a need that the founder had himself. Jason Cohen had found that his blog would crash every time he hit the front page of HackerNews. He decided what he needed was an all-inclusive WordPress hosting package that would manage WordPress for him, and be able to handle high-traffic spikes.

After carrying out some market research, Jason decided to found WPEngine (his fourth startup!)

“‘Scratching your own itch’ is an awesome and typical way a company is started, but that’s the grain of sand, not the pearl. You have to go out in the field before you know whether it’s just a grain of sand. Remember, lots of ideas are good ideas but not businesses.”

Jason bootstrapped the company, making a profit after seven months. He then hired two more members of staff and turned a profit again in six months. Now their growth is exponential, increasing by double-digits every month.

If you keep your ear to the WordPress news wire, you’ll know that last year WPEngine received significant angel investment (you can check out their impressive list of investors here), including a major investment from Automattic.

“This is what fuelled our ability to grow, both on the customer-acquisition side and on the company-building side. Money in the bank means that we can hire ahead of need and test more marketing efforts in a shorter time, and put more money into whatever efforts are paying off.

Perhaps equally useful is the guidance. I get different benefits from different investors—some help with the operational issues of scaling and projections, some are deep on certain kinds of metrics, some have started hosting companies and run them to massive scale and therefore can help on almost everything. In aggregate it has a massive impact on our success—there’s no doubt in my mind that without their help we wouldn’t be doing as well.”

With WordPress powering a significant proportion of the internet, there is scope for other hosting companies that just focus on WordPress. The market is huge, and the potential to create a successful company is massive.

“In a market that huge, of course there’s room for a ton of players, each contributing different benefits, different trade-offs. Sure we hope to be a major player, but we certainly have no interest in ‘killing’ competition. In fact we regularly refer customers to our competitors when we’re not a fit, and they’ll do the same.”

Jason sees the job of WPEngine to be as good as they can be for the corner of marketing that they are targeting. This means getting the balance right for both low-end and high-end customers. That said, they seem to be extremely successful at it, having just released support for servers in both London and Tokyo.

Consultancy

Everyone needs a little help from time to time (image CC license FuturePresent).

WordPress is easy to use, and it’s free, which means that the entry-level threshold of technical knowledge for people starting to use WordPress is always getting lower. This is great as it gives millions of people access to the Web, but once a users start digging under the surface of WordPress they soon discover that things aren’t so simple. On top of that, the plethora of plugins and themes available means it’s hard for an untrained eye to know where to start. This makes consulting an excellent opportunity for the WordPress-savvy.

I spoke to Mason James who provides WordPress consultancy services. I asked him what being a WordPress consultant involves:

“For me, consulting is troubleshooting in advance. A good consultant obviously has to have a thorough understanding of existing plugins and themes as well as what’s in the pipeline for WordPress itself, but also a keen sense of business strategy. This knowledge and experience helps a consultant to see down the development path and provide a clear guide in terms of using solid foundational products and avoiding the common pitfalls faced by WordPress-based businesses.”

This balance of having technical knowledge and business sense is essential for a good consultant. Mason operates by focusing his clients on their goals, and trying to build a business strategy around that. He helps them to set benchmarks, and creates a map around that benchmark of achievable goals. Anything that’s not relevant to their goals gets set aside. With a lot of startups he’s found that an unclear direction leads to feature creep and a delayed release. These are the pitfalls that a consultant is there to help prevent.

I asked him what the best and worst things about working within the WordPress economy are:

The best:

“The best thing about working in the WordPress Economy would have to be the tremendous amount of resources, support, and knowledgeable folks out there to pull from. I’m still discovering great sources of information and it’s growing all the time.”

The worst:

“I would say the worst aspect of the economy would be that the open source aspect can sometimes confuse folks on the value of it. They can get a website up and running quickly at only the cost of the hosting. Because of this some tend to be tighter with their wallets when it comes to getting expert advice or development. It’s not a huge issue, but for example, there is a difference in salary between a WordPress developer and a Drupal developer.“

Development Shop

You can build anything if you put your mind to it (image CC license xray delta one).

As well as there are businesses that just sell WordPress products, there are development shops the world over that are using WordPress to build large-scale (and small-scale) websites. Dave Coveney is the founder of Interconnect/IT, a UK-based WordPress development shop. The business started life as a technology and software consultancy firm, but they soon discovered that demand was starting to climb for WordPress. When Interconnect/IT marketed itself as simply a Web design and development studio it faced a lot of competition. But once it focused on WordPress it started to get the interest of larger potential clients.

I asked Dave if he has ever had any problems convincing his clients that WordPress isn’t a blogging platform. Here’s what he said:

“We took a lot of care to get known for what we could do with WordPress, released quite a few themes, and developed clever things to prove what we could do. When the likes of Telecoms.com or The Telegraph approached they needed strong and clear advice not on what WordPress was, but on where its limitations lay. That gave it credibility. And it’s a fantastic tool for websites with a content stream, and for simple brochure websites.”

That’s not to say that Dave hasn’t thought about jumping ship from time to time. He’s tried out other CMS options, such as Drupal, and spent a month learning Ruby-on-Rails. But he’s always come back to WordPress for its ease with user training, performance and deployment.

“I always come back to WordPress feeling slightly guilty for cheating on it. However, I’m not married to WP, so it’s always worth always keeping options open.”

We are living in a time of global recession, but WordPress has thrived throughout this period. With low barriers to entry, and ease of use for non-technical people, it’s the smart choice for small businesses as well as big businesses. Dave pointed out that many of the large firms and organizations that they work with use Escenic, which is hugely expensive for just one license. For the cost of an Escenic license, a good WordPress developer “can deliver the moon on a stick.” This lets development shops like Interconnect/IT develop sophisticated websites for a fraction of the budget. As Dave pointed out:

“anything that saves people money will do well during a recession, and recessions tend to create innovation. The WordPress economy is a good example of this.”

Translation

Thinking about every language (image CC license Tico).

Living in a global market, a business can expand considerably by creating multi-lingual websites. ICanLocalizeprovides self-service translations for WordPress and other CMS. The company also makes WPML, a WordPress plugin that enables WordPress users to create multilingual versions of their websites

The man behind ICanLocalize is Amir Helzer. Like many developers, ICanLocalize grew from a need that he had himself: a small shareware business selling Web utilities. He had his website and programs translated, and that increased his revenue threefold. The process, however, was painful. He decided to create something that people would actually enjoy using. The company started as one person and has now expanded to five, and continues to grow. Now iCanLocalize is a recommended resource for iOS developers and serves major clients such as eBay.

ICanLocalize provides self-service translation but WordPress users have the added advantage of being able to use the WPML plugin to send WordPress content directly to translators.

“It’s all happening in self-service mode. We are a platform that connects certified professional translators with clients. Our philosophy is that the system should take care of all technical issues allowing translators to just translate, and clients to just push and receive what they need.”

I asked Amir about his work with WordPress, which provides about 30% of ICanLocalize’s business:

“WordPress users are exactly our target audience. They are typically smaller businesses and highly cost sensitive. However, everyone who takes translation work also requires quality, so this lets ICanLocalizes’ benefits shine.

I feel that our involvement in WordPress has been a two-way street. We got a huge push from this mass exposure and we also helped WordPress mature into a completely multilingual CMS.”

Smashing Special: A Two-Part Series

Due to the length of the series, it was split into two parts:

• Part 1: What’s Going On In The WordPress Economy?
• Part 2: What’s Going On In The WordPress Economy?

(jvb)

© Siobhan McKeown for Smashing Magazine, 2012.

This special is the first in our series of Smashing Specials — extended articles and studies dedicated to a specific topic. The special features current WordPress theme trends for 2012, covering past trends, new developments in theme design and trends in the theme development.

2011 was a great year for WordPress, with some excellent new updates that saw the introduction of a drag-and-drop uploader, distraction-free writing, the HTML5 Twenty Eleven theme, and movement towards a fully responsive dashboard. As well as changes to WordPress core, theme development continued to evolve, as whispers of responsive design spread like wildfire across the WordPress community.

(image credit: Bowe Frankema)

Over the next year, some recent developments will become standards. Others, now just remote flickerings in the eyes of a few theme designers and developers, will start to take hold. Now that 2012 has properly started, let’s look at some trends that have emerged and are emerging.

Due to the length of this special, it was split into three parts:

• Part 1: Past Predictions
• Part 2: WordPress Design Trends for 2012
• Part 3: WordPress Development Trends for 2012

Past Predictions

When thinking about future trends, it’s fun to look back and see what people predicted before to see whether any of their predictions came to fruition. Thankfully, with the power of Internet, combined with Ian Stewart’s “Future of WordPress Themes� posts (as well as WPCandy), doing this is very easy.

So, just what were people predicting when WordPress was growing up?

The Demise of the WordPress Premium Theme Market

At the start of 2008, when creating a premium WordPress theme was frowned upon, Ian Stewart wrote this in a post:

It’s prediction time: The premium WordPress theme phenomenon has approximately one year left before collapsing entirely, leaving a rather large hole between completely free WordPress themes and custom themes $1500 and up. If you’ve got a “premium� WordPress theme waiting in the wings, I advise releasing it sooner rather than later. As in, now.

We don’t really need to add a comment to that one.

“Cluttered and Pimped Out�

Here’s what Robert Ellis said about the future of WordPress themes in 2008:

The vast majority of themes will still be garish mutations of Kubrick, but more cluttered, more pimped out with widgets, scripts and effects. There will still be premium themes that push the envelope in terms of built-in options and quality, but the market will become saturated, setting off even more accusations of copying (as we’ve seen with magazine themes; though personally, I think most of them look like they were “inspired� by CNN).

This was more on the money, and we have seen amateur designers cram in a lot of different scripts and effects. This has diminished over time. Hopefully, our direction now is more Zen.

Early Niche Predictions

Justin Tadlock had this to say in 2008:

I do hear some talk of moving into designs for specific niches, so theme developers could cater to particular users. I think this is a great idea, which could be a nice trend as we’ve seen with magazine-styled themes. Users want something that works for them before unwrapping the packaging.

Justin was definitely prescient then, as niche themes became more popular in 2011. And we’ll see much more of them in 2012.

Everyone Loved Theme Options

In 2009, themes that allowed you to customize the layout and design started to appear. Here’s what Dougal Campbell had to say:

The main change I see happening here is with themes which provide some sort of customizing feature on the back end which lets you choose options like: header graphics; one, two or three sidebars, along with their positions; color schemes; They will also be pre-bundled with several plugins which allow you to pull in your content from other sources such as Twitter, Facebook, Flickr, etc. These kinds of themes already exist, but I think we’ll see the ease of customization rise to a new level.

By 2012, this trend towards adding options and customizations reached its zenith, and it will hopefully decline over the coming year.

Want to have fun reading past WordPress theme predictions. Check them out here:

• “The Future of WordPress Themes in 2008,â€� Theme Shaper
• “The Future of WordPress Themes in 2009,â€� Theme Shaper
• “The Future of WordPress Themes in 2011,â€� WPCandy

A Trip Down Memory Lane

Let’s look at how theme design has changed over the past few years.

Free Themes: The WordPress Repository

Below are the most popular themes downloaded from the WordPress theme directory since 2009 (thanks to Otto for getting this information). You can see how WordPress themes have moved away from looking like blogs to a more professional appearance.

2009

iNove was the most popular theme in 2009, followed by Atahualpa and then Pixeled.

2010

Mystique was the most popular theme in 2010, followed by Atahualpa and then TwentyTen.

2011

Delicate was the most popular theme in 2011, followed by TwentyEleven and then Platform.

The Most Popular Themes in the Forest

To see how things have fared on the commercial theme front, we scoured the archive of ThemeForest. Below are the best-selling themes from the last quarter of each year.

Here were the top themes:

2008

Sharp was the top theme for the end of 2008.

2009

Twicet topped downloads for the last quarter of 2009.

2010

Striking was the most popular theme in the last quarter of 2010.

2011

The multi-optioned uDesign was the most downloaded theme in the last quarter of 2011.

What Happened In 2011?

Before getting to our predictions for what will take hold in WordPress themes this year, let’s quickly look at what has happened over the past year:

• Theme frameworks
  Theme frameworks were everywhere in 2011. As someone who blogs regularly about WordPress, I found myself announcing the launch of three different frameworks in one week. WordPress staples such as Thematic, Thesis and Genesis continued to grow in popularity, but more and more frameworks appeared on the scene, including the likes of Wonderflux, Bones and Roots. Perhaps in 2011 we’ll see fewer new frameworks and more themes for existing ones.
• Child themes
  Child themes took off in a big way in 2011. Once people grasped the concept that creating a child theme and making edits to it was better than hacking away at the parent, they started to have fun. Will we see child themes in the WordPress repository in 2012?
• The “CMSâ€� theme
  At the start of 2011, everyone seemed to be calling their theme a “CMS� theme, implying that their awesome theme gave WordPress the characteristics of a CMS, as opposed to WordPress itself being a CMS. Thankfully, that trend petered out towards the end of the year, perhaps as it became less imperative to convince people that WordPress was a CMS.
• Sliders everywhere
  Every theme seemed to have a slider on the home page. This might have been due to the gorgeousness of Nivo and other sliders that make it easy for anyone to include a jQuery slider in their theme. Hopefully, designers will be more inventive with their jQuery this year.
• Tumblr themes
  All of a sudden, creating a Tumblog became easy. Designers first achieved this with the Woo Tumblog plugin, but the introduction of WordPress post formats made it possible to create a Tumblog with WordPress core functionality.
• Custom post type mania
  As predicted by Brad Williams in WPCandy’s predictions for 2011, we saw loads of themes that made use of custom post types, including ones for job rollers, e-commerce websites, real estate websites, review websites and so on and so on. Not to mention a plethora of WordPress custom post type plugins.

Now we’ve got the past out of the way, let’s look at the future!

Smashing Special: A Three-Part Series

Due to the length of the series, it was split into three parts:

• Part 1: Past Predictions
• Part 2: WordPress Design Trends for 2012
• Part 3: WordPress Development Trends for 2012

(al)

© Siobhan McKeown for Smashing Magazine, 2012.

A few weeks ago I wrote about how you can put together a great readme.txt for the WordPress plugin directory. In addition to using a WordPress readme as a tool to help out your users, you can use it to promote your commercial products and services. While commercial theme developers are already promoted on WordPress.org, this promotion isn’t extended to commercial plugin developers. But restrictions often lead to creativity, and developers have had to get a bit creative in figuring out how to monetize the WordPress repository. API keys, complementary plugins and lite version are just a few of the ways that plugin developers are exploiting the WordPress plugin directory for commercial benefit.

(Image: Bowe Frankema)

What’s Allowed?

Back in 2009, Mark Jacquith posted this on the WordPress development blog:

Plugins that merely exist as placeholders for a plugin hosted elsewhere (like a “requirements check� plugin) are out, but “lite� versions, etc are in. The goal is to have the directory be free-to-download plugins. A placeholder for a premium plugin is against that spirit.

He goes on to say:

If your plugin is actually a plugin, not just an advertisement or a placeholder for a plugin hosted elsewhere, you’re fine, as far as this rule is concerned.

Related to this, Matt Mullenweg posted on the WordPress.org support forums:

There are plenty of plugins that tie into third-party services, for example Google AdSense, and some of them have no free versions. That’s totally fine as long as the plugin is totally GPL.

I emailed Matt to see if anything has changed since he posted this, and he directed me to WordPress.org’s “Detailed Plugin Guidelines.�

Briefly, if you’re a commercial plugin developer, here’s what you need to keep in mind if you’re planning to use the repository:

• The plugin must be GPLv2. (Explicitly state this in your license. If you don’t, it will be assumed that your plugin is GPLv2.)
• Trialware is not allowed.
• Upselling is allowed (but not by being annoying or disabling features after a time period).
• Serviceware is allowed, even for paid services (i.e. a plugin that serves to interface with a third-party service). The service must be doing something substantive, not just providing keys or licenses.
• No phoning home without the user’s consent. This includes:
  • No unauthorized collection of user data;
  • No remote images or scripts (everything must be part of the plugin);
  • Banners and advertising text should not be included in the plugin;
  • Advertising spam is not allowed.
• No sending executable code via a third-party system (unless of a service-client model).
• External links may not be included on the user’s public website.
• No hijacking the admin page.
• No sponsored links in the readme.
• WordPress.org reserves the right to edit the guidelines and to arbitrarily disable or remove a plugin for any reason whatsoever.

Adhering to these guidelines is a delicate balance, and not everyone who tries to monetize the repository is successful at it, as the people behind Plugin Sponsors recently found out.

That said, let’s look at some models whereby developers have managed to create synergy between free plugins and paid plugins or services.

The API Key

No one likes spam. (Image: Thomas Hawk)

Who’s doing it?

• Akismet
• Scribe SEO
• YoLink
• WPMU DEV Anti-Splog

If you’ve installed WordPress, then you’ve met Akismet. Akismet is the anti-spam plugin that comes bundled with WordPress. It’s free for non-commercial use, but if you are using it for a commercial website, then you have to pay for it. The whole Akismet issue pops up every so often in the WordPress blogosphere. Many people feel that a commercial plugin shouldn’t be bundled in WordPress, although I don’t plan to get into that debate here.

Whatever you think of it, providing an API key for a service is a viable way to create a WordPress plugin, host it in the WordPress repository, and yet charge for the service that it provides. Another plugin provider that adopts this model is YoLink, a search service that offers advanced search functionality for websites. Personal websites (i.e. without advertising) that have fewer than 5,000 monthly visitors per year can use it for free; after that, the pricing varies.

“We’ve found that once a user has ample time to test-drive the plugin on their site, they come to realize its value and upgrade to a paid subscription,� says Joe Pagliocco of YoLink. “We are seeing this most often with commercial sites looking for additional flexibility and indexed pages.�

However, you don’t even have to offer a free version of your service to get a plugin with an API key into the repository. Scribe, a popular service from Copyblogger, is a plugin that integrates with your WordPress website. In order to use Scribe, you have to sign up for an API key, which is a minimum of $17 per month. While the plugin is GPLv2 and free, the service is not. This approach might make some people hate you, but it is still a viable way to make money from a plugin in the directory.

Pro: You’re able to offer a plugin that provides a service and make money from it.

Con: People might hate you for it.

Upgrades And Support Forum

Jigoshop offers a commercial-level e-commerce plugin — for free!

Who’s doing it?

• Jigoshop
• WP eCommerce

Jigoshop is a free e-commerce plugin, available in the WordPress repository. It includes everything that you need to run an e-commerce website. If you like the plugin (and many people do), then you can pay for premium upgrades and support. Premium upgrades include MailChimp integration, BuddyPress integration and various advanced payment gateways.

I spoke with Dan Thornton at Jigoshop, and he said that they had considered going down the lite/premium route, but because the free version was embraced so quickly, they didn’t want to duplicate their work. By including all of the standard payment gateways in the free version, they made it possible for a small business to get a store up and running and then invest its money in extending the store’s features and functionality, rather than have to pay for all of the bits and pieces up front.

When Jigoshop launched earlier this year, it got a lot of promotion throughout the WordPress community purely because it is a totally free, fully-functioning e-commerce solution. “If we’d gone for a different business model,� says Dan, “we couldn’t have afforded the marketing and advertising to match the recommendations and promotion that we’re grateful to have had from users, designers and developers.�

Pro: Massive community of developers has gathered around Jigoshop, adding their own expertise to the product.

Con: A fully-functional GPL plugin is open to being forked by bigger players on the scene.

The Lite Plugin

Do you like your plugins with less calories? (Image: Niall Kennedy)

Who’s doing it?

• WPMU DEV
• Event Espresso
• Cart66

This is probably one of the most common ways to use the repository to up-sell, and it can be a great option for a variety of plugins. Basically, you restrict the features in the free version and offer a paid version for people who want more features. Putting a lite version of a plugin in the repository is fine, provided it is GPL and adheres to the “Detailed Plugin Guidelines.�

WPMU DEV, a shop for WordPress plugins, has a number of lite versions of its commercial plugins in the repository. It offers lite versions of its Google Maps, eCommerce, Chat, Wiki and Membership plugins, among others. In theory, these plugins should be adequate for the average WordPress user who wants the given functionality on their website, while the commercial versions are available for those who need even more functionality.

I asked James Farmer, of WPMU DEV, what he holds back for his members. “We started holding back quite a bit,� he says. “Now we hold back very little. It’s really just the extended stuff and extra support, etc, that premium users get.�

With little functionality being held back for members, I asked James why they bother including free plugins in the repository. “I suppose you could say to ‘give back,’� he says. “But really, it’s just about business: if folks get to try our plugins for free (and the WordPress.org repository is the best place to get them to do that), then a proportion of them will be keen on our full offerings… At least that’s the plan.�

Pro: Give back to the community while maintaining your business model.

Con: Have to split your support base across WordPress.org and your own website.

Complementary Plugins

Some things just work better in pairs. (Image: Martin Hartland)

Who’s doing it?

• WP Types & Views

Two new plugins on the WordPress scene are taking a different approach. Developed by OnTheGoSystems (the folks behind the popular WPML), Types is a plugin for creating custom post types, while Views is a plugin for displaying content. Drupal users will recognize similarities between Views and a certain Drupal module.

Types is free and can be found in the WordPress repository. Views, on the other hand, is a commercial plugin available through the developer’s website. Types is a fully-functional plugin, and if all you’re interested in is creating custom post types and taxonomies and custom fields, then you might stop there. But Views is used to display the content in complex ways by querying the WordPress database for you. And, of course, the Types readme.txt tells you all about what you can do with Views, to tempt you into grabbing the complementary commercial plugin.

OnTheGoSystems developed Types and Views hand in hand, and it markets them that way, too. Views needs Types to create content, and Types is made better when Views displays it. A synergy between the two fuels the business model. “Types complements Views,� says Amir Helzer, CEO of OnTheGoSystems, “by making it easy to create and manage custom data. Marketing 101 says that when you want to promote your product, you work to turn its complements into commodities. This is what Types does. It makes creating of custom data into a non-issue, so that people can concentrate on its display (via Views).�

Pro: Exploit a ready-made market for your commercial plugin.

Con: The market might decide that it only wants your free plugin.

Offer Commercial Themes

There’s big business in WordPress e-commerce. (Image: Thristian)

Who’s doing it?

• WooThemes

The plugin directory isn’t being used just by commercial plugin developers. If you run a successful commercial theme shop, then it’s perfectly within your power to give away a functional WordPress plugin for free, dedicate a team of developers to it, and then let the money roll in as people look for commercial themes to power your plugin. That’s what WooThemes has done with WooCommerce.

You can get WooCommerce from the WordPress repository for free; and with more than 30,000 downloads since launch, it’s proving to be a pretty popular e-commerce solution. What it’s really got going for it, though, is the large collection of dedicated e-commerce themes that work with the plugin.

While already successful as a commercial theme shop, WooThemes was keen to test its legs in the freemium waters. E-commerce seems like a perfect fit for it: free core functionality, while charging for design. I asked Adii Pienaar, WooThemes’ founder, what effect WooCommerce has had on its business. He says, “WooCommerce has been quite a diversification for us on two fronts. First, it diversifies our revenue models and allows us to include the freemium model, which means a higher volume of users. Secondly, it has added a whole new class of products to our offering. To that extent, we’ve already seen a bump in our overall revenue, and our WooCommerce-related revenues are already establishing themselves as a firm chunk of that pie.�

To follow this model, Adii suggests that you develop a great core product and then monetize add-ons to that core. Because the core is free, you get high-volume adoption, and you need only monetize a certain percentage of it to be profitable.

Pro: Great way to expand your current market.

Con: Works best if you’re already backed by a strong brand.

Installation And Set-Up Services

Everyone needs a bit of help sometimes. (Image: Carol Browne)

Who’s doing it?

• s2Member

s2Member is powerful membership plugin. In fact, it’s so powerful that a dedicated installation service runs alongside it. Simplicity in a plugin is always a bonus, but out of necessity some plugins end up being seriously complex. That isn’t a bad thing, but it can get confusing for less advanced WordPress users. From my own experience, membership plugins can be extensive and pretty difficult for users to set up.

A great way to monetize a plugin like this is to offer an installation service alongside it. To set up s2Member, you can employ s2Installs. This is the team of developers behind s2Members, and they can install and set it up for you, as well as provide custom coding to extend the plugin to fit your needs. What better way to set up and extend a plugin than by employing its own developers to do it?

This is a really good model in which everyone can access the plugin for free, while commercial help is available for people who aren’t able to use the plugin to its full extent.

Pro: You are the best person to provide set-up, installation and customization of your plugin, so capitalize on it!

Con: Only works with big plugins. Might not work so well with your Google +1 button.

Is It Really Worth It?

Now that we’ve looked at some of the models, you might be wondering if this is actually worth it. Many commercial plugin developers, including those of popular plugins such as Gravity Forms, don’t adopt the freemium model and yet are still incredibly successful. In fact, a number of the plugin developers I spoke with said that the amount of traffic they get from the repository is minimal, not to mention other developers who don’t want a whole lot to do with WordPress.org. Some feel that the tightrope that has been set up for commercial plugin developers who want to use the repository is too precarious and not something they want to put effort into. Commercial themes are supported on WordPress.org, but there is nothing similar for plugin developers. Most of the developers I spoke with felt that a commercial plugin page will probably never appear on WordPress.org.

That said, if you are going down the freemium route, then using the WordPress repository is definitely a viable option, provided that you do actually use GPLv2 and provide some kind of useful service. The WordPress plugin directory will always be the best way to get your product into WordPress’ back end.

Like everything, the WordPress plugin directory has its upsides and downsides, and it’s not a one-size-fits-all solution. But in addition to directly promoting your product and services, having a plugin in the repository has a load of indirect benefits:

• Self-promotion and branding
  You might not be making a living off of your plugin, but you will be making a living off of yourself. A great example of this is Yoast, which is available for free in the plugin directory; while its developer doesn’t make any money from it directly, his business is built on his SEO expertise.
• Networking
  Having a plugin in the directory helps you to connect with other people in the WordPress community. People will be like, “Oh, you’re the guy who made that plugin. I love that!� The more popular your plugin, the more people will be interested in you.
• Custom work
  Offering a plugin means that someone out there might want your plugin to be customized, and they might be willing to pay for it.
• Job leads and opportunities
  You never know who is looking in the repository. Some big-wig might love your plugin and could be hiring. You could also use it as part of your CV, letting potential employers check out your code before even getting shortlisted.
• Kudos
  Everyone loves a plugin developer — and if they don’t, they should!
• Giving back
  Part of being a member of an open-source community is finding a way to give back. After all, we get the software that we build our livelihoods on for free. A free plugin in the directory is a great way to give back, especially if it’s a good one!

Of course, it’s not all happiness and sparkles. There are some aspects to having a plugin in the repository that put some developers off:

• Double the support
  If you offer support on your own website, too, then you’ll have to keep on top of two support forums.
• Unreasonable support expectations
  It’s sad, but some WordPress users feel that developers who give their plugins away for free should be at the beck and call of users. This leads to flaming in forums, hostile emails, angry tweets and the occasional midnight phone call.
• Keeping up with WordPress
  WordPress has a fast development cycle, with around two to three major releases a year (along with security updates and the like). Maintaining a plugin can become quite a chore, as is apparent from all of the orphaned plugins in the repository.
• #17 in the “Detailed Plugin Guidelinesâ€�
  This states that WordPress.org can revise the guidelines and arbitrarily disable or remove plugins whenever it feels like it. This arbitrariness does put people off.

A Commercial Plugin Shop?

It has long been fabled that Automattic might create some sort of WordPress app store where commercial plugin developers can sell their plugins to users straight from the WordPress dashboard. This will likely remain a fable, with no whisper from Automattic that anything of the sort is planned. Of course, there are places where you can purchase commercial WordPress plugins, such as WPPlugins and Code Canyon, but neither of these has the advantage of delivering plugins directly from the WordPress dashboard.

PlugPress tried a different approach. It created an “app store� plugin that WordPress users could install from the WordPress directory and then use to browse commercial plugins and themes. It uploaded the plugin to the WordPress repository and announced that it was live, and then the plugin was removed.

It’s a pretty clear signal that this type of store plugin won’t be allowed in the WordPress repository.

Amir Helzer (who we met earlier) has another approach. He posted a few months ago on the WPML blog about an alternative repository for commercial plugins and themes. His premise is similar to the approach taken in the Linux world. Every theme and plugin author can become their own repository. So Theme Forest could have a repository, as could Mojo Themes, as could whoever else. A central plugin would enable WordPress users to select commercial sources from which to search for themes or plugins. This would essentially make commercial plugins available in the dashboard and enable people to easily upgrade. It’s a novel idea, but given PlugPress’ swift exit from the repository, you won’t be seeing this in the WordPress directory anytime soon.

Conclusion

I firmly believe that placing restrictions on something spurs greater creativity, and the models above demonstrate how commercial plugin developers are thinking outside the box to use a directory that is essentially for free plugins. If it were simply a matter of a WordPress app store, then all of us would be in danger of buying plugins that aren’t very good (Apple’s App Store, anyone?). Plugin developers think creatively, which can only be a good thing for end users. Astute plugin developers will always find ways to use the WordPress plugin repository to promote their products, and I hope that their plugins are the better for it.

Developers are undoubtedly creating synergy between their commercial products and the repository in other ways. If you know of any, we’d love to hear about them in the comments!

Further Resources

• Looking for a service to sell your plugins? Try WPPlugins or Code Canyon.
• “Plugin Repository and Commercial Plugins,â€� WordPress Tavern
  A discussion about commercial plugins in the repository.
• “How to Improve Your WordPress Plugin’s Readme.txt,â€� Siobhan McKeown
  An article by me, right here on Smashing Magazine.

(al)

© Siobhan McKeown for Smashing Magazine, 2012.