Over the last few months, development of WordPress version 2.9 has been in full swing. The major features that have been added are: basic image editing; easier video embedding; post, page and comment trash can; plugin update notification and compatibility notification in WordPress’ core upgrader and various developer and bug fixes. Along with the major changes, the smaller features and changes in 2.9 are listed here. Development is starting to come to a close, and help is needed to begin testing WordPress 2.9 beta 1.

If you’re interested in testing out beta 1 of WordPress 2.9, you can download it here (zip). You can also run the latest development version via subversion. Remember that this is pre-production software, and bugs are likely present. It is not recommended that you run this in a production environment, use a development environment instead. However, if you do decide to run the beta on your production blog, be sure to backup your blog’s files and database beforehand (as a precaution).

After testing the beta out, you can report any problems on the wp-testers mailing list. If you spot a reproducable bug, you can report it to WordPress’ ticket-management system: Trac (you can sign in using your WordPress.org account). Happy testing, the WordPress community appreciates it.

An organized and planned database will have relatable data separated into multiple tables. This data may need to be used together at some point. This is where MySQL JOINs come in. Carrying on with our previous instalment, we’ll continue talking about table joining.

Last time, we took a look at a basic table join, which selected all fields from two tables. Today, we’ll be covering how select specific fields from specific tables involved in our join. In your code, you may only need to use some of the available fields. By specifying just the fields you need, you can shave some time off your query. Let’s take a look at our previous join query, which we’ll modify:

[sql]SELECT * FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

With this query, we use the wildcard character (an asterisk) to specify that we want all the fields. In a regular select query, we would use a comma-separated list of fields, in place of the wildcard, to retrieve specific fields. In a join query, it is the same, except with must specify the table that a field resides in. We do this in the format of: table_name.field_name. Adapting our previous example, we end up with this:

[sql]SELECT table1.id, table1.name, table2.mark FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

Next time we’ll be covering joining multiple tables.

During our last instalment of this series, we began talking about organizational tables. This time around, we’ll be discussing some of the more advanced portions on tables in HTML.

If you’re using a table to organize data, you’ll likely have column headers that identify the type of data contained within that column. Using what we’ve previously covered, you could simply use a tr at the beginning of the table and use CSS to stylize them. However, there is a better way.

HTML contains a method to specify a table header, footer and body. We can use this method by wrapping the appropriate rows in thead, tfoot and tbody tags, respectively. In the thead section, cells must use th instead of td. The order of these “groups” is also vital. The thead and tfoot groups must be before the tbody group (the footer will be still appear below the body).

This method has a number of advantages over simply ordering your rows to create a header and footer. For starters, these three tags provide semantic meaning to your table. Having the footer above the body, in the code, allows the browser to render the footer before the (potentially long) body has loaded. Additionally, when you’re generating your body via a programming language (such as PHP), having the (likely) static header and footer before your dynamic body code will be neater.

Example:

[html]<table>
<thead>
<tr>
<th>ID</th>
<th>Surname</th>
<th>First Name</th>
<th>Email</th>
</tr>
</thead>
<tfoot>
<tr>
<td>ID</td>
<td>Surname</td>
<td>First Name</td>
<td>Email</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>192<td>
<td>Smith</td>
<td>John</td>
<td>john.smith@example.com</td>
</tr>
<tr>
<td>193</td>
<td>Doe</td>
<td>Jane</td>
<td>jdoe282@example.com</td>
</tr>
</tbody>
</table>[/html]

Last week, a new version of CentOS was released. Version 5.4 includes various improvements, bug fixes and security fixes. If you’re running CentOS on your server, you may be interested in updating.

CentOS contains numerous updated packages and new packages. If you’re interested in learning more about the changes in CentOS 5.4, you can view the release notes. To update from an earlier version of CentOS, login to your server as a root user via SSH and run the following command:

yum update

You will then need to confirm that you want to update by typing y and hitting the enter key. If you want to see the package changes before updating, you can do so by running the following command:

yum list updates

As previously mentioned, you can stay up-to-date on CentOS updates by subscribing to their announcement mailing list.

When you’re running WordPress in a production environment, it is ill-advised to make changes without testing. The best way of doing this is to run a secondary copy of your blog that you can test changes on first, before pushing them out to your production blog. These changes may include new plugins, plugin development, a new theme or even WordPress upgrades.

To duplicate your WordPress production environment, you’ll need to do a couple of things. First, you’ll need to decide whether you want to run your testing site on your own computer, or on the same server as your production site. Running your testing site on your computer will have the advantage of allowing faster development; however, you will not be able to perfectly replicate your production environment. By having your test site on the same server as your production site, you’ll obviously benefit from having the same environment.

Once you have decided on that, you will need to create a copy of the files you use on your current WordPress install (including your theme, plugins, etc). Simply downloading/copying these files via FTP will suffice. If you will need to sync files back and forth quite often, you should look into more complicated solutions.

For the database side of WordPress, we’ll be using a copy of our production database. This will give us a full set of data to play with on our development site. You can use phpMyAdmin to export your production database and import it into your development database. You’ll need to adjust the database setting in your development wp-config.php accordingly.

If you’ve been following along, you’ll have noticed that your development blog redirects to your production blog. WordPress stores your site’s URL in its database, and will redirect to it when the current URL doesn’t match the one stored in your database. Instead of modifying our development database accordingly, we can override the URL in our development wp-config.php. To do this, you’ll need to add the following two lines to your development wp-config.php:

[php]define(‘WP_SITEURL’, ‘http://example.com’);
define(‘WP_HOME’, ‘http://example.com’);[/php]

WP_SITEURL is the URL location of the WordPress files. WP_HOME is the URL to get to the blog portion of your WordPress site (this will differ from WP_SITEURL if you have a static front page). Omit the trailing slash from the url.

You should now have a functioning development copy of your blog to play with. Be careful about syncing changes back to your production plan and always backup your data beforehand.

When you begin to separate data into distinct tables, you will gain advantages as well as disadvantages. With this data separated, you may have instances where you need relatable data from two or more tables. Your first thought may be to query the database multiple time, then do some looping conditional checks in PHP to string your data together. This would certainly work; however, it is not the most efficient way. For starters, the code to string this data together is messy, and could be tricky to get perfect. Additionally, you’re making multiple calls to the database, with is putting more strain on your server’s resources.

There is an easier and more efficient method of accomplishing this. We can use MySQL’s table join functionality to get MySQL to do all our heavy lifting. Given a reference point, MySQL can join multiple tables together and return the final result to us, all in one database query. A reference point being two fields which will share matching numbers in both of the tables. For example, if you were storing data for school students, you may have a student information table and a student marks table. To join these two tables, you will need a field in the student information table that will match one of more rows in the marks table via a field. A student ID would be a good choice, as it would relatable to other tables.

Now that we are familiar with what is required to create a table join, we can learn the syntax for it. Basically, we select from the first table, tell MySQL to join with another table and then specify the reference point.

[sql]SELECT * FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

You’ll then receive a result with all the fields of table1 and table2 (the reference point will only appear once). You handle these results as normal MySQL queries.

In our next article, we’ll be covering joining more than two tables together, as well as different types of joins.