1. The Community

One of the greatest things about WordPress is the community. I worked with many different open source and closed source development communities, and this is the best one that I have ever dealt with. There are a number of ways that you can get involved in the WordPress community.

You can participate in WordCamp, an informal, community organized event throughout the world that is open to users and developers to share ideas on WordPress. For more frequent events, look for WordPress Meetups in your area; I am part of a Meetup in San Antonio that is hosted at Geekdom on a monthly basis.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

Whether you have been working with WordPress for years, or if you just picked it up yesterday, all are welcome to WordPress events. In fact, some of the best people to get involved in your local community are the newer WordPress users because they bring a fresh perspective. The WordPress community is very welcoming and the dialogue about what people like and don’t like leads to some great improvements for everyone.

2. More Than A Blog

A lot of people look at WordPress and think of it as “just a blog.” While it was forked from a blogging piece of software, WordPress has evolved to be so much more than that. Many of the sites you go to on a daily basis are probably running on WordPress. WordPress is fully customizable and with such an active community, many people are creating amazing themes and plugins that push it well beyond simply being a blog.

3. It’s Free

A lot of people say, “You get what you pay for,” but with WordPress you get so much more than that. You get an awesome community, you get a piece of software that can be much more than a blog and you get it all for free. The only thing left now is to find some good hosting, throw up a WordPress site and begin writing content.

This is what I have found to be awesome about WordPress, what do you love about it? Be sure to let me know in the comment section below!

In a previous post, Matt talked about the importance of updating your WordPress site. Check out the WordPress tag for more WordPress articles on the Rackspace blog! Learn more about how Rackspace can help you with hosting your WordPress site.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

You want to make sure that you are continually updating WordPress as new versions are released. You don’t want to be that guy that waits around and doesn’t update. With each update to WordPress you will find bug fixes and security fixes; the major version updates (like 3.1, 3.2, 3.3…) will contain feature enhancements. One of these enhancements could be really helpful to you, but if you hold off on updating you won’t have access to them.

Many people don’t update their themes and a common reason is that they modify them to make them more personal. This is one reason you should look into using a child theme instead of modifying a parent theme. A lot of things that you can do in child themes will give you the functionality you are looking for when you modify the parent theme.

You also want to make sure to update plugins frequently because they are susceptible to no longer working when a new version of WordPress comes out. Most of the time this is OK as WordPress tries to maintain 100 percent backwards compatibility, however, there are cases where a new version can break a plugin. Additionally, there can be security vulnerabilities in plugins and you don’t want to be running an insecure version of that plugin where someone could maliciously compromise your site.

Previously, Matt talked about what you need to know to backup WordPress check out his next post where he talks about why he loves WordPress. Learn more about how Rackspace can help you with hosting your WordPress site.

To make sure that your backups are current, I suggest you install a plugin. Having a backup plugin will make sure that you perform your backups on a regular, automatic basis instead of relying on yourself to remember to do manual backups. There are a few plugins that do this really well.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

BackWPup is a free backup plugin that will backup both your files and database content, or you could opt for the premium plugin called Backup Buddy to backup both components. Both Backup Buddy and BackWPup can send your backups off to Rackspace Cloud Files for storage in case you need to retrieve them in the future. Another plugin that has become very popular is called VaultPress, which is run by Automattic, the same guys who run WordPress.com.

If your site is compromised or your server fails, it is important to have a backup. By installing a backup plugin, you can have peace of mind that you have a record of your site that you can restore from.

Previously, Matt talked about how you can integrate a Content Delivery Network (CDN) with your WordPress site and you can check out his next post where he explains the importance of updating your WordPress site. Learn more about how Rackspace can help you with hosting your WordPress site.

The goal of a CDN is to distribute static media to users who are visiting your website. One benefit of using a CDN is the fact that they use a geographical DNS resolution to make sure that your users hit a CDN server closest to their geographic location. By doing this, you can deliver the media content quicker to your users’ browser.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

There are a couple of WordPress plugins that can connect the media on your site to Rackspace Cloud Files and help leverage the CDN. One of those is CDN Tools – as you upload an image or media file to your site, the plugin will store that file automatically on your Rackspace Cloud Files account so you can benefit from the CDN. Another plugin that supports a large variety of CDNs in addition to Rackspace Cloud Files is W3 Total Cache.

With only a few clicks, you can leverage these plugins to better serve media content to your end users. Not only will they get the content faster, your server will not be over taxed by rendering media files and can focus on delivering the text content of your site.

Previously, Matt talked about the importance of caching your WordPress site and check out the following post where he explains how to backup both the file system and database of your WordPress Site. Learn more about how Rackspace can help you with hosting your WordPress site.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

The object of caching is to store dynamically generated data in a static format so you can retrieve that data again without further processing. Since WordPress is an application that calls a database to retrieve content for your users, caching your content is a helpful way to speed up the performance of your server.

There are several plugins that can help you with caching your WordPress site. The BatCache plugin, along with the MemCached Object Cache plugin, is what WordPress.com uses to cache all its sites. It is a proven and simple plugin that will most likely work with your site. This solution is best if you are running a WordPress config on multiple dedicated or cloud servers.

If you are using something like shared hosting to run WordPress, you might want to look at something like WP Super Cache or W3 Total Cache. These options don’t take advantage of memcache or APC, but instead use static file caching. There are benefits to static file caching, namely you don’t have to invoke PHP to grab the data out of the caching mechanism, but rather deliver it directly from the disk to further cut down the load on the server. However, if you have more than one server in your WordPress Configuration, file caching doesn’t work that great since you are keeping two copies of the cache.

Even though your site might not have a huge amount of traffic right now, it is best to prepare for a growing user base by implementing a caching strategy as soon as you can.

Previously, Matt talked about three tips for selecting a WordPress plugin and check the following post where he explains the benefits of using a Content Delivery Network to serve up your larger media files and some plugins that can help you do it. Learn more about how Rackspace can help you with hosting your WordPress site.

1. Download From The WordPress.org Plugin Repository

I recommend that you download plugins from the WordPress.org repository for a couple of reasons: First, you will get automatic plugin upgrade notifications in the WordPress admin portal. This makes it easy to know that you have the latest and greatest version of the plugin with all the newest features and security patches.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

Another benefit is that the WordPress.org repository has higher security restrictions on the code used to write the plugins. People in the WordPress community review the plugins in the repository on a somewhat regular basis, which helps ensure that you are running plugins without malicious code. This protects both your site and your users.

2. Choose A Trusted Author

Picking a trusted plugin author is a somewhat complicated task. First, look for an author who has written more than one plugin hosted on the WordPress.org repository. Additionally, look for a plugin with a large number of downloads and seek out plugins with multiple released versions. This is a good indication that some of the kinks have been worked out.

3. Be Sure It Works With Your WordPress Version

On the plugin page, there will be a line on the right hand side that states what version of WordPress the plugin is compatible with. You will be given two values, both the lowest version required and the most recent version that the plugin is compatible with. Further down the page is a spot that says, “See what others are saying…” where you can review others’ opinions on the plugin. An overwhelmingly positive (or negative) response should be helpful in determining whether the plugin works correctly with the listed version of WordPress.

Check out Matt’s previous post where he talks about the dangers of installing WordPress from an OS software repository. In the next post of this series Matt explains the benefits of caching your WordPress site and some plugins that can help you do it. Learn more about how Rackspace can help you with hosting your WordPress site.

Packaging, Releases and Versioning

The version of WordPress installed from your Operating Systems software repository is very likely not up to date. Most OS distributions are going to include the stable version of WordPress from the time that the OS goes into beta. Let’s imagine that our fictional Linux distribution, My Cool Distro, releases a beta or release candidate today with the latest stable release of WordPress, which we will call 4.9.3. In this scenario let’s pretend that WordPress 5.0 is 14 days away from being released. My Cool Distro is going to still ship with WordPress 4.9.3 even though it shipped after 5.0 was officially released.  This is due to the rules and regulations of how the OS handles testing and package verification once it nears it’s release date.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

With WordPress, the X.Y releases are the major releases and the X.Y.Z releases are the minor releases that contain security and bug fixes for the X.Y major release. Just as 4.9 is a major release, 5.0 is also a major release, and 4.9.3 is the minor security and bug fix release. Most Operating Systems, will never upgrade a software package to another major release within the Operating Systems major release lifetime. In the majority of cases this is OK, as the developers and maintainers for My Cool Distro will backport important security fixes into the major version they initially shipped with. In some cases the developers of the original software package will do this themselves.

WordPress, however, does not participate in such a practice of keeping previous major releases up to date with new security fixes once a new major version is released. The WordPress project decided to do this for WordPress 2.0, largely to support the requirements of Debian Etch. However, in the end it didn’t work well and the idea was eventually abandoned. Additionally, in the case of WordPress, the developers and maintainers for My Cool Distro aren’t likely to have the skills or familiarity with WordPress to backport fixes, and will almost certainly never attempt it.

So let’s say that you install version 4.9.3 from My Cool Distro, and you notice that 5.0.2 is released. You go through the manual or automatic update process to upgrade to 5.0.2. Now, for the sake of argument, let’s say that WordPress starts backporting security fixes into previous major versions, and the WordPress 4.9 point release gets bumped to 4.9.4. The developers for My Cool Distro decide to update the package in their repository, you run an ‘apt-get upgrade’. You have potentially just blown away your 5.0.2 install with 4.9.4.

File Locations

The WordPress package from your Operating Systems repository is probably going to put files in really strange places, and likely reference it by use of symlinks from multiple other locations. For example, My Cool Distro puts WordPress in /usr/share/wordpress and symlinks portions from /etc/wordpress.

First, who would want web content in /etc? It is also generally bad practice to have your web content in a place like /usr/share/wordpress as it is not really a web directory. My Cool Distro will also create an Apache configuration file for you that will add an alias for to /usr/share/wordpress. Then you may want it to be accessible from directly from mycoolwpsite.com and the simple solution will be to set the DocumentRoot for mycoolwpsite.com to /usr/share/wordpress, or you are going to symlink /usr/share/wordpress to yet another place such as /var/www/vhosts/mycoolwpsite.com/. By the way, WordPress and WordPress plugins don’t really play that well with symlinks (but I won’t go into that now).

Now that you have a site using /usr/share/wordpress, you will probably want to install a new theme or plugin (I mean, how many people want to have a cookie cutter WordPress site, running the default theme?). You try to install from the WordPress admin and you find it is asking you for FTP credentials because PHP/Apache does not have appropriate access needed to perform the file system operations on the WordPress files and directories. At this point you install a FTP server, and have to screw around with it to allow your user to FTP to /usr/share/wordpress. You can also configure the FTP server to allow root logins, while deliberately slamming your head in a door. Or you just chown -R www-data:www-data /usr/share/wordpress so it stops asking for FTP connection information. ACK!

You will also want to upload images and such for inclusion in your posts. Do you really want to allow the web server user to upload content in /usr/share/wordpress/wp-content/uploads? You shouldn’t be uploading content like this to /usr/share/ at all. You will have to go through the process of moving your uploads directory, which can be difficult, because WordPress expects the uploads directory to be relative to the WordPress installation directory.

Later you decide that you want to create another WordPress site, so you make another symlink from /usr/share/wordpress, but with the symlink issues and the fact that you want completely different plugins and themes (not to mention that you don’t want to use WordPress Multisite or may not even know what it is), you download WordPress from the official site, or copy the original files to somewhere else. Now you are pretty much going through the manual install process — why didn’t you just do this to begin with?

You may decide that you want to run lighttpd, nginx or cherokee instead of Apache. You cannot use the configuration file that My Cool Distro provided for Apache, and you have to make modifications to the new web servers configuration file. In the process you find that aliasing doesn’t work the same as it did in Apache, so you symlink, point directly to /usr/share/wordpress, download WordPress or copy the files from /usr/share/wordpress to some place else. You are again going through the manual install process — so why didn’t you just do this to begin with?

I could go on…

Easy Button?

You have been taught by modern Linux distributions that installing software from your Operating Systems software repository is the only way to go. I will admit that I am one of the people who push this idea. But all ideas and best practices have their use cases and limitations. While it does make it easier, it was solving for a problem that WordPress doesn’t have. You don’t need to know what compile flags to use, you don’t have to worry with dependencies (other than of course the obvious applications needed to run a website), and you don’t have to put it in some pre defined location so that other software can find it to use it as a dependency.

Your Operating Systems software repository was designed to help make it easier for users to install software and help you stay secure. We have covered why using such a method is not helping you keep secure, so why is it not easier?

When you download WordPress from the official site you immediately have access to the installation instructions promising the famous 5 minute install. With some practice, you can install Apache, PHP, MySQL and WordPress within 5 minutes and have time left to go grab a coffee.

What do you get when you install from a software repository? You get some files dropped in an obscure directory, you get a small Apache configuration file that isn’t going to get you what you want, and you are going to get a readme.txt that the average person isn’t going to know where to find. This is supposed to be easy right?

Then you are going to be surprised that the installer doesn’t create a database for you, a database username, password or even tell you that you what to do next. That readme.txt is likely to be in some place like /usr/share/doc/wordpress-4.9.3/readme.txt. You find this file and it really tells you nothing. You go to WordPress Download website and find the install instructions and go from there. Now why didn’t you just do this to begin with? This is supposed to be easy right?

You get things installed and you go to upload media items and you don’t have the flash uploader, which means you cannot upload multiple files at once. What!? You hit the WordPress support forums, someone reads the readme.txt file that is bundled with the package from the software repository and finds that, My Cool Distro stripped the required files. You now need to download that file from the WordPress website. Now you are back to downloading something else from the WordPress website — again, why didn’t you just do this to begin with? To be fair, in it’s current form, WordPress 3.3, does not use the SWFUpload flash uploader any longer, but plugins may require it. This still gives you an idea of some of the problems that you can run into.

Support

If you have an issue, you will need support. At this point you are running an old, possibly insecure version of WordPress, your files are in strange places, you aren’t sure which place has the real files and have probably been hacked. On top of that, the support forums and IRC channel for My Cool Distro are of no help with WordPress. The support forums and IRC channel for WordPress have no familiarity with the way you installed it, and are recommending you upgrade to the newest version before they can really provide help, because they can’t remember if the year old version you are using supports the functionality you are looking for.

You eventually find out that you have been hacked because you didn’t stay up to date, and now there is concern about the integrity of your entire OS install and Google thinks you are running a bogus pharmacy website.

At this point, I hope that I have convinced you that installing WordPress from your Operating Systems software repository is bad practice and that you should never do it. By the way, for all you folks who installed WordPress from your Operating Systems software repository, I was just asked to buy some pharmaceutical products from your site and got a popup offering a free pirated film available for immediate download from an anonymous FTP site running on your server.

Check out Matt’s next post for three tips on selecting a WordPress plugin. Learn more about how Rackspace can help you with hosting your WordPress site.

I had recently implemented some code in a WordPress plugin, for downloading some source javascript files and then verifying them by requesting an MD5 file, and comparing the MD5 of the downloaded source file to that of what we expected. I had wanted to use the Content-MD5 header, but as I am running nginx, and nginx not supporting it, I decided for the time being to leave it, making the extra request.

I knew the solution to adding it was in using the nginx embedded perl module, and to make sure that I didn’t block the delivery of the content, that pulling an MD5 hex hash out of an MD5 file that lived along side the original file would be best.

I ended up writing two versions, one that would only pull the MD5 out of an MD5 file, and one that would fall back to compute the MD5 hex hash on the fly if an MD5 file didn’t exist.

Here is the finished product:

# nginx Embedded Perl module for adding a Content-MD5 HTTP header
#
# This perl module, will output an MD5 of a requested file using the
# Content-MD5 HTTP header, by pulling the hex hash from a file of the
# same name with .md5 appended to the end, if it exists.
#
# Author: Matt Martz <matt@sivel.net>
# Link: https://gist.github.com/1870822#file_content_md5_req_dot_md5.pm
# License: http://www.nginx.org/LICENSE

package ContentMD5;
use nginx;

sub handler {
    my $r = shift;
    my $filename = $r->filename;

    return DECLINED unless ( -f $filename && -f "$filename.md5" );

    my $content_length = -s $filename;

    open( MD5FILE, "$filename.md5" ) or return DECLINED;
    my $md5 = <MD5FILE>;
    close( MD5FILE );
    $md5 =~ s/^\s+//;
    $md5 =~ s/\s+$//;
    $md5 =~ s/\ .*//;

    $r->header_out( "Content-MD5", $md5 ) unless ! $md5;

    return DECLINED;
}

1;
__END__

# nginx Embedded Perl module for adding a Content-MD5 HTTP header
#
# This perl module, will output an MD5 of a requested file using the
# Content-MD5 HTTP header, by either pulling it from a file of the
# same name with .md5 appended to the end, if it exists, or will
# calculate the MD5 hex hash on the fly
#
# Author: Matt Martz <matt@sivel.net>
# Link: https://gist.github.com/1870822#file_content_md5.pm
# License: http://www.nginx.org/LICENSE

package ContentMD5;
use nginx;
use Digest::MD5;

sub handler {
    my $r = shift;
    my $filename = $r->filename;

    return DECLINED unless -f $filename;

    my $content_length = -s $filename;
    my $md5;

    if ( -f "$filename.md5" ) {
        open( MD5FILE, "$filename.md5" ) or return DECLINED;
        $md5 = <MD5FILE>;
        close( MD5FILE );
        $md5 =~ s/^\s+//;
        $md5 =~ s/\s+$//;
        $md5 =~ s/\ .*//;
    } else {
        open( FILE, $filename ) or return DECLINED;
        my $ctx = Digest::MD5->new;
        $ctx->addfile( *FILE );
        $md5 = $ctx->hexdigest;
        close( FILE );
    }

    $r->header_out( "Content-MD5", $md5 ) unless ! $md5;

    return DECLINED;
}

1;
__END__

# nginx sample configuration for adding a Content-MD5 HTTP header
# using the Embedded Perl module
#
# Author: Matt Martz <matt@sivel.net>
# Link: https://gist.github.com/1870822#file_nginx.conf

http {
    perl_modules perl/lib;
    perl_require ContentMD5.pm;

    server {
        location / {
            root /var/www;
            index index.html
        }

        location /download {
            perl ContentMD5::handler;
        }
    }
}

Here is an example of the resultant HTTP Headers:

$ curl -I 

HTTP/1.1 200 OK
Server: nginx/1.0.5
Date: Mon, 20 Feb 2012 20:19:04 GMT
Content-Type: application/octet-stream
Content-Length: 134217728
Last-Modified: Mon, 20 Feb 2012 20:18:25 GMT
Connection: keep-alive
Content-MD5: fde9e0818281836e4fc0edfede2b8762
Accept-Ranges: bytes

$ curl -i 

HTTP/1.1 200 OK
Server: nginx/1.0.5
Date: Mon, 20 Feb 2012 20:28:57 GMT
Content-Type: application/octet-stream
Content-Length: 42
Last-Modified: Mon, 20 Feb 2012 20:28:32 GMT
Connection: keep-alive
Content-MD5: 017d95ac06d4200bbcb2a5682e873fd7
Accept-Ranges: bytes

fde9e0818281836e4fc0edfede2b8762 128.bin

$ curl -I 

HTTP/1.1 200 OK
Server: nginx/1.0.5
Date: Mon, 20 Feb 2012 20:29:27 GMT
Content-Type: application/octet-stream
Content-Length: 134217728
Last-Modified: Mon, 20 Feb 2012 20:28:20 GMT
Connection: keep-alive
Content-MD5: fde9e0818281836e4fc0edfede2b8762
Accept-Ranges: bytes

$ curl -I 

HTTP/1.1 404 Not Found
Server: nginx/1.0.5
Date: Mon, 20 Feb 2012 20:29:36 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive