Modern browsers will cache downloaded content for a period of time, so as to not be downloading the same content repeatedly. These browsers will keep this cache for a few days by default, or until the user clears it manually. However, if the visitor visits your site frequently, it would be more beneficial for the browser to cache this content for a longer amount of time.

That’s where this article come into play. It is possible to send HTTP response headers that tell the browser to cache the content for (up to) a longer amount of time. For the visitors who visit your site frequently, this will benefit both you and them. Since they won’t be repeatedly downloading the same content, their page will load slower, and your server will consume less bandwidth. For the visitors who don’t return to your site, telling the browser to cache the content for longer really has little negative effect.

The response headers we’ll be setting are Expires and Cache-Control. Assuming you have already installed mod_headers, this will be a snap. Start by logging into your server via SSH, and opening your Apache configuration file (/usr/local/apache2/conf/httpd.conf).

If you followed our GZIP article last week, then you’ll already have part of this code in your file. Find that code, and add this above it:


ExpiresDefault "access plus 2 weeks"
ExpiresActive On
Header append Cache-Control "public"


Assuming you did follow last week article, then immediately after this line:

Add these lines:

ExpiresDefault "access plus 1 months"
ExpiresActive On
Header append Cache-Control "public"

After you have add those two snippets, save and close the file and then restart Apache. This will tell browsers to cache .css files for two weeks and images for one month. While you could certainly cache CSS files for one month, I, personally, tweak my CSS files more frequently than I change images. Feel free to change that to suit your own needs though.

Creating themes is another portion of WordPress development. While it certainly involves less programming than creating a plugin, there is still a fair amount of code “required”.

Themes are generally spread into multiple files, which are then (mostly) automatically included into each other on a as-needed basis. If we take a look the default theme, we can see the general structure of the files. The default theme has the following files (beside them I’ve included a short description of what they’re for):

404.php (displayed for 404 errors)
footer.php (the footer of the design)
index.php (the blog home page)
search.php (search result page)
archive.php (date, category and tag archive listings)
functions.php (can hold theme-dependent plugins, etc)
links.php (template for list of links)
sidebar.php (the sidebar of the design)
archives.php (template for list of archives)
header.php (the header of the design)
page.php (a page)
single.php (a single post)
comments-popup.php (popup form for comments)
image.php (attachment template)
style.css (CSS file)
comments.php (comments display loop)

As you can see the various sections of a WordPress site are separated into different files (archives, posts, pages). Additionally, the header, footer and sidebar also get their own file. This creates the design structure, which one of the various page types then fits into. Over the next few articles, we’ll be further discussing these files and how to create a theme from scratch.

As we discussed last week, planning your database structure ahead of time has many benefits. Today we’ll be going over (in a general sense) how to create a database plan.

Let’s start out with tables. A table contains a structure made up of fields. Conforming to the structure are rows of data. Think of a table like a spreadsheet, where fields are the “headers” at the top of a column, and data is separated into rows.

The best way of deciding what tables you want to create is relatively simple. Within your database, you’ll probably need to store a few different types of data. If we take the example of a blogging platform, you’ll need to store (at minimum) posts, comments and options. These are three different types of data. As these data types will require different fields, we will create a table for each data type. Generally, this is a good way of determining what tables you will need to create.

In this example you could possibly store posts and comments within the same table (as they have similar field requires). However, I would recommend against this. Because there is a potential to have thousands of comments and thousands of posts, combining these two data sets will only slow things down. This is another thing to consider when planning out your tables. If you have two types of data that could conform into one table, will one (or both) of these data types potentially end up with thousands of rows. If so, you should separate them.

There is a caveat on that last point. If those two similar data types are directly related to each other, and you will always need the other within your application, you may want to keep them within the same data row. This is because performing a query to retrieve this data involves less load on the server if they’re in the same row, than if they were in separate queries. For instance, you’ll always need the comment author and the comment body together, so it makes sense to keep them within the same row, and not in separate tables (not a good example, since they both fall under the “comment type”, but you should get the point).

Onto fields, which are much simpler to plan out. Basically, you’ll need a field for each type of data within a general type of data. For the example of a post table, you would need a field for when the post was created, the title of the post, the body of the post and any other features the blogging platform might have (categories, tags, etc).

The expandability of a database structure comes from making your tables general enough to support additional fields within in the future. Keeping your data types general, while not making them too general, is the basis of a good database structure. While still trying to make your data types general, you should follow the above guidelines that I have set out in this post and not make them too general.

Because I like you guys (although really because I feel like I’m writing to myself… and I like myself), I’ve made an visual (incomplete) database structure for the example we used throughout this post. Obviously you don’t need to make a plan this “formal” (a few notes jotted on a piece of paper, in a text editor or, if you have a good memory, in your head will work just fine.

In Javascript, you may be familiar with event triggers such as onClick. jQuery is able to do something similar, where you can bind functions to an event on an element.

While in Javascript event triggers are generally used as attributes on HTML objects, jQuery does it differently. jQuery has functions for events, that you branch onto a selector. You then bind your own function to the event function, and you end up with a very powerful event trigger.

Event functions are simply a function that you branch onto a selector and then bind a function to. Let’s look at an example of a click event. Let’s say that everytime that somebody clicks on a link, an alert box appears.

[code language="js"]$("a").click(function(){
alert("You just clicked a link!");
});[/code]

It’s as simple as that. jQuery supports all the standard event types, which you can see a list of over here.

Continuing on with our optimization mini-series, today we’ll be enabled GZIP on out server. GZIP compresses files before sending them to the browser (which will decompress them automatically), which results in a smaller download size and, therefore, a faster loading file.

However, GZIP does have some downfalls. First of all, compresses files as they’re requested (everytime, on-the-fly) can become very CPU-intensive on a very large site. Secondly, on very small files, the time the browser takes to decompress the file might be longer than the time saved downloading. These won’t become an issue, as your site would have to be very large, and your server very underpowered for the first situation to become pronounced. Since the download time on small files is very minimal anyways, you can just throw the second situation off the table.

As we have compiled Apache with the mod_deflate module, enabling GZIP is fairly easy. Start off by opening up /usr/local/apache2/conf/httpd.conf and finding the <Directory /home/*/public_html> line. Before the </Directory> line, add the following lines:

# Send gzipped content
SetOutputFilter DEFLATE

# Only compress text/html for non-supporting browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

These lines will enable GZIP compression for all files. Because some old browsers did not support GZIP compression on all file types, the last three lines will selectively disable it. If the browser doesn’t specify that it will accept GZIP compressed content, Apache will automatically disable GZIP for that specific request.

This will currently enable GZIP for all file types, including images. Unfortunately, compressing images with GZIP will actually increase their file size, giving you the opposite effect. The solution is to disable GZIP compression on images. Add these lines outside of the directory tags:


SetOutputFilter OFF


Save and close the file. Then restart Apache.

There you have it, faster downloading web pages using GZIP compression.

When creating a plugin that is meant to modify the front-end of the WordPress site, you may need to execute code within the theme, using common hook or otherwise. Let’s take on the example of if we’re creating a plugin that outputs a random quote.

For starters, you’re going to want to have a function within your plugin that will output something to the browser. You’ll probably want the user of the plugin to be able to decide where their want to quote to appear in their theme. While you could certainly tell them to simply reference the function where they want the quote, however there’s one major flaw in this method. If the user (for whatever reason) decides to deactivate the plugin, your function will no longer be loaded into the theme. That function no longer exists will cause PHP to issue an error, which will have a negative effect on the site.

A better way of having the user add something to their theme is to have them create an action. Creating an action will allow you to plug a function (or many) into the hook. The difference is, that if your plugin gets disabled, the hook will still be created, your function will just no longer be hooked into it. Thus, the user will not experience any errors (related to your plugin) in their theme.

By simply having the user add a line that includes apply_action() with a specific name, you’re then able to hook into that action normally and create a better experience for your plugin.