Do It With WordPress

Useful Configuration Tweaks for wp-config.php

Dave Clements — Mon, 06 Feb 2012 15:00:48 +0000

wp-config.php (as you may guess from the name) is a configuration file that allows you to define all the important settings for WordPress. When you first install WordPress, you’ll upload the default wp-config-sample.php, which you’ll need to modify and rename. From then on, you can go on editing wp-config.php.

Keep wp-config.php secure

There’s two ways of achieving this – you can either move the wp-config.php file out of your public_html folder, into your hosting’s main root folder above public_html. This way, it’s out of reach to the public. Alternatively, you can use .htaccess to deny access to it. This involves pasting the following into .htaccess:


 Order Allow,Deny
 Deny from all

The important tweaks

Most of the important setup information that goes in wp-config.php I have covered in other tutorials, so I’m going to link you to those tutorials in case you haven’t set those things up yet:

The personalised tweaks

Beyond the important tweaks above, you have a bunch of other tweaks that are more like personalised options, that will dictate how your site should be run, particularly behind the scenes.

Set your homepage

You can override values set in your General Settings by defining the Site URL and the Blog URL in wp-config.php. Use the following definitions:

define('WP_SITEURL', 'http://example.com/');
define('WP_HOME', 'http://example.com/wordpress');

Change Autosave Interval

By default, WordPress saves your progress every 60 seconds, but you can change that using this definition, where the value is in seconds:

define('AUTOSAVE_INTERVAL', 240 );

Configure Post Revisions

WordPress allows you to keep the last several copies of a WordPress post, so that if you make a mistake, you can revert to an older version. You can either disable this feature (to reduce your database size) or set the maximum number of versions WordPress should keep:

define('WP_POST_REVISIONS', 3);
define('WP_POST_REVISIONS', false);

Debug mode

If you’re experiencing issues with your site, or you’re developing a plugin or theme, you might find it useful to turn on the debug mode, to highlight any issues. It defaults to false, so you only need to specify it if you want to use it:

define('WP_DEBUG', true);

Increase PHP Memory Limits

A frequent issue that some WordPress users encounter is that they run out of PHP memory when doing memory intensive tasks. You can define a memory limit for WordPress using the following definition, changing the value to your preferred maximum limit:

define('WP_MEMORY_LIMIT', '128M');

Change the Language WordPress Uses

Sprechen Sie Deutsch? ¿Hablas español? If English isn’t your first language, you can set a different language for WordPress to use. Use one of these language codes and define it in wp-config.php:

define('WPLANG', 'de_DE');

The .mo file will need to exist in wp-content/languages for this to work. If it’s somewhere else, you can define the folder that the language file is in:

define('WP_LANG_DIR', $_SERVER['DOCUMENT_ROOT'].'wordpress/languages');

Override default permissions

If your host is setting your file permissions too restrictive, or you just need to change them from the WordPress default, you can define what they should be for files and directories with these definitions (these are the recommended settings by the way):

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

Specify FTP and SSH information

Depending on your host’s setup, WordPress may ask you for FTP information whenever you try and update/upload something. or you may just prefer to use SSH instead of FTP. So you can use all of the following definitions to define, in order:

FileSystem Method – either direct, ssh2, ftpext or ftpsockets
FTP Base – where your WordPress installation is located
Content Directory – set the location of your wp-content folder
Plugin Directory – set the location of your plugins folder
Public Key – the location of your SSH public key
Private Key – the location of your SSH private key
FTP User – the FTP or SSH username
FTP Pass – the password associated with the FTP User (not needed for SSH public key authentication)
FTP Host – the host and port of your FTP/SSH server (FTP port defaults to 21 and SSH to 22 if not specified)
FTP SSL – use SFTP, if supported by your server

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/path/to/wordpress/installation/');
define('FTP_CONTENT_DIR', '/path/to/wp-content/');
define('FTP_PLUGIN_DIR ', '/path/to/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org:21');
define('FTP_SSL', false);

Take the Trash Out

By default, WordPress permanently deletes any post marked as trash after 30 days, but you can specify the number of days it should wait before doing this. Alternatively, you can disable the trash feature, by setting the duration to 0.

define('EMPTY_TRASH_DAYS', 60 );

Allow Database Repairs

WordPress has a built-in feature that enables automatic database repair in case the database gets corrupted. If you encounter problems with your database, try setting this definition:

define('WP_ALLOW_REPAIR', true);

Limit Plugin/Theme edits and installations

If you want to remove the ability for users to install or edit themes or plugins, you can use the following definitions to take care of that. The first will disable the editors, but still allow installations and updates of themes/plugins, whereas the second definition will disable all of these functions:

define('DISALLOW_FILE_EDIT',true);
define('DISALLOW_FILE_MODS',true);

There’s a few more definitions that you can set, but they’re much more obscure and chances are that you won’t need them. Have you tricked out your wp-config.php file now? And perhaps more importantly, have you secured it?

Specify how your WordPress Site Should be Viewed on Mobile Devices

Dave Clements — Thu, 02 Feb 2012 14:00:10 +0000

With the rise of the smartphone, readers are increasingly turning to their mobile devices to read your content. So, you want to be sure that it’s being seen the way you intend for it to be seen.

One way that you can make sure of this is to use the Viewport metatag. It is a standard that was developed by Apple at the introduction of the iPhone. It is now supported by most mobile devices, including iPhone, iPad and Android.

It allows you to specify what zoom level your site should be set to when it is loaded, how far in or out a user can zoom and even to disable zooming if you wish.

For example, to set the width of your site to the width of the device, load the site with a 1.0x zoom and allow scaling between 0.6x and 2.4x, then you would use a meta tag like this, which goes in your head section. You can either put it there manually in header.php, or you can use a function to place it there, which I’ll show you later:

Another example, to set the width of the device to 640 pixels, the height to 960 pixels and disable zooming, would look like this:

There’s more specifics on the details of the viewport tag on Apple’s developer website. It also has a few other tweaks that you can make, such as turning the status bar black when viewing your site, or running your site in full-screen mode by using the following meta tag:

If you want to use a function to add these to your header instead of messing with your theme files, then put something like this into your functionality plugin:

function diww_viewport_meta_tag() {
	echo '';
}

add_action ( 'wp_head', 'diww_viewport_meta_tag' );

Allow Users to Create Posts on your Site with Formidable Pro

Dave Clements — Mon, 30 Jan 2012 13:00:28 +0000

In the process of creating a new site, I realised that I needed to allow people to submit information from the site and turn that information into a new post, so that it could then be displayed on the site, without me having to manually copy the information from an email into a new post.

I went in search of some solutions and while I had used TDO Mini Forms before, it is no longer in development and was not very user friendly to configure anyway. I was left to decide between Gravity Forms and Formidable Pro. I ultimately decided on Formidable Pro, not least because it was cheaper (and still did everything I wanted) and was recommended by a couple of people. So I bought the plugin and set about configuring it.

Create the form

In this example, I’m going to create a form to allow people to submit stories to be shown on the site under a specific category. So in my case, I created a field for the story title (which will become the post title), the user’s name and email address, and then the story itself. I set all of these to be required fields, to ensure that nothing is omitted.

For the story title field, I selected the Post Field to be Title (which means that the title of the post will be whatever is submitted in that box).

I also need to set which category the post is going to be created in, but since I don’t want people to be able to edit this, I’m going to create a hidden field. I created a Multiple Selection field and then set the Post Field to be Taxonomy and then chose Category as the Taxonomy type. Now if you update the form, it will present a list of your categories. You can now preselect the category that you want the posts to be put in and select Admin Only under Field Type, so that people won’t be shown that field, meaning that your selection of categories will be unchangeable by users.

Then I created the story field, setting the field type to paragraph, to give the user plenty of space to write down their story and also set the post field as Post content, so that everything written in this field will become the main post content.

Now you need to create another hidden field to set the post status. I recommend setting the post status to draft so that you can review everything before it goes live on your site. So create a drop-down field and set the Post Field to Post Status. Once you save the form, it will give you the option to preselect the post status (which should be Draft). Be sure to set the Field Type to Admin Only, so that users can’t change this to published to circumvent your review.

You can now create text fields to collect the user’s name and email address, using validation to confirm that the email address is a valid address.

After you’ve got all of the fields in place, you can set up form notifications, so that once an entry is submitted, you get an email sent to you so that you know to review it on your site. You can also send an autoresponder to the submitter.

Once the form is complete, you can copy the shortcode from the top right-hand corner and paste it into the page where you want the form to appear on your site.

Your experiences

The options for what you can do with Formidable Pro are quite limitless. How have you used forms like this to collect and display information from your readers? I’m always interested to hear your experiences. Let me know in the comments.

How to Set Up Domain Mapping for WordPress Multisite

Dave Clements — Mon, 23 Jan 2012 13:00:03 +0000

So you’ve gone through setting up WordPress Multisite, and now you’re ready to start setting up new sites in your network. Only trouble is, you want to use unique domains for your sites instead of using subdomains of your main installation. Well, with a little extra effort, it’s entirely possible.

Install the required plugin

There’s an excellent plugin that will do most of the hard work for you. Install the WordPress MU Domain Mapping plugin and Network Activate the plugin.

Before you proceed any further, there’s a couple of things that you have to do manually. Access your site’s installation, either using FTP or your hosting Control Panel and go to wp-content/plugins/wordpress-mu-domain-mapping/ and locate the sunrise.php file. You must move this file up two levels, to the wp-content folder.

Once you’ve done that, find your wp-config.php file and add the following definition. Add it below your previous multisite rules (i.e. above the “Stop editing” line):

define( 'SUNRISE', 'on' );

Configure the plugin

Now your plugin is correctly installed and when you head to the Network Admin area you’ll notice a menu under Settings called Domain Mapping. Click on that so that you can configure the plugin.

The main thing you need to be concerned with is setting the IP address of your server. To find this, log in to your hosting cPanel and on the main page, you should be able to see the IP address of your server in the information on the left-hand side. If you can’t find the IP address, you can get in touch with your host, or use one of many available free tools to convert the web address to an IP address.

If you fill out the IP address, you can ignore the CNAME field. Then, the remaining options are as follows:

Remote Login – Means that logging in to one site will log you in to all sites.
Permanent Redirect – This will create a 301 redirect on your subdomain (as opposed to a temporary 302 redirect) – highly recommended if the domain mapping will be permanent.
User Domain Mapping Page – Creates a new menu in each site which allows that site’s users to map their own domains (instead of being controlled by the network’s Super Admin only).
Redirect administration pages – Means that all administration pages will be kept on the original site’s domain, instead of on the mapped domains.
Disable primary domain check – Means that multiple domains pointing to a single site will be treated as separate sites, instead of redirecting all domains to the noted primary domain (not recommended).

Map domains to your network sites

Now you’re ready to set up the domain for your new sites. You should have already created the site that you’re wanting to map your domain to. At the moment, it will just be a subdomain of your main site – it doesn’t have to be set up or looking perfect – it just has to exist.

Once you’ve purchased your domain, make sure that you set the nameservers for the domain to your hosting account’s nameservers. Then, go to your hosting account cPanel (which all good hosts, including my recommended HostGator, should have) and find the Parked Domains option under Domains.

Once in there, add your new domain as a parked domain, making sure that the document root shows as the same folder as your WordPress installation (probably /public_html). If you can’t do this (because you don’t have cPanel for instance), you need to set an A record on your new domain that points to the IP address of your hosting server (which you found out earlier).

Now is the final step. You’ll need to know the “Site ID” of the site you want to map the domain to. If you click on Sites > Sites in the Network Admin, and click on the name of the site (as if to edit it), the URL will include the site ID. It will look something like this (where the Site ID is 2 in the example):

http://www.theukedge.com/wp-admin/network/site-info.php?id=2

Now back in your Network Admin, go to Domains under the Settings Menu. You’ll see a section for adding a new domain, with three fields: one for the site ID, which you just found out, the domain name and an option whether to set the domain as the primary domain for the site. This is because you can set more than one domain to point to a single site, so you want to specify which one should be the site’s primary domain.

Once you save that, with any luck (and assuming that DNS changes have propagated), if you go to your new domain in a web browser, you should find yourself at your new site.

I’ll grant you that it is a little bit fiddly, and it would be nice if WordPress would bring this into the core and make it a bit more of a fluid process, but once it is set up, you never need to look at it again; the plugin will keep serving up the right site at the right domain.

Did you manage to get through the setup process? Did you encounter any problems? If you need any help getting through this process, you can always ask a question here, or hire me to do it for you.

How to Install & Setup WordPress Multisite

Dave Clements — Mon, 16 Jan 2012 13:26:12 +0000

Since version 3.0, you have natively had the option to activate WordPress Multisite, which allows you to run as many sites as you want from a single WordPress installation (whereas previously it was one website per WordPress installation).

If you run a lot of sites, or you have lots of clients that you keep websites for, it can be a lot of maintenance to go to each one individually and update them on a regular basis.

With WordPress Multisite, you can update all the plugins and themes with just one click, which is a huge time-saver. I currently run a network of about 10 sites and it makes it so much easier to keep everything updated. You could have a much larger network of sites and it would be no more difficult to update them all.

The benefits of WordPress Multisite are massive and I thoroughly recommend it to anyone who wants to run more than one site, unless there’s good reason for keeping the sites separate from one another.

If you find this tutorial a little too daunting, you can always hire me to do it for you. If you’re comfortable fiddling with code, here’s how to do it…

Back up everything!

You’re about to be making some significant changes to your core files and in particular, your database, so be sure to take a thorough backup of both even if you automate your database backups.

Allow multisite installation

To avoid dangerous mistakes, you have to intentionally enable the option to even install multisite. Fortunately, it doesn’t require much of you. Hunt down your wp-config.php file which should be in the root of your WordPress installation, find the “stop editing” line and insert the following line just above it, like so:

define('WP_ALLOW_MULTISITE', true);

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

Setup the network

Now when you refresh your WordPress admin, you’ll see an additional option under the Tools menu called Network Setup. Head there. You’ll be presented with a few options, like what to call your network and the email address of your Super Admin (see A Quick Guide to User Roles). You may also be presented with the option to choose between sub-directory or subdomain installation. Unless you desperately want a subdirectory installation, I would strongly suggest subdomain installation. Fill the options out and hit the big old install button (but only if you promise me that backed up your site first).

Enable the network

Now that your database is ready to get the network going, you need to edit a couple more files to make the network active. Fortunately, the clever WordPress monkeys made it very explicit and easy for you to understand.

After setting up the network, you should be presented with a page that shows you a few blocks of code. Enabling the network involves adding some code to two files: wp-config.php and .htaccess, both of which should be in your website’s root folder. The code for your wp-config.php will look something like the code below:

define('WP_ALLOW_MULTISITE', true);
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.theukedge.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

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

Add a wildcard subdomain

At this point, you should also enable a “wildcard subdomain” in your hosting account, which will allow WordPress to use whatever subdomain it needs to create all the different sites. I’m going to show you how to do this in cPanel, since this should be available to most of you (especially if you use the awesome HostGator).

Once logged in to cPanel, hit the Subdomains icon. You’ll then have a small form that will enable you to add a new subdomain (above any subdomains that might already exist). Create a new subdomain of * on the domain of your WordPress master site, setting the document root as public_html, or wherever the root of your website is, if it’s not there.

Once you’ve successfully done that and added all the code that WordPress asks you to, you’ll need to login again. There should be a link at the bottom of the Network setup page. Click there and log back in, where your new multisite-enabled site will be waiting for you.

Tweaking your settings

How you set up your network will largely depend on how you want to run it. For example, on my network, I don’t want to allow anyone to be able to create their own site, though that is an option if you want to do that. I also don’t want to limit what kind of files can be uploaded (since I’m in charge of all the sites), or what size they can be, though if you have a more open network, you may want to put some of those restrictions in place.

To modify your network settings, you’ll need to go to the newly created Network Admin area; your original WordPress site will continue to have it’s own admin area, but there will be a new overarching Network Admin Area where you can install themes, plugins and add new sites and users from. To access it, you can go to the admin bar and find it under the My Sites menu. You can also go to yourdomain.com/wp-admin/network to get to the Network Admin area.

Once you’re at the dashboard, you can find the network setup page under Settings > Network Settings. Just have a good look through at everything and set up the options as you see fit for what your network needs are. You can of course change them if they are too strict or lax in the future.

If you’re going to disable new site registrations, so that only a Super Admin can create new sites, you might want to add another declaration to your wp-config.php file, just below all the ones you pasted earlier. This will redirect people to a specified site if they try to access a site that doesn’t exist (presumably your master site). For example, since I have the following declaration in my wp-config.php file, anyone trying to access balloons.theukedge.com, which does not exist, will be redirected to The UK Edge:

define( 'NOBLOGREDIRECT', 'http://www.theukedge.com');

Adding a new network site

Now that your network is all set up, you’ll probably want to add your first network site. Doing so is a fairly simple process. Go to the Add New option under the Sites menu in your Network Admin area.

The process of adding the site is incredibly simple. Just three pieces of information are required of you; the site address, which is where your site will be accessed from. For example, if I was going to create a site at parties.theukedge.com, I would simple insert parties in this field.

You’re then asked for the Site Title and finally the Administrator’s email. If you want to add yourself as the site’s admin, just enter the same email address that you used in your existing profile. Alternatively, you can set it as someone completely new.

Once you click on Add Site, it will create the site for you and you are then given the option to go to the Dashboard, or Edit the Site. Simple huh!?

How about using custom domains for my new sites?

As you’ll have noticed, everything up to this point has allowed you to create new sites as subdomains to the Network Master Site, where you installed Multisite. But what if you want to use custom domains for your new sites? For example, I have WordPress Multisite installed on theukedge.com, but Do It With WordPress is a network site from that installation, even though it’s domain (doitwithwp.com) is not a subdomain of theukedge.com.

Well, I’m going to write that up in a separate tutorial, which will come your way soon. In the meantime, I’m going to point you in the direction of the tutorial that I learnt from to set up “domain mapping”. Please check the WordPress Multisite Domain Mapping Tutorial by Otto.

Problems? Questions? Requests?

So, how did it go for you? Did you get it set up successfully? Do you have any questions that I didn’t cover in this tutorial? Or was there something that you need me to help you with? Let me know in the comments.

Speed Up WordPress with W3 Total Cache

Dave Clements — Mon, 09 Jan 2012 13:00:38 +0000

W3 Total Cache is probably the most useful WordPress plugin you can own (save maybe WordPress SEO by Yoast) and it still baffles me that it is completely free. For the grand price of zero, you get a plugin which will cache your pages, objects, database queries, pair up with a CDN and more. I am still of the opinion that there is not a single WordPress site that could not benefit from installing it.

So with that said, get it installed and then come back here for some guidance on how to set up its myriad of configuration options.

General Settings

When you install and activate the plugin, you’ll get a new icon the menu of the left hand side of your admin area. Click on that icon to bring up the general settings page for the plugin. You’ll want to start here.

Bear in mind that this page is where you “turn on” several of the functions of the plugin and it may be worthwhile keeping them disabled until you have configured the individual components and then returning here at the end to turn everything on.

You may be prompted to allow W3 Total Cache to install lines of code in your .htaccess file upfront and throughout the configuration process. Make sure you have a backup first, and then have it auto-install the code.

Page cache

The page cache creates static pages from your dynamic content and serves them up to your users, instead of creating pages on-demand, which massively reduces your server load. You’ll likely find that the only option you have here is to select Disk: Enhanced, which is more than likely adequate for what you need.

Minify

Minify is the process of removing line breaks, comments and spaces from CSS and HTML files to reduce their size (thus delivering them quicker to the user). Again your only option may be Disk, which it is for me, but that will serve you well. You should be able to select Auto for your Minify Mode and the default settings for all the minifiers unless you have reason to choose something else.

Database cache

The database cache saves the results of database queries instead of looking to the database every time the request is made, which significantly reduces the impact on your SQL server. Since WordPress is entirely database driven, nearly every page will make several requests to the database, such as displaying your 10 most recent posts on the front page, or recent comments in your widgets. Use the Disk option.

Object cache

The object cache stores numerous objects from the database. It may or may not speed up your site, depending on the speed of your disk. You can do a comparison before and after turning it on to see whether there is a reduction in load time and if there isn’t, you might as well leave it turned off. If you are to turn it on however, use the Disk option.

Browser cache

The browser cache works by “telling” your visitors’ browsers how long to keep using the same version of an object. For example, it is unlikely that you will change an image once it has been uploaded, so there is no sense in downloading the image every time a user visits a page – it can just keep the original version and use it over and over again. This will cut a big chunk out of the amount of data needed to download every page, since much of it can be stored on the user’s computer after the first visit. There’s no options here, but you’ll need to enable it here once you’ve set the specific settings in a short while.

CDN

CDN stands for Content Delivery Network, which hosts static parts of your site on servers all over the world so that users can download them from their closest server, instead of potentially requesting it from halfway across the world, reducing latency and load on your server. They’re fairly cheap to use and I recommend it. I personally use Amazon Cloudfront, though there are a number of alternatives supported by W3 Total Cache. I wrote a tutorial detailing how to set up Amazon Cloudfront as your CDN with W3 Total Cache, which will be useful for guiding you through that process.

Varnish and Cloudflare

You can generally ignore these two sections, unless you know that you have a need for them.

Miscellaneous settings

With the miscellaneous settings, I recommend verifying the rewrite rules; I have found that on numerous occasions, other plugins that interfere with .htaccess can mess up the W3 Total Cache settings, so enabling this will tell you when there’s a problem that needs resolving. Else, your site could be running with several parts of the plugin not in effect and you wouldn’t know it.

I also recommend using the Google Page Speed dashboard widget for tracking your page speed.

Also, consider making a donation through the support section. I don’t blame you for wanting to wait to see the results, but if you’re impressed, consider a small donation; support WordPress developers, especially when they work for free.

Page cache settings

Now move on to the page cache settings page. Here is where you set the specific settings for how the page cache should operate. Here’s the settings that I recommend:

General

Enable caching of the home page, SSL requests and requests only for your domain. Also check the box to disable caching pages for logged-in users. I don’t recommend caching feeds because if you make changes, you want it be reflected in your RSS feed, which I have had issues with before, when I had this option enabled. I also don’t recommend caching 404 pages because they shouldn’t be used very often and they will return an error code of 200 (OK) rather than 404 (not found), which is undesirable, so they’re not worth caching.

Advanced

For most users, you won’t really need to touch the Advanced settings, but you can reduce the Garbage Collection Time, which is how long the cache holds a version of a page before building a new one (the default 3600 seconds – 1 hour should be sufficient). You can also set specific user agents (like bots) that shouldn’t be served pages from the cache, or set specific files which should never be included in the cache.

Cache preload

These options allow the cache to be pre-built (i.e. it builds the pages in the background rather than waiting for someone to view a page and build it on-the-fly. This helps to spread your server load more evenly and reduces load times for those who are trying to view a page that hasn’t yet been viewed, or has expired in the cache. I use an interval of 600 seconds and build 10 pages at a time. You’ll need to adjust this based on your server and the number of pages on your site. If you have 1000 pages and you’re only building 10 every 10 minutes and your cache expires every hour, then you’ll only be able to build 60 out of your 1000 pages before it needs to start over again. Be sure to insert your sitemap address and enable to the preload function.

Purge policy

The purge policy dictates which pages should be rebuilt in the cache when a new post is published. For example, your front page likely has a list of your most recent posts, but if you don’t purge it from the cache when you publish the post, it won’t show on the front page until the cached page expires and it gets rebuilt with the new information (your new post). For me, I purge the home page, post page and blog feed (all feed types). The other pages are so infrequently used that it wouldn’t really matter if they have slightly outdated information – this might not be the case for busier sites.

Minify settings

In the General section, enable the Rewrite option and disable minify for logged-in users. Also set how you want to notified if there’s a problem with minifying your code.

HTML & XML

I recommend enabling all aspects of HTML minifying. This includes leaving the box for not minifying feeds unchecked (so that feeds get minified too).

JS

Some people report issues with minifying Javascript, so use this with caution. I’ve enabled it and it doesn’t appear to cause issues with my site. All you need to do is check the box to enable it; you can leave the other five options unchecked, unless you only want to combine Javascript files that appear within certain portions of the page (such as the header, or footer).

CSS

For the CSS section, you want to be sure to set it up as I’ve shown in the image, by prcoessing @import files (these are files that are imported into other CSS files by using the @import function – we want to minify those as well) and removing comments and line breaks. Leave Combine only unchecked, because we want to take it further than just combining the CSS files (we want to minify them as well).

Advanced settings

Again, you don’t need to fiddle around too much with this. You can fiddle with the garbage collection time if you want something more or less frequent than the default 86400 seconds (1 day) or specify rejected user agents or pages that shouldn’t be minified.

Database cache settings

In the general section, make sure that the option to not cache queries for logged-in users is checked. You want to be sure to have the latest version of your site every time it’s loaded.

Advanced

Again, there’s not too much to fiddle with here unless you have good reason to. As with other caches, you can set garbage collection times, expiration times and pages that shouldn’t be cached.

Object cache settings

As I mentioned earlier, it’s debatable whether this will even do you any good, but if you do enable it, you can pretty much leave the default settings as is. Not much else to say on that one!

Browser cache settings

This section is a bit more important and involved. It tells visitors’ browsers how long to hold on to files it downloads. Here’s how I recommend setting it up:

General

Essentially, you want to ensure that you set every option for including information in the page header. However, you can leave the options for preventing caching objects after changing settings and not letting WordPress process 404s. It should look like it does in the image to the right.

CSS & JS, HTML & XML, Media & Other Files

All of these sections will essentially look exactly the same, making use of all the header information available. The only thing you’ll want to change is the expiration time in each section. I would set the expiration time for CSS and JS to 2,628,000 seconds (1 month), HTML and XML to 3600 seconds (1 hour) and Media & Other Files to 31,536,000 seconds (1 year). You can adjust these based on how frequently you think these types of files are likely to change on your own site.

CDN

The Content Delivery Network section will depend on your specific CDN provider, but I have already created a separate tutorial for setting up W3 Total Cache with a CDN (Amazon Cloudfront in the example). Regardless of your provider though, the long and short of it is that you want to serve as much static content as possible from your CDN rather than your own server.

Once you set up your CDN (if you’re going to use one), you can head back to the General Settings page and enable all the components that you’re going to use. Then log out (since some components have purposely been disabled if you’re logged in) and browse your site. It should be immediately apparent how much faster your site is, but you can also perform some tests using Pingdom Tools, which is very useful for showing your page load speed.

So, did you get it set up successfully? What settings did you tweak and why? Are you having any issues? Let me know in the comments!

2012 New Year’s WordPressolution

Dave Clements — Thu, 05 Jan 2012 13:30:27 +0000

It’s the New Year, a traditional time for resolving to make changes in our lives to better ourselves in the coming 12 months (and hopefully beyond).

Even though many of us stop going to the gym in about mid-February, there’s smaller changes that you can make in your life that are more manageable and realistic. Given that this blog is all about WordPress, it only seems fitting to write down a few “best practices” that you should try and adopt in order to make editing, managing and updating your blog a whole lot easier.

Stop using functions.php

It’s something that I mention frequently, but if ever you needed a kick up the bum to do this, now is the time. functions.php should be a file that is used by theme developers to define functions that manage and alter the way in which the theme appears and operates.

When we want to add or modify some functionality in our blog, we are often presented with snippets, which many people will tell you to put into functions.php, a habit which I want to help stop. This isn’t good because if you change or update your theme, any snippets you entered into functions.php will not be reflected in your new theme.

The better way to handle adding these code snippets is to use a functionality plugin. Do not be alarmed or overwhelmed; it’s actually very easy to create and you’ll be underway in about 10 minutes. Make the change now!

Edit theme and plugin files more appropriately

Once you start getting your feet wet in WordPress, you might start looking at your theme/plugin files and consider editing them to alter the appearance of your site slightly, whether it’s to add some social sharing buttons, or to add featured images to your posts.

There’s just a few tips that you should try and take on board which will help with managing your blog and keeping track of your edits:

Use comments to remove portions

Never, ever, ever delete code from a theme file or plugin file. Instead, use comments; this is a way of basically saying “ignore this bit”. If you’re editing a PHP file, you can comment out a section by using /* and */ to denote the beginning and end of your commented section. So for example, in the following section of code from my own functionality plugin, the snippet for delaying publishing to my RSS feed is disabled:


// Delay Publishing to RSS feed (disabled) //

/*
function publish_later_on_feed($where) {
 global $wpdb;
 if ( is_feed() ) {
 $now = gmdate('Y-m-d H:i:s');
 // value for wait; + device
 $wait = '5'; // integer
 $device = 'MINUTE'; //MINUTE, HOUR, DAY, WEEK, MONTH, YEAR
 $where .= " AND TIMESTAMPDIFF($device, $wpdb->posts.post_date_gmt, '$now') > $wait ";
 }
 return $where;
}
add_filter('posts_where', 'publish_later_on_feed');
*/

// Remove nofollow from comment author links //

function make_comments_author_links_dofollow($str)
{
 $str = preg_replace(
 '~]*)\s*(["|\']{1}\w*)\s*nofollow([^>]*)>~U',
 '', $str);
 return str_replace(array(' rel=""', " rel=''"), '', $str);
}
remove_filter('pre_comment_content', 'wp_rel_nofollow');
add_filter ('get_comment_author_link', 'make_comments_author_links_dofollow');

Make notes and explain your code

You should also use comments to make notes in your code on what each line does, or on what each section of code is for. In the example above, you’ll see that there’s a comment before each of the snippets that specifies what each snippet is for, for easy reference when looking at the code in future.

If you’re a theme or plugin developer, you should also use comments to explain your code, so that anyone (including yourself) looking at the code in future to either understand or modify it, can see what everything does. As an example, the following is a section of code from my SOUP widget, which shows upcoming posts to your readers:

// Extract Args //

function widget($args, $instance) {
 extract( $args );
 $title = apply_filters('widget_title', $instance['title']); // the widget title
 $soupnumber = $instance['soup_number']; // the number of posts to show
 $posttype = $instance['post_type']; // the type of posts to show
 $postorder = $instance['post_order']; // Display newest first or random order

As you can see, each line has an inline comment (marked by two slashes followed by the comment) explaining what it means, for easy reference during development and also for future modifications.

Your own resolutions?

What resolutions have you made for running/editing your WordPress sites over the next year? What would you tell others to do?

Add a Column to Easily Note the Post ID

Dave Clements — Wed, 04 Jan 2012 13:00:44 +0000

After recently writing my post “Include a Post within a Page or Post“, I was in the process of writing a tutorial to give you an easier way to find the Post ID, by adding a column in the post editor screen.

Well, it seems that WP Snipp pipped me to the post as they just published a post doing exactly that. So rather than go through the rigmarole of writing the snippet myself, I’m going to give you his snippet. Drop it into your functionality plugin to use it:

// ADD COLUMN IN EDITOR FOR POST ID //

function posts_columns_id($defaults){
    $defaults['wps_post_id'] = __('ID');
    return $defaults;
}
function posts_custom_id_columns($column_name, $id){
	if($column_name === 'wps_post_id'){
        	echo $id;
    }
}

add_filter('manage_posts_columns', 'posts_columns_id', 5);
    add_action('manage_posts_custom_column', 'posts_custom_id_columns', 5, 2);
    add_filter('manage_pages_columns', 'posts_columns_id', 5);
    add_action('manage_pages_custom_column', 'posts_custom_id_columns', 5, 2);

Now when you go to your posts (or pages) screen, you’ll see that there’s an additional column that shows your post ID for easy reference. Pretty handy huh? Thanks for the snippet Kevin.

Set up W3 Total Cache with Amazon CloudFront CDN

Dave Clements — Thu, 22 Dec 2011 13:00:21 +0000

I wrote a post a number of months ago about using Amazon S3 to create a free CDN for your WordPress. Someone at the time correctly commented that this wasn’t a true CDN, because a CDN has a number of servers all over the world with syndicated content from your website, whereas S3 stores your information on a single server, so all it serves to do is reduce the load on your own server.

After recognising this, I set about making the switch to CloudFront, which is Amazon’s CDN offering. I was initially skeptical about the cost, but in actual fact, despite having an increase in visitors in the months since doing this, my monthly cost has gone down by 50-75% (from my S3 hosting costs). I pay just a couple of bucks a month for my CDN as well as a chunk of S3 storage.

Install W3 Total Cache

In order to do this, you’ll need to install the magnificent W3 Total Cache plugin. This plugin’s principal purpose is to cache your dynamic content into static pages to significantly speed up how quickly your site loads (and for this reason it is one of about two plugins that I will install on every single installation of WordPress). However, in the plugin’s development, they soon added the capability to use a CDN to further speed up your site by delivering your site’s static content (images and static files) from servers all over the world.

Install the plugin and activate it. The options for setting up the plugin are quite extensive, so I’ve covered that in a separate tutorial: Speed Up WordPress with W3 Total Cache.

Be sure not to get ahead of yourself. Do not activate the CDN from the plugin’s General Settings yet. We’re going to set up the CDN so that everything’s ready and then turn it on; otherwise you’ll be telling the plugin to use a CDN that doesn’t exist and you’ll have loads of missing content. However, do be sure to select Amazon CloudFront (Pull) as your CDN provider and save your changes.

Get set up with Amazon CloudFront

Most of you will likely have an Amazon account. If not, you’ll have to go through a few more steps to get set up. Go to Amazon Web Services and either create an account, or use your existing account to get signed in.

Once you’ve set up an account, go to your Account and go to the Security Credentials section. From there, create a new access key and keep the Access Key ID and Secret Access Key handy because you’ll need them later.

Set up the CDN in W3 Total Cache

Go to the CDN tab of the W3 Total Cache configuration page. In the General section, check every box, except for the last (Import external media library attachments). You don’t want to be storing other people’s data, unless you have concerns about the reliability of their servers.

In the next section (Configuration), you’ll need to enter your security credentials from Amazon AWS that we got earlier. You’ll then see a button for creating a distribution. Click on that to create the distribution within CloudFront. If you entered your details correctly, you’ll see a little message that says that the distribution was created successfully. You’ll also note that it will populate the field titled “Replace site’s hostname with” with your unique CloudFront subdomain. You can test the distribution to make sure everything is set up correctly.

Activate the CDN

You’re all set to activate the CDN now. Go back to W3 Total Cache General settings and enable the CDN. Load your site and check that it loads as expected. At this point, you now have a fully functional CDN running through Amazon CloudFront.

Set up CNAMEs

Stopping at this point is fine; everything works correctly and you’ve achieved what you set out to do. However, another nice touch that W3 Total Cache added was the ability to use CNAMEs for your CDN. What does that mean I hear you ask? Well, if you look at the URL of any of your images on your site with the CDN active, you’ll see that the location is some random subdomain on cloudfront.net. It works, but you can make it look more professional and also help SEO a little in the process by replacing the random CloudFront domain with your own domain.

First of all, log in to your web host’s control panel and look for a DNS Zone Editor. Next you’ll need to create a CNAME for subdomains that you want to use in place of your CloudFront subdomain.

For example, on my site, I have created CNAMEs called cdn, cdn1, cdn2 through cdn7, which all point to my CloudFront subdomain. You could choose names like media, cdn, files, static or whatever you like. I recommend creating 8-10 though to spread your DNS/HTTP requests across multiple CNAMEs. See the image above for how I set it up in WebHost Manager:

Enter your CNAMEs in AWS

Once the CNAMEs are set up with your web host, go back to the AWS console, find your CloudFront distribution and edit it. It will bring up a window where you can enter all the CNAMEs for your site. Enter them all here and save them. Then go back to your W3 Total Cache CDN configuration page and enter the same CNAMEs in place of your CloudFront subdomain that was automatically populated when you created your distribution earlier. See the image below for how to enter this information.

Then, make sure to test your CloudFront distribution to ensure that it is configured correctly. If the test passes, save everything and reload your site and make sure that (a) everything looks like it should and (b) your files are being served from your CNAMEs instead of your CloudFront subdomain.

This whole tutorial seems imposing, but once you get into the swing of things, it really doesn’t take more than about 15 minutes. It makes such an improvement to your site speed, so it’s well worth your time and efforts. If you have any trouble with it, leave a comment and I’ll try and help you.

Include a Post within a Post or Page

Dave Clements — Mon, 19 Dec 2011 13:00:36 +0000

I’ve seen this question come up quite a few times:

How do I put a post into another post?

How do I include a post inside a page?

I always thought it was a really rookie question by people who didn’t understand WordPress and how it works. And I suppose that may still be true to a certain extent, but a couple of occasions have lent themselves to using this for legitimate needs.

For example, for one of my clients, they wanted to return their equivalent product if a user searched for a competitor’s product on their site. They wanted to return the usual product information, but wanted information at the top of the page explaining that the product shown below is the equivalent product for what they searched for and to look for the specific product number in the product literature. So below that, it was necessary to paste the entire product information post which already exists. So this was a good reason to use this ability.

I did a bit of searching and found a solution from the good people over at Digging Into WordPress. It’s another snippet, so get your functionality plugin ready:

function diww_include_post($atts) {
	$thepostid = intval($atts[id]);
	$output = '';
	query_posts("p=$thepostid");
	if (have_posts()) : while (have_posts()) : the_post();
		$output .= get_the_content($post->ID);
	endwhile; else:
		// failed, output nothing
	endif;
	wp_reset_query();

	return $output;
}

add_shortcode("include_post", "diww_include_post");

In short, what this snippet does is create a shortcode (include_post) in the last line, which has a single argument; the post ID (id, from line 2). The shortcode uses that post ID to find the appropriate post content and then returns that content in place of the shortcode.

The syntax for using the shortcode with the snippet above would be:

[include_post id="3012"]

This will return the post content from post 3012 to wherever you paste it. That could be a post, page, a custom post type, or even a sidebar widget.

If you’re not sure how to get the post ID, go to your list of posts. When you edit one, the URL will include the post ID. In this example, the URL would look like this:

.com/wp-admin/post.php?post=3012&action=edit.

(Alternatively, you could add a column to your posts editor which shows the post ID next to each post.)

You could also use this functionality to create snippets of text that you use repeatedly and paste them into posts, or to paste common suggestions or disclaimers into posts, by creating posts specifically for those pieces of text and then using the shortcode to pull them into any other post. What have you used this for? I’m always interested to hear how you use these snippets.