The problem a lot of people run into is that they end up assigning too many tags to their posts. This defeats the purpose of tags. If you only end up with one or two posts with that tag, it hardly deserves its own “category.”

As mentioned, tags are somewhat like categories — but just a little more specific. For example, here at WPMU, we obviously don’t think the term “tags” is big enough or important enough for its own category. However, I am going to tag this post “tags” because it seems like an important enough/big enough topic that other posts will also touch on it some significant way.

I’m NOT, however, going to tag this post “merge tags.” That topic isn’t large enough to have a significant number of other posts that talk about that.

To be honest, I might have done that in the past, but we’ve come to realize it’s not really that valuable. And so we’re actually in the middle of cleaning up our “tag problem” by deleting many and merging the rest.

If you’ve got a tag problem too, read on.

How to Merge Your Tags

In order to help you merge your tags, I’m going recommend you use a plugin called Term Management Tools.

Once that’s installed, you’ll need to hop on over to your tag screen (Posts > Tags).

Get Rid of Unused Tags

Probably the very first thing you should do before you start merging is to start deleting. You may find a number of tags will be hard to merge with others. You might also find that somehow you’ve ended up with tags that aren’t assigned to any post at all.

On your tag page, if you click on the “Posts” link on the right, it will arrange your tags by the number of times they’re assigned to a post. I’d start by checking the box for all the ones that say “0” and then using the pull-down menu at the top and deleting them.

Get Rid of “Difficult” Tags

You can then start looking down through your other tags and seeing if there are any you know you can delete right away – i.e. tags that not many posts use and that will be difficult to merge with others. Again, the best candidates here will be the ones that are assigned to only a few posts.

As before, check the box next to the name of the tag, and then use the pull-down menu at the top.

If you have a large number of tags, you may want to increase the number you can see on one screen by pulling down the Screen Options panel at the top and bumping that number up.

Merge Remaining Tags

Assuming you’ve got the Term Management Tools plugin active, you can now get to merging your tags.

Go through your remaining list and check all those that should be merged together into one term.

In my example, I am checking the tag “blue” and the tag “blue things.” From the pull-down menu at the top, I choose “Merge.”

When I choose “Merge,” another box appears just to the right of the pull-down menu. I simply write the name of the tag both of those tags will be merged into. In my case, I’m writing in the name “blue.” But you don’t have to write the name of an existing tag here. You can write the name of a completely new tag.

Click “Apply,” and your tags will be merged.

If you have a lot of tags, this process may take a while, but it will be worth it in the end. It will be better for your users, and you can give up the tag addiction that so many of us are afflicted with.

(Note: Once the job is done, you can delete this plugin from your site. No use keeping unused plugins around.)

Photo: Red Tag from BigStock

Related posts:

1. Featured WordPress Plugin: Simple Tags This week I’m going to look at some plugins that...
2. How to Merge Categories in WordPress No plugin necessary - check out this quick guide for...
3. 11 Ways to Make Your WordPress Site Faster and Leaner Is your site slow? Does it it crawl at a...

We’ve put everything we can into this to provide you with a truly professional email newsletter setup, including pretty much everything you could require:

• Super easy setup and configuration
• Beautiful, fully customizable templates
• Along with a great template builder
• Powerful user management (including import)
• User groups & group management
• Detailed informative reports
• Cracking widget interface and behavior
• SMTP much improved
• Add user data to newsletters
• Display emails in browser
• Shortcodes galore
• New hooks to integrate with other plugins
• And much, much more
• With amazing support and usage docs, if you need them

And of course as it’s a WPMU DEV plugin it’s guaranteed to work, guaranteed to be updated and comes with guaranteed support.

Not bad huh :) Let’s take a look under the hood…

The template builder is just like editing a theme in WordPress, in fact it’s identical :)

And of course the plugin comes with a bunch of pre-built, gorgeous templates for you pleasure, for example:

And here’s one of my personal favorite features, adding and managing users and groups:

And of course logged in users (for example, on Multisite or BuddyPress installations) can easily manage their email subscriptions via the widget, yum:

And there is so, so much more… in fact here’s that video again if you missed it the first time round, 60 seconds and you’ll be convinced.

We’ve been working on email functionality for WordPress for years, for example there’s Subscribe by Email, Mass Email (old skool MU!), BuddyPress Group Email and Automessage (drip email), but we reckon this is the best of the lot, by a long way.

Download e-Newsletter here, woohoo!

Photo credit: Today is a good day

Related posts:

1. MailChimp email newsletter WordPress MU integration! Did you get our Useful WPMU Links newsletter? If so,...
2. Aweber vs. Mailchimp: Which is the Best Email Newsletter Service? Comparing the two most popular email building services and seeing...
3. Send HTML Emails with WordPress and the e-Newsletter Plugin We’re very excited to introduce our brand new e-Newsletter plugin...

And of course, from a business perspective I could hardly be more interested… man I’d love to have WPMU.org in there, since the early days it’s been the holy grail of ‘writing about WordPress’ publishing.

But let’s be honest, these days it’s a waste of space, an afterthought, a void and a vacuum, it’s tumbleweed across a deserted dashboard… in short, it’s pants.

And I think, especially with 10 years coming up, it’s about time it was sorted out.

Specifically, let’s:

1. Remove the pointless, non-updated, irrelevant & repetitive stuff (see below for the complete teardown)
2. Add in some of the massive amounts of good stuff out there (see below that)
3. Not let people ‘buy their way’ into it
4. Actually make it work.

So, without further ado…

So, what is the WordPress Planet… and why should I care?

Well, that’s easy, it’s this aggregation of ‘blogs talking about WordPress’, which goes into the dashboard of every WordPress site as ‘Other WordPress News’ [headlines only]

Historically this has been the place where people are supposed to go to to get their WP news, resources, information and increasingly tutorials.

Along with occasional controversy.

It’s included in something stupid like 60,000,000 WordPress sites, by default.

And what’s the policy for inclusion, well it’s pretty simple

This is an aggregation of blogs talking about WordPress from around the world. If you think your blog should be part of this send an email to Matt.

It’s Matt’s list, that’s taken care of that then.

And it’s been stagnant, or worse, pretty much since it’s inception, specifically because of…

Who is on the Planet… should they be?

Here’s the complete list, with my thoughts attached, would be interested in others, I’m by no means the expert in this.

Essentially my criteria is whether these feeds are adding value to a WordPress user by being in there, or not, along with a dash of whether  they are updated and/or any good.

Also, I’m going to take the position that commercial entities shouldn’t be there.

• Akismet - Commercial entity, so no
• Alex King - A mixture of commercial and personal WP GPL stuff, yes
• Andrew - Not updated for over 2 years, no point
• Andrew Nacin - One post in the last year, not really on WP, so nope
• Andy Skelton -  Nothing on WP since 2011, drop
• BuddyPress - BuddyPress, obviously yes
• Dev Blog - Yes, duh
• Donncha - A couple of super cache updates, could just be done in plugin, so no
• Dougal Campbell - 8 relevant posts in the last 12 months is good enough for me, pass
• Gravatar - Hmmm, really, bit like Akismet, for WP accounts, so no
• Jane Wells - Name needs updating, 2 related posts in last year (one much better off on make.wordpress.org), so no
• Joseph - Another Automattician, couple of commercial posts but half a dozen decent relevant WP ones so yes
• Lloyd - Broken feed / site offline
• Lorelle on WP - Makes sense, plenty of news, yes
• Mark Jaquith - Half a dozen relevant ones, so yes
• Matt - Good when relevant, shouldn’t really be *everything*
• Mike Little - Two posts on WP birthdays and one WordCamp announcement in 12 months… naw
• Peter Westwood - Nothing since Jan 2012, begone
• Ping-O-Matic - This is a bit silly, remove
• WP Android (feed) - Unnecessary, surely, wouldn’t one feed, or the dev blog, do it?
• WP Blackberry (feed) - “”
• WP Nokia (feed) - “”
• WP Windows Phone 7 (feed) - “”
• WP iPhone (feed) - “”
• WPTavern (feed) - I’d say no, given their new ambitions and shady context (more on that below)
• Weblog Tools Collection (feed) - Just been sold to a new buyer, who knows if they are trustworthy, remove please (see below)
• WordPress.tv (feed) - Makes sense
• WordPress.tv Blog (feed) - Really, do we need it twice?
• bbPress (feed) - Of course
• mdawaffe (feed) - Half a dozen posts since 2005, dunno why this is even here, remove

Results:

Keep = 10
Remove = 20

Ooo, controversial, so why no WP Tavern or WLTC?

As I mentioned above, both are now folded / retired / rebirthed and both now owned by unknowns, or maybe the same unknown!

And in the ultra-competitive space of WordPress publishing (we’re all doing this for a reason, let’s not kid anyone, advertising, WPMU DEV, other revenue streams, our egos…) both are gaining a massive commercial and competitive advantage over other sites in the space.

Surely that shouldn’t be for sale? It just doesn’t seem right.

And I mean, wannabee Valleywag WP Candy was included and then taken out again (for being basically pants too, I think). So it’s not like these things aren’t done and considered. I wonder when and/or why the chap upstairs removed them.

I’d say that until WLTC demonstrates if it’s going to get back on its feet and start doing good WP stuff, then it shouldn’t be included.

And that WP Tavern should probably also be put on probation, at least until we know who is behind it and what their motives are… as well as asking whether it’s covering or offering the kind of stuff we are after.

And who should replace them?

Because there are a lot of excellent sites about WordPress out there, and not in the Planet, that are far, far better.

Obviously WPMU would provide a completely non commercial feed if asked, but we’re not going to be, so that being said I reckon that, we should see:

• WP Daily – John’s transparent enough and doing a good enough job to warrant inclusion
• WP Mail – A web version of this should absolutely be included, it’s the best aggregation (alongside WP Daily’s) of what’s going on
• Smashing Mag WP Section – Great, detailed, quality, in-depth articles, why on earth not?
• WP Tuts + – Clearly Envato are back in the good books, having 1% GPL products is enough, yay, why not give ‘em a slot

And also…

• WP Lift – Why not, they give it a good crack
• WP Beginner – Always good quality
• WP Mayor – Doing a good job
• Chris Lema – Bit more commercial, but worth it

In my opinion these sites all offer fantastic, regular, fairly unbiased and mostly non commercial useful news, information and resources about WordPress… why not make that the criteria and shake up the Planet a bit.

How does that sound? Got any other suggestions, leave ‘em in the comments.

And while we’re at it…

How can we make The Planet actually work?

Well, howabout we stop thinking about it as an afterthought.

With as many people using WordPress as there are currently are, why can’t Matt / Automattic / The WP Foundation / The Community actually get it right on WordPress.org and in WP dashboards the world over.

Let’s start with removing the fluff and bringing in the good.

And then let’s let (or pay, in $s or links) Christian and Bianca curate it – and make it a proper big deal… not just an item in the dashboard (although we can keep that) but a weekly notification in the WP backend (easily turned off) that says…

Let’s celebrate the wonderful World of WordPress news, let’s not hide, it’s a huge strength.

And last, but not least, let’s make an editorial code for the setup and a board to enforce it, something like:

• Strictly non commercial work, not promoting any one product (products must be reviewed)
• Fair and unbiased
• No affiliate stuff ever, whatsoever, under any circumstances
• No advertising within posts (only on your own site)

And anything else you can think of.

It’s not rocket science, it’s just making some effort and doing it properly.

What say you?

Related posts:

1. Nice work with the WordPress Planet, now let’s make it just about WordPress It’s great to see WP Tavern and WP Candy added...
2. Subscribe to the BuddyPress News Planet Quickly catch up on BuddyPress news with this new resource....
3. Who Wears the Pants in Your BuddyPress Groups? New Plugin Gives You the Power To Promote, Demote and Block Users With Ease A plugin for managing BuddyPress groups is hot off the...

When you browse the code in the default WordPress theme, you have no idea what any of it does and you are running out of time. You need a crash course in the worst way. You need the Naked WordPress Theme.

Learn how to theme WordPress with the Naked WordPress theme

The Naked WordPress theme was created by Joshua Beckman to be “The solution for designers who don’t know WordPress”.

This is not your ordinary bare bones theme, stripped of everything but the essentials. Naked WordPress assumes that you know nothing about WordPress and includes comments on all aspects of the theme. Every single piece of the template files is commented so that you can understand what it does. Armed with that knowledge you can safely rearrange and customize your theme. You’ll be able to remove pieces without worrying about deleting something essential.

Here’s a quick example of just how useful the Naked WordPress theme is for beginners. If you’re brand new to WordPress, you probably have no idea what wp_head() does. Naked WordPress clues you in to how important it is so that you don’t screw things up:

1
2
3
4
5
6

<?php wp_head(); 
// This fxn allows plugins, and WordPress itself, to insert themselves/scripts/css/files 
// (right here) into the head of your website. 
// Removing this fxn call will disable all kinds of plugins and WordPress default insertions. 
// Move it if you like, but I would keep it around.
?>

With this kind of commenting built into the theme, there’s no need to look things up in the codex when you’re building in a hurry. The functions are neatly summarized and commented inline to save you time.

Naked WordPress features:

• Responsive styling
• Custom menus
• Custom sidebar and widgets
• Blog, with all the WordPress goodies we know and love (comments, categories, tags, etc.)
• Pages, Home page

Of course, reading up on the codex and learning all the ins and outs of WordPress theming is highly recommended if you want to be able to expertly navigate it and create your own themes. However, if you’re more interested in designing the theme than building it, then the Naked Theme will help to keep things moving while you’re still learning WordPress. It functions as both a starter theme and a crash course all in one.

Download the Naked WordPress theme for free from its homepage and follow the project on github. If it helps you build something, consider showing a little love to the developer by way of a donation.

photo credit: emanuela franchini via photopin cc

Related posts:

1. The Rankings: 90 Most Popular Premium WordPress Theme Designers The most popular WordPress design shops are ranked from 1...
2. WordPress Theme Team Releases Free Underscores Starter Theme Using the Underscores starter theme just got a little easier....
3. 7 Free, Modern Starter Frameworks for WordPress Designers Get a rundown of the 7 best free WordPress frameworks...

In fact, in good internet fashion, you can see some of the very first stirrings of WordPress in a post where Matt laments that b2 hasn’t been updated in a while, and he’s thinking of splitting off from it. The first commenter on that post is Mike Little saying, “If you’re serious about forking b2 I would be interested in contributing.”

And WordPress was born.

In order to celebrate the occasion, we thought we’d take a look back at these last 10 years. No doubt you will be seeing a lot of “looking back” posts over the next few weeks, going over features that have been added and important decisions that have been made.

But in this post we thought we’d take a different tack. With the help of the Wayback Machine from archive.org, we thought we’d go take a look at how WordPress.org itself has changed stylistically over the years. For those of us who spend a lot of time on the site, it might take us back.

Although it still holds to its roots of uncluttered simplicity today, there have been a number changes along the way. Take a look for yourself.

June 18, 2003

This was the first screenshot we could get a hold of, and so we’ll start here. As the official birthday is in May, and we find ourselves in May now, from here on out we will sample each year from a date in May.

About Page

It might also be interesting to take a look at the first About page for the site. You’ll notice a few interesting things there. One of the more interesting is a mention that the name “WordPress” itself came from Christine Tremoulet of BigPinkCookie.com. (Yes, her blog runs WordPress.)

Utilities?

You might notice an odd menu item there that you aren’t used to – “Utilities.” Here’s what that page consisted of.

By July 29^th, however, the name “Utilities” had been changed to “Hacks.”

Showing Off the Goods

Of course it’s a good idea to show off the wares to potential users, and so screenshots were included. Here’s a look at the first editor:

You can see more screenshots here.

It’s interesting to note that the WordPress.org site these days doesn’t seem to advertise screenshots of the backend. Perhaps because it’s free and easy to install, no look at the backend is really needed.

May 2004

Taking a look at the site the next year, we see a few changes.

Of course one change is the dark, right-side column where WordPress features are highlighted. Another little change is the shadow against the background.

Donate

In the menu, we also see a Donate button has been added. Taking a look at that page, we see a somewhat vague promise of “additional benefits.” OK, not a “somewhat “ vague promise — a completely vague promise.

Screenshots

And we also get a look at the updated editor.

May 2005

In 2005, things look pretty much the same, but we can see by the top menu that a blog has been added and a section to recommend web hosts.

Screenshots

In the screenshots section, you’ll notice that they’ve begun advertising themes in a more upfront way.

One other little note here. You may notice a little banner in the top right-hand corner that WordPress had been named Application of the Year by ArsTechnica. Here’s what they said: “WordPress is the most prominent rising star of weblog software, completely free and with a large and active community. Styles, plugins and hacks are readily available, with problems such as comment spamming being addressed far more rapidly than competing applications.”

And here’s a screenshot of the editor for that time.

May 2006

In 2006 we see a lighter, cleaner look with the removal of the background image. We now also see some navigation on the left. You might also notice the “Donate” button is now gone.

Themes and Plugins

In the menu, you’ll notice the first section for plugins and themes called “Extend.”

If we take a look at the themes section, you can see there were six! And you viewed their thumbnails by scrolling from left to right.

May 2007

No real changes to the homepage this year, and so we won’t include it here. Also, though there was the beginning of a theme directory, by May of 2007, it seems to have been eliminated. However, you can see that the plugin directory had really started to take off.

Year 2008

By 2008, the homepage had taken on a heavier look with a dark gray header area.

Plugins

In 2008 the plugin section had been reorganized (still no theme directory at this point). You’ll also notice some stats:

2,181 plugins, 4,082,686 downloads, and counting

At the time of this writing, those stats stand as follows:

24,897 plugins, 453,551,157 downloads, and counting

May 2009

The next year saw only a few minor changes to the homepage, but you’ll notice a menu item for “Showcase” at the top now – a chance to show off sites out in the public using WordPress. It seems the Showcase was added in the fall of 2008.

By May of 2009, the theme directory was also back … in full force. (Technically it seems to have arrived in 2008.)

May 2010

No major changes seem to have occurred to homepage by May of 2010.

May 2011

By May of 2011 we see a return to a lighter homepage.

May 2012

In May of 2012 we see a few important menu changes. The “Extend” section has been broken out into “Plugins” and “Themes,” but more importantly, we see a sign of the times with an addition of a “Mobile” button.

We can also see that the plugin section has gotten a lot of love in the last year, including the addition of fancy headers, a star rating system, and a more integrated support area.

May 2013

And finally we arrive at today. We see a return to a darker header.

We also see a new menu item at the top called “Get Involved.” This pulls down to reveal a number of different areas of the site where you can learn more about the behind-the-scenes process of putting WordPress together, as well as where you can begin to help yourself.

And so not only do we have to end there, but it’s also an appropriate place to end. WordPress has made it ten years with the help of a lot of different people pitching in from all over the world. If you feel so inclined, and you’d like to see ten more years of improvement, then think about joining in here.

photo credit: camdiluv

Related posts:

1. 5 Tips for WordPress Bloggers from the Greatest Writers in History If you’ve got five minutes, I’ve collected some tips from...
2. How to Show a Post From Exactly One Year Ago Today There may be certain special occasions where you’d like to...
3. WordPress 2010: A Year in Review Today’s 12 Days of WordPress comes to you from Sarah...

Checking through each site on your network to see what plugins are in use is simply not an option. The task is much too tedious for a busy site admin like yourself. That’s where Plugin Activation Status saves the day. It essentially performs a plugin audit so that you can get rid of any extra baggage.

Find and dump all your unused plugins

When you first activate the plugin, you’ll see this screen with an empty list, located at Network Admin >> Plugins >> Active Plugins.

Click continue to generate the lists. Don’t do this during peak traffic time if you have a massive network as it might cause slow downs.

Plugin Activation Status will produce two lists:

• A list of plugins that are not currently active on any sites or networks
• A list of plugins that are active somewhere within the installation, accompanied by details of where and how those plugins are activated

Please note that this plugin is only for multisite networks, as it does not make sense for single site installs.

A good WordPress admin must clean up after himself.

Installing plugins just to try them out and not deleting them is a nasty habit. Sure, you’re in a hurry, but later on you’ll forget why you added those plugins and wonder if you’re really using them. Removing unused plugins is an important part of multisite maintenance. You’ll be able to see issues more clearly when troubleshooting if you have fewer plugins active, minimize security risks and keep your site leaner. Install Plugin Activation Status and it will tell you exactly which plugins you can dump for spring cleaning.

photo credit: atibens via photopin cc

Related posts:

1. 16 Time-Saving WordPress Multisite Plugins for Managing Your Network Check out these new plugins for WordPress multisite, selected to...
2. Keep a Clean WordPress Uploads Folder by Deleting Unused Images Many times while creating pages and posts a user will...
3. 24 Massively Useful Plugins for WordPress Multisite Networks Need some new tools for managing your WordPress multisite network?...

Those efforts at the end of last year really made working with galleries much easier and more pleasurable. And so if you’ve been enjoying the new galleries as I have, you may like this little trick that will allow you to put galleries pretty much anywhere you like in your site.

You do this by creating a gallery in a Page and then inserting some code into your theme’s template.

Besides being able to put a gallery pretty much anywhere, another nice feature of this trick is that you can easily go back into your gallery page and change it as you like  – adding photos, deleting photos, rearranging photos, etc. And of course all those changes will immediate take place on your site as well.

You’ll need to dig into the code once to set it up, but after that, changing things up is as easy as working with galleries through the media manager.

3 Steps to Inserting Galleries in Your Theme

Here’s a quick overview of the steps involved. We’ll go into details below.

1. Create a gallery in a Page
2. Find the Page ID
3. Insert a little bit of code into your theme’s template

1. Create a Gallery in a Page

As mentioned earlier, there’s a complete tutorial for inserting a WordPress gallery if you need it. In this post, we’ll assume you already know how to build one.

When you create your gallery, you will need to take into consideration where your gallery will go.

For example, let’s say you’d like to put your gallery into your sidebar. When you set your gallery up, one choice you’ll need to make is how many columns the gallery will have. If it’s going in your sidebar, for example, then you’ll probably want to keep the columns at one.

(Note: there is no option for rows, but we’ll talk about this later.)

If you set the columns for three, then you may get something that looks like this:

If you set your columns to one – which your sidebar has space for – then it will look like this.

The same is true for putting your gallery other places, of course. For example, say you want to put a gallery across the top all your pages by putting it in the header.

More than likely the best look will be stringing the thumbnails side-by-side all the way across the top in one row. (Of course you can do more than one row too, but you’ll probably want the thumbnails to be as close together as possible.)

For example, take a look at this page with thumbnails in three columns. The columns will spread themselves out to fit the width of the page. That leaves a lot of wasted space and takes up a lot of room (especially in a spot like the top of every page).

Now look at an arrangement that has all the thumbnails in one row.

(As mentioned, there is no “row” function in the gallery. You control the look by columns. And so in order to get one row, you just need to set the columns to be the same number as the number of thumbnails in your gallery. In this example, because I had six images, I set my gallery to have six columns.)

Again, you can have more than one row if you like. But in order to maximize space, it’s probably better in a case like this if you have more than one row only if there are too many images to fit on one row.

In the example below, I left the columns set to six, but I added six more images to my gallery.

2. Find the Page ID

The next thing you will need to do is to find the Page ID for the page with your gallery. You can see full instructions for doing that in this post.

3. Insert Code

The final step is to insert the following code in your theme’s template files where  you want your gallery to appear. (Appearance > Editor)

1
2
3
4
5

<?php
$id = ID#;
$p = get_page($id);
echo apply_filters('the_content', $p->post_content);
?>

You will need to insert your actual Page ID into the spot that says ID#. For example, if my page ID is 2428, my code in that section will look like this:

1

$id = 2428;

Or the complete bit of code again with the ID in place:

1
2
3
4
5

<?php
$id = 2428;
$p = get_page($id);
echo apply_filters('the_content', $p->post_content);
?>

And so that’s it. Just add that bit of code, and you’re ready to go.

Where to Put Your Galleries

As mentioned, you can put your galleries practically anywhere, you’ll just need to think about things such as layout and columns, etc.

Here are a few places you may think about putting different galleries:

1. All Category Pages – Put a gallery on all category pages by placing the code in category.php (or archive.php if category.php doesn’t exist)
2. Different Categories – You can put different galleries in different category pages (e.g. a “fruit gallery” on your fruit category page and a “vegetable gallery” on your vegetable category page, etc.) In order to do this, you’ll need to create individual category templates.
3. Header — Put galleries at the top of every page by placing the code in your header.php file
4. Footer – Put galleries at the bottom of every page by placing the code in your footer.php file
5. Pages – Put galleries only on Pages (not posts). You’ll need to put the code in your page.php file.
6. Posts – Put galleries only on the post pages where your full posts appear (i.e. not on the homepage, category pages, etc.). You’ll need to put the code in your single.php file.

Get Your Wheels Spinning

Don’t forget that you can link a gallery thumbnail to any page you like. Your thumbnails don’t need to simply link to a larger version of the image. They can link anywhere. … This may get some wheels spinning.

Also, while we’re talking specifically about photo galleries here, this little trick works for any content you put into the Page you created – text, single images, videos, etc. So let your imagination run free.

Related posts:

1. How to Insert a WordPress Photo Gallery into Your Blog Put an image gallery into your posts with a tool...
2. How to Create WordPress Photo Galleries with the New 3.5 Media Manager Learn how to use the more powerful and flexible WP...
3. Easily Add Galleries to WordPress Posts and Pages with TinyMCE Thumbnail Gallery Tinymce Thumbnail Gallery is a new plugin for adding a...

Solid multisite compatibility is one of the reasons that MarketPress is so popular. There is no better WordPress e-commerce plugin for operating multiple stores with one global shopping cart. This new extension compliments MarketPress’ built-in multisite capabilities.

The MP Product Search Widget plugin features:

• Advanced Product Search Options – narrow down the search through different parameters, such as category, tag, and price range.
• Compatible with Multisite for Global Searches – allow customers to make global product searches across your MarketPress network – just like Etsy.com does it.
• Built to Impress – display all the search results in a nice, beautiful modal view, together with product thumbnail, price, and ‘buy now’ button for each item.
• Advanced Sorting Options - allow your customers to sort the search results based on different parameters, such as release date, title, price, sales.
• Powered by AJAX – perform high-level search queries without crashing the server.

Multisite Compatible: Global Product Search Widget

Configuration options are the same as the single store search widget. The only difference is that it searches all stores.

Options for the widget include:

• Show or hide category filter
• Limit to custom categories
• Show or hide tag filter
• Limit to custom tags
• Show/hide price range
• Choose from 7 different color skins
• Limit visibility to store pages only

Want to try out a live demo of the search to see how it works? Check out the search widget on any of these themes:

Live Demo: FlexMarket | PRO | GridMarket | SimpleMarket | Twenty Twelve

Download MP Product Search Widget for Free

There are a couple of different avenues for downloading the plugin – either way it’s free. The first option is to visit MarketPressThemes.com and create an account. Then you can proceed to the user dashboard to download the plugin. The plugin is also available at github if you want to grab the zip file directly. Many thanks to the folks at MarketPressThemes.com for making this plugin available for free.

Related posts:

1. Global Search for WordPress MU and BuddyPress One of the things we’ve been asked a lot for...
2. WPMU DEV MarketPress 2.0 Released – Now with Downloadable Products, Global Carts and Much, Much More! Yes, that’s right, it’s the one you’ve all been waiting...
3. Add a Search Widget to Your bbPress Forum New widget lets you search forum/forums, topic/topics and reply/replies within...

These numbers are somewhat affected by one organization, the NY Times, having seven blogs on the list and another organization, Wired, having three blogs on the list. That said, no one can doubt that the trend for WordPress has been an upward one.

The following chart is from Pingdom.com.

And here’s a list comparing last year’s results and this year’s results.

To see a list of what each of the Top 100 use, head on over to the Pingdom report.

Related posts:

1. Edublogs Celebrates 1,000,000 Blogs! Lots of hard work and great features makes for one...
2. Report: Top Bloggers Use WordPress More than Any Other Blogging System A new report shows that WordPress is the platform of...
3. Introducing Blogs.mu So, there you go, that’s our big news – say...

This required rethinking the whole strategy of hosting them: instead of having huge server with almost unlimited memory, disk space, many CPU cores, and infinite resources, I had to somehow extract the same amount of performance out of this tiny virtual server. How?

After a whole week of reading mostly outdated tutorials, and evaluating many different approaches and strategies, it was clear that my beloved LAMP environment, favored by so many for running WordPress, had to go. Apache simply refused to be fit into such strict limits.

The alternative seemed to be Nginx, which I had absolutely no experience with, so I was not expecting miracles — and I was aware that WordPress has been designed to take good use of Apache’s tricks, like mod_rewrite to get not only pretty URLs but also work tightly with disk caches.

But to my utter surprise, not only Nginx plays nicely with WordPress, but the result was unsurpassable performance that I never thought to be possible! Small is beautiful, but it can be ultrafast too. Here’s how!

Requirements

For this tutorial you will need three things:

1. A virtual machine (also known as virtual private server), either created on your own computer (using VMWare or similar software), or, more likely, leased from a commercial provider. You can get a good overview of pricing and features at CompareVPS. I’m using a VPS with 512 MB of RAM, 40 GB of disk, and 500 GB of monthly traffic for a bit less than US$10/month.
2. A pre-installation of Ubuntu. For this tutorial we will use Ubuntu 12.04. There are more recent versions; and many of the commands and configurations will probably work under Debian Linux as well. Commercial providers will usually pre-install the operating system when you sign up with them.
3. Some familiarity with Unix console commands. At least you should not be afraid to experiment with them!

Quick overview

So here is what we’re going to install. First, we’ll begin with MySQL, and tweak it a bit to get it to fit into our limited-memory environment.

Then comes Nginx with a basic configuration. Nginx requires an external way to communicate with PHP, so we will need to install PHP-FPM — a way of managing PHP FastCGI processes which shows good performance on benchmarks (and yes, that’s precisely what WordPress.com is running to achieve their levels of performance), and fine-tune it all.

We’ll be using PHP with the Alternative PHP Cache (APC) — a way to speed up PHP processing — which plays nicely with the W3 Total Cache plugin (which, in turn, is fully Nginx-aware).

And finally we’ll explain how you can host multiple sites with completely different domain names using a single WordPress multisite installation.

Caveats and disclaimers

Before you start following this tutorial, you should have in mind a few things. Choosing the “best” setup for WordPress is a tricky business, because, on one hand, it depends on the definition of “best”; but on the other hand, it depends on your WordPress setup (and the hardware it’s running on), what it’s being used for, the kind of data (like images and multimedia files) you’re hosting, and, more importantly, your visitors and what they’re doing.

There are plenty of benchmarks on the Web attempting to “prove” that one solution is “better” than others. I did the same for my own particular setup, and what will be described below is the result of my own tests. But you might have a different environment and not be able to reproduce the same results.

For instance, some people question very seriously the claim that Nginx + PHP-FPM is actually slightly slower than Apache + mod_php unless you have a lot of static content (because Nginx will serve it directly without the need of contacting the PHP-FPM backend). If you have plenty of memory to spare, a solution using Varnish + Apache + mod_php might beat a very fine-tuned Nginx + PHP-FPM solution. Just because Nginx + PHP-FPM might work best for the kind of setup that WordPress.com has, it doesn’t mean it’s the best for you.

But if you have a very tight environment with few resources — or, instead of opting for a huge server with lots of memory and CPU, you prefer to distribute your load among several small cloud instances — then this tutorial might help you out with extracting the most performance out of your tiny virtual private server.

Installing MySQL

So, your virtual server provider has just sent you the access password to your own slice! It’s time to to log in via SSH and start installing things. We’ll begin with MySQL.

Some pre-installed versions of Ubuntu might have MySQL 5.5 already as part of the package list. If not, what you need is to run:

1

sudo apt-get install mysql-server

Now it’s the time to tweak MySQL to make it fit into as little memory as possible, but still perform adequately well. The first choice is to either go with MyISAM or InnoDB, the two most popular table engines. MyISAM is the oldest one, InnoDB comes as default with MySQL 5.5.

Discussions have been raging on the Internet about which solution is best for WordPress, and, again, it might be a matter of personal taste and specific environment. What is important here is that if you just use one of them. It’s pointless to let MySQL run both, and that will save you some memory.

After some reflection, specially after reading Mark Maunder’s article (who benchmarked MySQL using both approaches), it seems that MyISAM might be a preferred choice on single-CPU environments. Since for this tutorial we’re using a tiny virtual server, which might just have one CPU core, we’ll stick with MyISAM.

Open /etc/mysql/my.cnf (you will need a text editor; nano is a popular one and should be installed on most systems; if not, sudo apt-get install nano should get you that) and change/add the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

#
# * MySQL configuration for tiny memory footprint
#
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
skip-networking
key_buffer = 24M
sort_buffer_size = 4M
read_buffer_size = 4M
#binlog_cache_size = 2M
max_allowed_packet = 12M
thread_stack = 128K
thread_cache_size = 8

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP

#max_connections = 200
#table_cache = 64
table_cache = 128
thread_cache = 256
#thread_concurrency = 10
thread_concurrency = 4
myisam_sort_buffer_size = 1M
tmp_table_size = 12M
max_heap_table_size = 12M
wait_timeout = 200
interactive_timeout = 300
max_connect_errors = 10000

#
# * Query Cache Configuration
#
query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 16M

#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!

skip-innodb
default-storage-engine = myisam
skip-external-locking
skip-slave-start
skip-name-resolve

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

Some short explanations on the above configuration: you might have seen tutorials for improving performance under MySQL, even from Matt Mullenweg himself, and the settings are a bit higher. Here we’re looking at a compromise: we don’t want MySQL to have terrible performance, but we don’t want to have it consuming too much memory.

The more surprising aspect might be “no networking” (and all the related aspects to that, e.g. skipping name resolving, and so forth) and getting rid of InnoDB completely. This saves us some networking buffers, but, of course, it means that WordPress will need to contact MySQL on an Unix socket and be installed on the same machine; we’ll see how this works later on.

If you prefer to run two servers, side-by-side, one with MySQL, the other with Nginx/WordPress, then of course you will need to turn networking on. This might be a more suitable environment for cloud-based networks — some providers allow you to allocate a set amount of CPUs, memory and disk, but you can launch as many instances as you wish.

Usually, only some of those will be accessible by the outside world, and the rest is inside a “private” network, with no routing to the exterior. Cloud providers usually do not charge anything for traffic among your virtual instances — only for traffic that crosses the boundary to the “real world”.

This will mean that although you have open network connections in this case, they’re completely shielded from the outside world, and, as such, are secured. And, of course, you can later duplicate the MySQL instances (or the front-end instances) if you need.

But for this tutorial, we’re keeping it simple: everything is inside the same virtual private server, and, as such, networking is not necessary — we can communicate via Unix sockets instead.

Start MySQL with:

1

service mysql start

At the end, you should most definitely set a root password (also known as “administrative account”) for MySQL, since by default it’s empty. There are many ways to do that, but Ubuntu 12.04, for MySQL 5.5, has a neat command:

1

sudo dpkg-reconfigure mysql-server-5.5

Under other distributions, you will need to use the following commands:

1
2

sudo mysqladmin -u root -h localhost password 'mypassword'
sudo mysqladmin -u root -h myhostname password 'mypassword'

Remember to pick a very hard-to-figure-out password, preferably randomly generated.

Installing Nginx

The next step is to install Nginx. This is a software application that is under constant development, and it pays off to get the latest batch of security enhancements. Unfortunately, the Ubuntu core developers are not always up-to-date with Nginx, so the recommended choice, as per the Nginx Wiki, is to add it from a third-party repository (or, as the Ubuntu crowd calls them, from a Personal Package Archive [PPA]), which is maintained by volunteers and is not distributed by nginx.org. It has some additional compiled-in modules and may be more fitting for your environment.

1
2
3
4
5

sudo -s
nginx=stable # use nginx=development for latest development version
add-apt-repository ppa:nginx/$nginx
apt-get update
apt-get install nginx

If you get an error about add-apt-repository not existing, you will want to install python-software-properties:

1

sudo apt-get install python-software-properties

and then just run the above commands again.

Overview of the configuration for Nginx

You can run Nginx and Apache side-by-side on the same server (for instance, letting Nginx deal with static content and having Apache handling PHP), but for this tutorial, we’re going to assume that only Nginx will be running, and we will use the same data directory structure (the one where the actual files for the websites are going to be) used by Apache.

Why? It will make changing to Apache easy, if you decide to drop Nginx; or, if you’re following some tutorials on the Web, which assume you have a “standard” structure for a Linux distribution with Apache, then you won’t be much confused about the right directory to place your files.

What this means is that all data will be under the /var/www directory. Nginx itself follows a configuration style which is similar to all applications under Debian/Ubuntu. The main configuration directory is /etc/nginx. The main configuration file is /etc/nginx/nginx.conf. Additional configuration files (we will use that for adding WordPress-specific configurations) are under /etc/nginx/conf.d; they will be automatically loaded when Nginx restarts/reloads.

And finally, all website-specific configurations (for each virtual host) will be under /etc/nginx/sites-available. Each time you create a new virtual host, that configuration file will be symbolically linked to /etc/nginx/sites-enabled.

Some Nginx configurations that you might find out there will probably just use one single file for everything (Nginx usually doesn’t have very long configuration files anyway). Here, however, we will split everything according to the usual tradition of Debian/Ubuntu. The idea is that each virtual host will have as little different information  as possible, and draw from common rules for everything.

Installing PHP5, PHP5 Extensions and PHP-FPM

Nginx, as you might remember, does only handle static files — everything else needs to be passed to an external service. In our case, we’ll use PHP-FPM to handle PHP5 on behalf of Nginx. PHP-FPM is like a mini-webserver, with its own options, but which will only process PHP — we’ll get back to it later.

Figuring out what PHP5 extensions you really, really need to have is not always easy! For this tutorial, we want to have PHP5 with as few extensions as possible (to make sure it consumes little memory!), but we need at least a few, since WordPress (or some of the plugins) will depend on them.

I have mostly followed Rahul Bansal‘s suggestions. The first thing is to make sure we get PHP 5.4 (instead of the default PHP 5.3 which comes with Ubuntu 12.04 LTS), and that means adding another repository to get the latest version. Newer versions of Ubuntu might already have PHP 5.4 as the default, so you might wish to skip this step.

1
2

sudo add-apt-repository ppa:ondrej/php5
sudo apt-get update

Now we need to install PHP5 and all the necessary modules:

1

sudo apt-get install php5-common php5-mysql php5-xmlrpc php5-cgi php5-curl php5-gd php5-cli php5-fpm php-apc php5-dev php5-mcrypt

For some WordPress plugins you might need to add php5-pear to that list, as well as a few others (like php5-imap if you are using some sort of newsletter which gets mailed out to your users). International users will probably add php5-intl. I normally add php5-tidy which gets used by W3 Total Cache, but it is not strictly necessary.

Configuring Nginx

To give you a rough overview of what the Nginx configuration below does, it’s good to understand that Nginx is configured with rules: as it gets an URL, Nginx will need what to do with it — look up into a certain directory for a static file (for images, CSS, and so forth), pass PHP scripts to PHP-FPM, or block access (for security reasons).

Nginx can obviously do quite a lot more processing, like adding no-expiry headers and removing cookie requests for static files (for better caching), or gzip‘ing everything on the fly (for saving bandwidth).

Here is the /etc/nginx/nginx.conf file which handles most of the common features:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

user www-data;
worker_processes 1;
pid /var/run/nginx.pid;
events {
 worker_connections 256;
 # multi_accept on;
}
http {
 ##
 # Basic Settings
 ##
 sendfile on;
 tcp_nopush on;
 tcp_nodelay on;
 keepalive_timeout 65;
 types_hash_max_size 2048;
 server_tokens off;
 client_max_body_size 8m;
 reset_timedout_connection on;
 # server_names_hash_bucket_size 64;
 # server_name_in_redirect off;
 index index.php index.html index.htm;
 include /etc/nginx/mime.types;
 default_type application/octet-stream;
 ##
 # Logging Settings
 ##
 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;
 ##
 # Gzip Settings
 ##
 gzip on;
 gzip_disable "msie6";
upstream php5-fpm {
 keepalive 8;
 server unix:/var/run/php5-fpm.sock;
 }
# include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;
}

Notice a few things. First, worker_processes should be set to 1 per CPU (in my own VPS I just have one CPU). client_max_body_size is the size of uploaded files through POST; I believe it defaults to 1m (one megabyte), but 8 is the default used by PHP for file uploads, so I suggest those two settings are kept with the same values.

The upstream command is the setup to talk to PHP-FPM: as you can see, like we did with MySQL, we’re using Unix sockets to communicate with PHP-FPM. If you had a setup with Nginx on one VPS and PHP-FPM on another (using Nginx, say, as a front-end reverse proxy/caching server), you would use server my.ip.address:portnumber instead.

In this tutorial, we’ll show you both the single-site and multisite configuration for WordPress. The configuration files for those two choices will be stored under /etc/nginx/conf.d/, so we will activate the appropriate ones on demand. That’s why this line is commented out — we don’t want to load both configurations, since WordPress works rather differently under multisite mode!

The configuration for single-site WordPress (save it under /etc/nginx/conf.d/wordpress.conf) is as follows, inspired by the recommendations at WordPress.org and the entry for WordPress on the Nginx Wiki, which describe best practices as well how to avoid some common pitfalls.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# WordPress single blog rules.
# Designed to be included in any server {} block.
# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
 try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
 access_log off; log_not_found off; expires max;
}
# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
 # Zero-day exploit defense.
 # http://forum.nginx.org/read.php?2,88845,page=3
 # Won't work properly (404 error) if the file is not stored on this server, which is
 #  entirely possible with php-fpm/php-fcgi.
 # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  #  And then cross your fingers that you won't get hacked.
 try_files $uri =404;
 #fastcgi_split_path_info ^(.+\.php)(/.+)$;
 #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
 include fastcgi_params;
 fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_intercept_errors on;
 fastcgi_keep_conn on;
 fastcgi_pass php5-fpm;
}

And now the rules for WordPress running in multisite mode (save them under /etc/nginx/conf.d/wordpress-mu.conf):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.
index index.php;
# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
 try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
 # Zero-day exploit defense.
 # http://forum.nginx.org/read.php?2,88845,page=3
 # Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
 # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. And then cross your fingers that you won't get hacked.
 try_files $uri =404;
# fastcgi_split_path_info ^(.+\.php)(/.+)$;
 #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
include fastcgi_params;
 fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_intercept_errors on;
 fastcgi_pass php5-fpm;
}
location ~ ^/files/(.*)$ {
 try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
 # access_log on; log_not_found on; expires max;
}
#avoid php readfile()
location ^~ /blogs.dir {
 internal;
 alias /var/www/wordpress/wp-content/blogs.dir ;
 access_log off; log_not_found off; expires max;
}
# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
 access_log off; log_not_found off; expires max;
}

The difference is mostly dealing with file uploads, since each WordPress multisite installation will have a “common” area, but separate areas for the uploads. We will see later how this magic happens (hint: we will need to map each subdomain to the correct $blogid).

For now, notice that this configuration is not perfect: I had to explicitly add alias /var/www/wordpress/wp-content/blogs.dir; — ideally, this should be set from each virtual server’s configuration, or this will work with just one multisite installation…

Beyond these rules, we’ll add also a common set of restrictions, in an attempt to make Nginx more secure. Place them under /etc/nginx/conf.d/restrictions.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Global restrictions configuration file.
# Designed to be included in any server {} block.</p>
location = /favicon.ico {
 log_not_found off;
 access_log off;
}
location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
}
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /\\. {
 deny all;
}
# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\\.php$ {
 deny all;
}

All that is left to do are the configuration files for the individual websites! But first, we need to set up PHP-FPM; then, after we install WordPress, we will be able to see all of this working together: at this stage, all you can do is to see if there are any configuration errors:

1

sudo service nginx configtest

If all’s well, you should just see:

1

Testing nginx configuration: nginx.

Configuring PHP-FPM

PHP5 itself is configured from /etc/php5. Under Debian/Ubuntu, each different way of launching PHP5 will have its own, separate configuration — e.g. apache2 for the Apache configuration, cli for the command-line version of PHP5, and, naturally, fpm for PHP-FPM. They are all set independently, which sometimes might be confusing, as you can launch different modules and have different settings for each configuration.

We can start with /etc/php5/fpm/php.ini first, since it doesn’t need many changes. Just check that memory_limit = 128M (you can tweak this to consume less memory, but keep in mind that W3 Total Cache will consume a fair amount of memory — in exchange for superfast performance). You might have noticed from the Nginx configuration that we ought to use cgi.fix_pathinfo=0. Also remember to set date.timezone for your own timezone (it’s mandatory for PHP 5.4). The rest should be pretty much the standard.

Check under /etc/php5/fpm/conf.d which modules PHP5 should load. In my case, I had to delete 20-snmp.ini, which I didn’t need. Each of those files calls the appropriate extension and allows you to set extra parameters. You should have something like this list:

1
2
3
4
5
6
7
8
9

10-pdo.ini
20-apc.ini
20-curl.ini
20-gd.ini
20-mcrypt.ini
20-mysql.ini
20-mysqli.ini
20-pdo_mysql.ini
20-xmlrpc.ini

Now we need to configure the service that provides PHP to Nginx. PHP-FPM has an extra configuration file for that, stored under /etc/php5/fpm/php-fpm.conf. We will not need to change this file; this is the global configuration for PHP-FPM. Then it launches several pools.

The analogy is that PHP-FPM works a bit like a webserver with virtual hosts: php-fpm.conf has the overall configuration, and then we have separate configurations for the pools under /etc/php5/fpm/pool.d/. By default there is just one pool, www.conf, and this is all we need to edit. It’s a long file, I’m just showing some of the changes and checks you should do:

1
2
3
4
5
6
7

listen = /var/run/php5-fpm.sock
pm = dynamic
pm.max_children = 20
pm.start_servers = 3
pm.min_spare_servers = 1
pm.max_spare_servers = 5
pm.max_requests = 500

This looks familiar, right? First, we must make sure that PHP-FPM is using the same Unix socket than Nginx. Then we’ll use dynamic allocation of pools — in this case, we tell PHP-FPM to start with 3 servers (that means three processes ready to listen to PHP requests from Nginx), limit it to a maximum of 20, don’t keep too many spare servers around, and, every time a child process serves 500 requests, it gets killed.

This naturally reflects my own setup — 512 MB of RAM, some of which is naturally also needed for MySQL and Nginx itself (Nginx doesn’t eat much memory, though). After some careful tuning of the parameters, this allows me to serve something like 10 concurrent requests and have all processes in memory — no swapping!

But, of course, this depends on how many extensions you have loaded on PHP5, how much concurrency you really need (10 simultaneous connections is not that much), how quickly your webpage loads (which, in turn, depends on the plugins, widgets, external calls, and so forth)…

The whole trick is to twiddle with these numbers until you get acceptable performance, avoid disk swapping, and don’t leave your users endlessly waiting for pages!

If you want to have separate logs, which will report things like processes dying too early from lack of resources or connectivity issues with Nginx and similar errors, add the following to the www.conf pool configuration file:

1

php_admin_value[error_log] = /var/log/fpm-php.www.log

If not, PHP-FPM will just pipe most errors via Nginx (but not all), and they will appear on the webserver’s log.

You start PHP-FPM with:

1

sudo service php5-fpm start

Double-check that Ubuntu is launching MySQL, Nginx, and PHP-FPM when it boots (this is the default behaviour for newly installed packages providing network services); if not, use update-rc.d to check them all in.

Installing WordPress

Most of you will install WordPress directly from the sources, and a good reference for that is on the Ubuntu Server Guide website. I personally dislike the way Ubuntu handles WordPress as an application. It will be better integrated into the overall system, but you will only get upgrades when the Ubuntu team feels they should upgrade it. Looking at the dates of the last update, this was quite a while back. In the case of WordPress, the latest and greatest is also the safest (security-wise) choice, so I recommend to install it manually.

Although Nginx can read pretty much anything from any place on the directory structure, as mentioned before, I’m true to the “Apache/Ubuntu” way of organizing things, and that means placing everything under /var/www  — including, in this case, the virtual host that will hold our WordPress installation.

1
2
3
4
5
6

sudo -i
cd /var/www
wget -O wordpress.tar.gz http://wordpress.org/latest.tar.gz
tar -zxvf wordpress.tar.gz
chown -R www-data:www-data /var/www/wordpress
rm wordpress.tar.gz

Now we need to handle the database. WordPress needs a “clean” database (freshly created). In this example, we’ll also add a user just for that database.

If you prefer to use a Web-based database configuration tool, just follow the instructions on this tutorial about installing phpmyadmin. If you’re fine with using command prompts to make database changes, then log in to mysql server as the root user:

1

mysql -u root -p

Create a database with the name wordpress:

1

CREATE DATABASE wordpress;

Create a new user, which will have access to this database only; its username will also be wordpress:

1

CREATE USER wordpress;

Set the password to the user wordpress to be VeryHardToFigureOut2013! (use your own, but make it hard to guess or just generate it randomly as suggested before) :

1

SET PASSWORD FOR wordpress = PASSWORD("VeryHardToFigureOut2013!");

Grant user wordpress all permissions on its database of the same name:

1
2

GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'VeryHardToFigureOut2013!';
FLUSH PRIVILEGES;

And now you can log out from the session by typing:

1

exit

I usually try to log in immediately afterwards with the username/password just created, to be sure everything is fine.

Next, it’s configuration time! WordPress will do pretty much everything on its own, but first we need to let Nginx become aware of our new site.

Open /etc/nginx/sites-available/mydomain.conf and type the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

map $http_host $blogid {
 default 0;
 mydomain.com 1;
}
server {
 server_name mydomain.com;
 root /var/www/wordpress;
 access_log /var/log/nginx/mydomain.com-access.log;
 error_log /var/log/nginx/mydomain.com-error.log;
 include conf.d/restrictions.conf;
 include /var/www/wordpress/nginx.conf;
 include conf.d/wordpress-mu.conf;
}

We’ll get into this later.

1
2
3

cd /etc/nginx/sites-enabled
ln -s /etc/nginx/sites-available/mydomain.conf
touch /var/www/wordpress/nginx.conf

Note that the last command is a requirement for W3 Total Cache (that file has to exist and be readable by the webserver’s user).

Finally, to make sure all this is readable by the webserver, do

1

chown -R www-data:www-data /var/www/wordpress

Running the WordPress self-installer

Go ahead and let WordPress create it.

Click on Let’s Go:

Note that the database host is: localhost:/var/run/mysqld/mysqld.sock. This will get WP to talk to the database via the Unix socket which is set up for MySQL by default, and, as said, totally avoid any TCP-based network connections.

If all goes well, you should be able to get to the familiar steps below:

If not, two things might be wrong. The first is that our “unusual” MySQL setup is not properly configured. The second one is that somehow one password or setting was written wrongly; just go back and fix it. Remember not to use the “admin” name for the Super Administrator: as said, the latest BotNet attack on WordPress sites looked specifically for “admin” and tried to crack its password.

After that, you should be able to login; WordPress is still running in “single site” mode. Now to the next step!

Defining Multisite

To enable WP in Multisite mode, you need to open /var/www/wordpress/wp-config.php with your favourite text editor. If you have done this before, it should be easy. Above the bit that says:

1

/* That's all, stop editing! Happy blogging. */

Add the following lines:

1
2

/* Multisite */
define('WP_ALLOW_MULTISITE', true);

Refresh your browser, and you should have a new option under Tools > Network Setup:

For this tutorial, I will be setting it up as separate sub-domains. There is a reason for that — the Nginx rules later will be a bit easier. At this point, if you press Install, WP will do some validations and probably return an error about a missing “wildcard domains”. Don’t worry. What matters next is that wp-config.php needs another change. As you can see, WP “assumes” you’re running under Apache, so we will pretty much ignore step 2, and just add the prompted lines on step 1 to wp-config.php:

1
2
3
4
5
6

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'mydomain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Remember, this will come below the line saying define(‘WP_ALLOW_MULTISITE’, true); but before the line saying 

1

/* That's all, stop editing! Happy blogging. */

You will need to login again, but that’s it, your WP Multisite install is pretty much finished.

Adding plugins

We will want at least W3 Total Cache. I will assume you’re familiar with the plugin installation procedures, so I won’t go into much detail here. Go to My Sites > Network Admin > Dashboard and then choose Plugins > Add New, search for W3 Total Cache, install it, and set it to Network Activate. One of the great features of W3TC is that you can configure it for all sites in a multisite environment at once, and that’s exactly what we want to do here.

At this stage, you’ll probably be adding all your favourite plugins. I’m personally a fan of Jetpack, since it includes so many useful things like Akismet anti-spam measures, statistics, Photon to cache your images on WP.com’s cloud for free (which is very useful to keep traffic off your website!), and a reasonably good system for managing all your social networking integration. And due to the many security incidents with WP, I tend to install at least Limit Login Attempts.

I’m also very fond of Human Made Limited‘s pair of plugins, WP Remote and BackUpWordPress. The first will allow you to centrally manage all your WP blogs (even if hosted on different servers!) for free, making sure you keep them always up to date (core, plugins, and themes), and never forget to upgrade them all. BackUpWordPress is probably one of the simplest free backup plugins which will backup both the content and the database, and, in my experience, it’s one of the easiest to use if you wish to migrate from one server to another — which is always a mess under WordPress.

As a bonus, when both are installed, you can easily retrieve your backups from WP Remote’s backoffice, from any site. So if you’re administering a lot of WP blogs on different servers, both are a must. Since they’re both free, simple to use, and do their job right, there is little reason not to install them, even though there are better (paid) alternatives around. But, of course, this is all up to you!

What we’ll definitely add is WordPress MU Domain Mapping. There are deep theological discussions about why this isn’t part of the WordPress core. Basically, you have two options of having a network of sites: either they’re all under the same domain, but on different directories (e.g. mydomain.com/site1, mydomain.com/site2, and so forth), or under different subdomains (site1.mydomain.com, site2.mydomain.com). But in most real scenarios, what you have is totally different domains for each site, and you want the ability to manage them all together.

This is the job for WordPress MU Domain Mapping: you will tell it to point a certain domain — say, myotherdomain.com and anotherdomain.com— to specific sites on your install. Obviously you will need a little help from Nginx. The purpose of the next steps is to add these two sites, and make sure they’re properly pointed to the right place, and that Nginx can correctly forward the requests to the right place. All of that while still making sure that W3 Total Cache is working!

First, let’s confirm that W3 Total Cache likes the configuration so far. While still on the Network Administration panel, follow the link on Performance > Dashboard and click on Check Configuration. If all goes well, you should have something like this:

The important thing here is that Nginx should have been detected. You will also see that we have PHP with the Alternative PHP Cache (APC) module enabled.

Now go to Performance > General Settings and enable at least Page Cache, Minify, Database Cache, Object Cache (and Browser Cache should be on by default). For the method use Opcache: Alternative PHP Cache (APC). Save the configuration by clicking on Save All Settings. W3TC should tell you to Empty the Page Cache, so go ahead and do that.

If all went well, W3TC has done some under-the-hood magic for you. If you now open the /var/www/wordpress/nginx.conf file, you should have a surprise: W3TC will already have filled it on your behalf! (If you have an empty file, or got an error, it means that you have either forgotten to touch this file before or it doesn’t have the right user/group ownership or permissions; just take a look again if it’s set to www-data:www-data and is writable).

Fine-tuning W3TC is more an art than a science, although it has become quite easier on recent versions. Page Cache should be fine by default. Minify depends on a lot of things and is probably the trickiest bit. If you’re using CloudFlare, and are as lazy as I am, just let CloudFlare handle minification for you. If you add the login data for CloudFlare on W3TC, the latest versions will communicate with your account, correctly identify that it’s set to auto-minify things, and disable those options on W3TC.

It’s always better to allow CloudFlare to waste CPU cycles on minification, instead of spending your precious resources on that. However, I have a particular instance of a website where CloudFlare’s minification does not work well, but W3TC’s does. This will depend a lot on the theme and the plugins you’re using, and it’s great to know that you have this option.

If you’re not using CloudFlare, try the automatic settings, and on Performance > Minify enable at least HTML & XML (with Inline CSS minification and Inline JS minification), JS and CSS. This should also combine all JS and CSS automatically, which will give you extra points on Google PageRank.

I usually don’t mess around with Database Cache and Object Cache, but I go wild on Browser Cache and turn everything on except Prevent caching of objects after settings change and Do not process 404 errors for static objects with WordPress (because I like my own personalized error pages!).

Note that W3TC is a plugin with a very active development cycle. This means that many options are constantly being added and/or removed, specially if they’re a bit obscure or hard to understand what they’re doing. If you’re reading this tutorial many years after it was written, I would recommend you to check a recent W3TC-specific tutorial, to see what options have changed and what they do.

Now let’s install the WordPress MU Domain Mapping plugin. Remember, this has to be network activated to work. Then go to Domains > Domain Mapping and set the checkboxes under Domain Options like this:

Adding two new sites

So when this tutorial is finished, you should have a network of three sites: mydomain.com, myotherdomain.com and anotherdomain.com. What we’re doing is the following mapping:

• mydomain.com points to the overall installation, the default site, i.e. mydomain.com
• myotherdomain.com points to site1.mydomain.com
• anotherdomain.com points to site2.mydomain.com

Firstly, you need to go to your DNS provider and add records for all that. We’ve seen how mydomain.com was already configured to point to your IP address. Now you will need to point site1.mydomain.com, site2.mydomain.com, myotherdomain.com and anotherdomain.com all to the same IP address (Nginx will handle the rest).

Once DNS has refreshed (and you can ping those domains and make sure they’re all pointing to the correct IP address — always the same one!) we can start adding the two sites. This, of course, is what you can do from Network Admin > Sites > Add Site. On Site Address put site1; under Site Title use myotherdomain; and the admin email could be the same as for the main site (myname@mydomain.com in this tutorial). Similarly, for site2, use anotherdomain for the title, and the same email address once more.

Let’s get it all properly mapped. Go to Settings > Domains. You will see the following message popping up:

1

Please copy sunrise.php to /var/www/wordpress/wp-content/sunrise.php and ensure the SUNRISE definition is in /var/www/wordpress/wp-config.php

First, let’s copy that file (this is the handler for domain mapping):

1

cp /var/www/wordpress/wp-content/plugins/wordpress-mu-domain-mapping/sunrise.php /var/www/wordpress/wp-content/

Now edit /var/www/wordpress/wp-config.php and add

1

define( 'SUNRISE', 'on' );

just above of:

1

/* That's all, stop editing! Happy blogging. */

Go to Settings > Domains again, now it should show:

We’re ready to add our own mappings. Sadly, the panels for WordPress MU Domain Mapping are not very user-friendly — we need to figure out the Site IDs on our own.

Fortunately, this is not too hard, since they’re listed on the Sites > All Sites panel:

Now when you hover with the mouse over the Domain name, it should give you it’s ID, with an URL like this:

1

http://mydomain.com/wp-admin/network/site-info.php?id=1

Notice that there is an extra column, called Mapping, which was added by WordPress MU Domain Mapping. It starts as being blank. If you have followed this tutorial, and haven’t added and then deleted any domains, the logic is simple: the first site is ID 1, the second 2, and so forth (but as soon as you add and delete domains, this can quickly get out of order).

So these are the assignments we wish to do:

• mydomain.com uses ID 1 (default — no need to add it)
• myotherdomain.com uses ID 2
• anotherdomain.com uses ID 3

If the options have been correctly set, it should now look like this:

And, under Sites > All Sites, you should have:

WordPress is now configured to handle the domain mapping, but we have to let Nginx know about it too!

So let’s get back to opening /etc/nginx/sites-available/mydomain.conf. You will have noticed the map directive at the top. What we’re going to do is to pretty much replicate here what we have setup via WordPress:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

map $http_host $blogid {
 default 0;
 mydomain.com 1;
 myotherdomain.com 2;
 anotherdomain.com 3;
}
server {
 server_name mydomain.com myotherdomain.com anotherdomain.com;
 root /var/www/wordpress;
access_log /var/log/nginx/mydomain.com-access.log;
 error_log /var/log/nginx/mydomain.com-error.log;
include conf.d/restrictions.conf;
 include /var/www/wordpress/nginx.conf;
 include conf.d/wordpress-mu.conf;
}

Restart nginx with:

1

sudo service nginx reload

And now it’s testing time! If all went well, you should be able to view http://myotherdomain.com/ and http://anotherdomain.com/ on your browser and they will be properly redirected.

Final note: How to test all the above before going into production?

Following the above tutorial requires owning at least three domain names which you’re not using for any purpose, and, of course, adapting every line of code to reflect your real domain names. But you might wish to do some testing first to be sure that you have the configuration right, before you move to a production environment.

Here is a neat little trick that you can use: using the HOSTS file for creating “fake” domains. Most computers are pre-configured to read static IP address assignments from their HOSTS file first, and only then hit the DNS nameservers. All you need to know is your server’s IP address.

You should do this on two places: on the server where you’re running your WordPress installation and on your desktop computer. Under Linux/Mac OS X, the file is under /etc/hosts, so with sudo nano /etc/hostsyou should be able to edit it and add the following line at the bottom:

1

192.168.0.1 mydomain.com site1.mydomain.com site2.mydomain.com myotherdomain.com anotherdomain.com

where, of course, you should replace 192.168.0.1 with your server’s real IP address. Under Windows, it depends a bit on what version you’ve got; it’s usually under C:\WINDOWS\system32\drivers\etc\hosts. Use something like Notepad to edit it (don’t use Write or Word, since it will add lots of useless formatting and break everything!).

After you’ve done the changes, you will very likely need to exit your browser and launch it again (because most browsers will cache DNS).

There are a few caveats, though: since you’re not using “real” DNS, your WordPress installation will not be able to use any plugins that require a XML-RPC call to your server. A typical example is Jetpack, which really requires “real” addresses, because it contacts your server directly to do its magic.

However, almost all other plugins — even the core auto-update feature which needs to contact the “outside” world — don’t have that restriction. CloudFlare may also have a few issues: you have to be careful not to let CloudFlare clear the cache, or it will be caching the wrong site instead! The best is to turn it off on your development environment and just activate CloudFlare again when you move the site to the production environment.

photo credits: aussiegal, sachinpurohit, rdecom,
world map from BigStockPhoto

Related posts:

1. Nginx and WordPress µ 2.6 After googling like a madman and trying to learn russian...
2. How to Setup Your Own Nginx Powered WordPress Server Learn how to set up Nginx on Ubuntu!...
3. 10 Plugins to Make WordPress Blazing Fast Check out these 10 great plugins for speeding up WordPress...