That’s a big issue in times where search engines are favoring fast loading websites. It also may mean that you have to upgrade your hosting to keep up with the performance requirements of your website.

P3, Plugin Performance Profiler, is a free WordPress plugin that analyzes the performance of frontend plugins. Frontend plugins are all plugins that are executed during page loading time.

Installation

Just open Plugins > Add New in your WordPress admin dashboard and search for P3. Click on the Install Now link to install the plugin, and on Activate on the next screen to activate it. You can alternatively download it from the official WordPress Plugin repository to install it manually on your blog.

Usage

Open Tools > P3 Plugin Profiler and click the Start Scan button to run the standard scan. The program will load several posts and pages from your site to calculate individual plugin performance data. You can alternatively run a manual scan instead, which allows you to pick the pages and posts that you want to load on the site. The benefit here is that you can specify exactly which posts and pages you want to use for the sample.

Once done, results are displayed in the program interface.

You should now see the average plugin impact on the site’s load time, the number of MySQL queries that are run per visit and a runtime breakdown by plugin.

If plugin impact appears to be to high, or if you have a plugin installed that is using a lot of resources, you may want to consider replacing it or removing it completely from the site. You can deactivate plugins before you run the test again to see if the deactivation has a positive impact on the frontend page loading times. You could furthermore install an alternative to see if it is lighter on the resource side.

There is however no option to compare scans with each other, which is unfortunately. It is also not clear why the performance profiler itself is listed in the results, as it does not really make a whole lot of sense.

Still, if you are hearing complaints from readers or are noticing server peak load times and resource usage, you may want to check out the Plugin Performance Profiler plugin to see which plugin may be causing it.

WordPress Portable is a free program for Windows that automatically ships with everything needed to run WordPress locally. All you need to do is to extract the package contents on your system after download and start the WordPress Portable executable afterwards.

The blog is available from that moment on and you can do all the things that you can do on a self-hosted WordPress blog as well.

Just open http://localhost/wordpress/ in your web browser to open the local WordPress installation. Click on log in and enter admin as the username and password to open the administrative interface of the blog.

First thing you may want to do is to upgrade the blog to the latest version. You should see a notification at the top of the admin interface on first run. The update takes considerably longer than it would on a remotely hosted website.

Once done you can start to install new themes and plugins, modify settings, and to start writing your first posts. You basically can do everything that you can do on a self-hosted WordPress installation.

The local installation can be used for several purposes. This includes local theme and plugin development and testing, testing new WordPress versions before you upgrade your live blogs on the Internet, or to showcase blogs to clients or friends. Another option is to use the local WordPress blog to store your own personal writings, a diary for instance or important information that you need to write down or want to collect.

WordPress Portable ships with Apache, PHP and MySQL included, which means that you do not have to install those technologies prior to installing the blog. New users benefit from the simplicity of the solution, while advanced users may like the ability to put the package on a portable drive or stick, or to use it to quickly run tests locally.

The project lacks documentation which can be a issue for some users. It is for instance not clear if and how Apache, MySQL and PHP can be updated to newer versions, or if it is possible to import the database of an existing blog (the later may be possible with the help of plugins).

WordPress Portable is only available for the Microsoft Windows operating system. Interested users can download the latest version of the package, weighting in at about 10 Megabytes, from the developer website.

It is as usually possible to update the blog right away from within the admin dashboard if it has been configured for that, or via file transfer clients if the former option is not available.

The blog post that announces the new version of WordPress mentions 15 maintenance related fixes and one security related fix that have been applied to the new version. It fails to go into detail but links to the bug tracker listing which details every fix except for the security issue.

At least one of the issues that have been fixed in WordPress 3.3.1 seem to have affected this site. I was recently noticing issues with the author biographies not being displayed anymore on article pages, and it took a whole day to find a working workaround. It appears now that this was a bug that got fixed with this new WordPress release.

The security vulnerability is only briefly mentioned in the blog post where it is described as a cross-site scripting vulnerability that is affecting WordPress version 3.3.

The WordPress Codex lists all files that have been revised in the new version. It is theoretically possible to only upload those files to the site to save time and bandwidth.

I have already updated several WordPress sites to version 3.3.1 and did not notice any odd behavior or issues with the updating or site operation.

WordPress admins are encouraged to update their blogs as soon as possible to protect it from the security vulnerability and to resolve the stability issues that have been fixed with the update.

The What’s New page at the WordPress Codex highlights the – many – changes of the new version. WordPress admins will instantly notice several changes to the applications admin interface. A new toolbar is displayed on top of the dashboard that combines the features of the admin bar and the admin header.

The new bar links directly to plugin and theme updates, comments awaiting moderation and the New menu with options to create new content on the blog. (There is a function to remove some of the elements that are shown in the admin bar. Credits to Sergej Müller)

Another change are “fly-out” menus in the admin interface. All submenus of a menu are displayed when you hoover the mouse over the menu. This saves a click and improves the admin’s workflow.

WordPress editors will notice a new file uploader. The developers have done away with the four upload buttons for specific type of media, and replaced it with a single button. The new uploader supports drag and drop operations and file browsing to select files to upload. Support for rar and 7z files have been added to the file uploader.

WordPress admins who switch between themes regularly will notice that widgets are not lost anymore when they do that.

A video has been created that highlights several of the new features.

The WordPress backend has been updated as well with hundreds of bug fixes and performance improvements. It is to early to tell if the improvements will have a significant impact on the blog’s server resource usage or loading times.

Have you updated your blog to WordPress 3.3 yet? If so, what do you think of the new version?

Why is it bad? Because search engines rank content in their search results. If they believe you are the creator you are usually ranked higher than a site that has copied the content, if such a site is ranked at all.

The reality is this. Sites that scrape contents are easy to setup (using RSS feed mostly), require barely any maintenance and earn the creator money. These sites publish copied contents shortly after they have been published on the original website. As long as people can make money from this method, they will use it to do just that.

Fat Pings are one way to resolve the situation. The idea is simple. When you publish an article you ping a trusted source to confirm that you site is the original location of that article. It does not really matter if you do it 10 seconds before the scraper does the same or one hour, it is only important that you do it before the scraper does. This obviously has consequences for original content creators who do not make use of Fat Pings, as it is quite possible that scraper sites may make use of Fat Pings for an extra advantage.

How do you cope with that situation? You configure all of your sites to support Fat Pings. Here is how that is done.

If your blog is hosted on WordPress.com or Blogger, then you do not need to do anything. Fat Pings are automatically sent out. If you are running a self hosted WordPress blog, you can install the free PubSubHubbub extension to inform search engines when they blog has been updated.

The suggestion to use Fat Pings comes directly from Google. You can read up more about it on Search Engine Journal and Labnol.

I also noticed that articles with hundreds of comments were loading significantly slower than pages with less comments. This made me reduce the number of comments per page to 50 root comments (plus their answers).

Today I noticed that WordPress added another JavaScript to ever page. The script in wp-inlcudes/l10n.js that is related to the admin bar that the WordPress developers added to one of the recent versions of the blogging platform.

While it is a small file with a size of 233 bytes it is still a script that is loaded by anyone, not just the admin of the blog. This somehow does not make a lot of sense. The important thing here is that the blog needs to make the request to load the element, not the time it takes to load the 223 bytes.

WordPress administrators may want to remove the JavaScript element from being loaded by every blog visitor to speed up the blog’s page loading times. The easiest way to remove the l10n.js from being loaded with WordPress is to unload it in the functions.php file in the WordPress theme folder.

All you need to do for that is to add the following line of code to the end of the functions.php file.

wp_deregister_script('l10n');

Please note that this may disable part of the admin bars toolbar functionality. Users over at Stack Exchange have found a way to keep the JavaScript loaded for administrators of the blog.

if ( !is_admin() ) {
function my_init_method() {
wp_deregister_script( ‘l10n’ );
}
add_action(‘init’, ‘my_init_method’);
}

Just add this code instead to the functions.php file.

It is thankfully not super complicated to configure your site to be compatible with the new author photo snippets that show up on Google Search. It is at this point in time however not guaranteed that your photo, or a photo of one of your authors, will appear in Google Search. It is rumored that Google has enabled that feature only for selected blogs and sites.

Nevertheless, it does not hurt to add the code to your site and Google Profile. And if your site gets picked by Google, you can expect a higher CTR (click-through rate) than sites without an author profile photo in Google.

Lets take a look at how it looks like in the search engine if it is configured correctly and enabled by Google:

Here are the steps that you need to undertake:

Creating An About Author page

You first need to create an about author page on your website. You then need to link to that page from all posts that this author writes. The link needs to use the rel=”author” parameter. How it is added depends largely on how the author information are posted on the post pages.

Here on Ghacks, the code looks like this:

<p class=”tags”>Author: <a href=”http://www.ghacks.net/author/martin/” title=”Posts by Martin Brinkmann” rel=”author”>Martin Brinkmann</a>

Adding the code can be an easy task on single author blogs, but a bit more complicated on multi-author blogs. The best way to add support on those blogs and sites is to install a plugin like Allow REL= and HTML in Author Bios that adds the support.

You are not yet finished though. The about author page needs to exist for every author on the site. The actual page can contain any kind of information. One important part though is that it needs to link to the Google profile of that author. The link to the Google profile needs to contain the parameter rel=”me”.

<a rel=”me” href=”http://profiles.google.com/ID”> Author Name </a>

Linking Back from Google Profile

In the last step, we need to link back from the Google profile to the about page on the website. Open your Google Profile, click the Profile icon at the top and then the Edit Profile button at the top. Locate links on the right side and select the Add custom link option.

You need to link to the author page on the website, and enable the “this page is especially about me”. You also need to make sure that a photo is added to the profile.

Testing the rich snippet

Open the rich snippet testing tool and enter an url from your website that is linked to a single author (a blog post for instance).

If you see the author photo next to the listing, you have configured the author profile photo support on your site correctly.

To summarize:

• Create an about author page on your site. Link from that page to the Google Profile of that author with the rel=”me” tag. Link the author’s blog posts on the website with the rel=”author” tags to the about author page on the blog.
• Add a photo and a link to the author’s about page on the Google Profile of that author. Make sure the “this page is especially about me” box is ticked.
• Check for correct implementation with the help of the Rich Snippet Tool.

I personally dislike the new WordPress admin bar for several reasons. First, it always takes up space at the top of the browser window, which means that the start of the website is pushed down a bit. The admin bar furthermore does not link to all available sections of the WordPress admin interface. If you want to manage plugins for instance, you end up with the same amount of clicks than before.

The WordPress Toolbar is a Firefox extension that resolves those two issues, at least for Firefox users. Unlike traditional toolbars, this one does not add itself to the header area of the browser, which is a good decision. The extension adds a single icon to the Firefox status bar after installation.

A click on the button has no effect on most sites. It only works on WordPress powered sites and only if the user is currently logged in as a user of that site.

When that is the case, a button toolbar is displayed in the upper right corner of the page. This toolbar is displayed both on the frontend and backend of the blog.

The toolbar replicates the full WordPress admin backend sans custom theme related sections. The main buttons lead directly to the sections in the backend. If you mouse over a button you see all available submenu options listed there, so that you can open those pages right away as well.

All options are basically links that point to the section in the admin backend. While that may not be the most comfortable way of integrating the backend in the WordPress frontend, it resolves the issues of the admin bar. WordPress Toolbar links to all sections of the admin interface, plus it does not push down the page with its always visible bar.

Most WordPress administrators may not like the fact that the button in the status bar needs to be clicked on before the toolbar is displayed in the upper right corner. This means that it requires two or three clicks to load the desired admin page. Even worse, admins need to click on the status bar icon at the bottom of the browser screen and then on a button near the top of the screen. It is possible to customize the button to place it in one of the top toolbars of the browser instead to reduce the time it takes to activate the feature.

WordPress administrators who would like to give the toolbar a try can download the extension from the official Mozilla Firefox website.

Please note that this is not a security release, which means you have got more time than usual to update your WordPress site to the new version of the blogging script.

WordPress Trac lists all the changes in the new release. If you look at the list you will notice that most are design related. Many fix or improve the Twenty Eleven default theme that ships with WordPress, while others do the same for the new admin interface introduced in WordPress 3.2.

Still no option to change the default font for the admin interface easily, unfortunately.

Updates are makinguse of the new “fast” update mechanism which only updates files that have been changed, instead of all files of a WordPress installation. Users who update via their WordPress Dashboard should notice that the procedure is speedier than before.

Updates are available via Dashboard > Updates. WordPress administrators can download the new version of WordPress from there or update directly if their blog has been configured properly for that.

The new version is alternatively available at the official WordPress website.

I have updated six blogs so far and did not notice any problems with the new updating mechanism or the new version of WordPress itself.

It is still a mystery to me why the developers thought it was a good idea to change the default plain HTML editor textarea font in the WordPress admin interface.

If you are like me, you prefer the old font, especially if you are used to working with the HTML editor of the admin area.

It is thankfully though not complicated to switch back to the old font. All you need to do is to replace or edit one file of your WordPress installation.

CSS is used both on the blog’s frontend and backend to format elements. Lets take a look at the new font of the WordPress 3.2 admin interface.

new wordpress font

To change the WordPress admin interface to this

you need to edit the file wp-admin.css located in the wp-admin/css directory. Make a backup of the file before you start editing it. Open it in your favorite text editor and search for the string #editorcontainer

You should see code that looks like the following:

#editorcontainer #content{font-family:Consolas,Monaco,monospace;padding:6px;line-height:150%;border:0

Notice the font-family setting? To change the font all you need to do is to add another font in front. I have added Verdana which you can see in the second screenshot of the admin interface. The code for Verdana would look like this

#editorcontainer #content{font-family:Verdana,Consolas,Monaco,monospace;padding:6px;line-height:150%;border:0

You can also change the padding and line-height there to get better values as well if you want.

I know that some of you may not be comfortable editing css files on their own. I have uploaded the new wp-admin.css file to my server, and you can download it from this link: wp-admin.css.

Just copy the file to the wp-admin/css/ section of your WordPress blog and you should see the new font when you reload the admin page. The only change in the file is the new font. If you want to change line height, padding or other values you need to do that on your own.

Update: Files and edits you need to edit have changed in WordPress 3.3.1 as John Petrie points out. It is now necessary to edit the wp-includes/editor-buttons.css file, and change the style information of wp-editor-area. Thanks John for posting your solution.

That’s good because the new version introduces new system requirements that webmasters should make sure their server supports, before they upgrade. WordPress 3.2 requires as a minimum MySql 5.0.15 and PHP 5.2.4. That’s a big step from MySQL 4.1.2 and PHP 4.3. Contact your hoster if you are not sure if you server supports the minimum requirements.

Experienced webmasters can also create a php file with <? PHPINFO(); ?> as the content and upload it to their server. The file displays the information, among many others, in the browser when opened there.

The highlights of WordPress 3.2 in 40 words or less: WordPress comes with a refreshed admin design, a full screen editor for distraction free blogging, a new default HTML5 theme and an extended admin bar.

There are other things, largely under the hood that will make webmasters happy. This includes faster page loading times, dropped support for Internet Explorer 6, additional performance and speed improvements and caching of admin dashboard widgets to reduce the site’s memory footprint.

The new admin interface seems to use new typography as well, at least in some parts. Especially the font in HTML editing mode feels strange with its white space between words and a new line height. Editors who switch to the visual mode on the other hand seem to get a default font (does anyone know if it is possible to change the font in WordPress admin?)

The update notifications are as usual available right on the admin backend of the blog. Webmasters can update their blogs from within their, if configured this way. This is the fastest update option. An alternative is the download of the new version from the official website and updating via ftp or sftp.

I have updated five blogs yesterday evening and the update went well without difficulties. I will now continue to upgrade my other twenty or so blogs, such fun..

WordPress 3.1.4. has just been released and the developers refer to it as a security and maintenance upgrade. The new version fixes one known vulnerability that “could allow a malicious Editor-level user to gain further access to the site”. If you are running a single author blog you are safe from this.

I’d still recommend to update the blog as soon as possible because of security hardening additions to the blogging platform.

The update is as usually available as a direct download, install and update from within the WordPress admin interface, and as a separate download from the official WordPress website. I have updated a total of five blogs so far – including Ghacks Technology News – and encountered no problems or issues after the update. While it may be to early to tell, it is relatively safe to say that the update won’t break the blog.

WordPress admins who are interested in all changes in the WordPress 3.1.4 release find them listed on WordPress trac.

The developers have furthermore released the third and final release candidate of WordPress 3.2 which will be released in the near future. While I would not suggest to update a public blog to that version yet, it is clear that it won’t be long until the final version is released. Likely again before my bedtime.

You find additional information about the features and changes in WordPress 3.2 on the official beta announcement post over at the WordPress website.

Have you updated your blogs yet? If so, have you encountered any issues with this update?

For example, many posts benefit from a nice, clean thumbnail seated just to the left of the title of your posts. Such images break up otherwise monotonous, similar posts into individual units with their own appearance and characteristics. They can make the difference between an unattractive blog blanketed in text and an interesting web magazine with illustrations.

To implement these thumbnails you need to tell WordPress to look for the specific images you want and then to add them itself. You can do this by creating a field in each post called customimage which, when found, will tell WordPress to make the image appear. On the off chance that you do not add the customimage field to a particular post, you want WordPress to instead display a default image.

To begin, select an image that you would like posts to display by default. This could be your face, your dog, a speeding car – really, it’s completely up to you. Open the image in your favorite editor (Gimp, Paint.net or any other image editor that you may have at your disposal) and set it to whatever pixel dimensions you prefer. Be mindful that regardless of how long your blog title is, your photo will always be the same size. Somewhere between 150 by 150 and 250 by 250 pixels is probably a safe bet, and square boxes are easier to place various images in later, as opposed to rectangular ones. Once you have a nice image name it something you can remember (standard.gif, default.gif, etc.).

Next, upload the default image into your theme’s image directory. This makes it available to all pages of your site and any post missing the customimage field.

Now for the important part: post the following code into the index.php file of your WordPress wherever you would like the thumbnails to appear:

<?php $postimageurl = get_post_meta($post->ID, 'customimage', true);

if ($postimageurl) {

?>

<a href="<?php the_permalink(); ?>" rel="bookmark"><img src="<?php echo $postimageurl; ?>" alt="Post Pic" width="200" height="200" /></a>

<?php } else { ?>

<a href="<?php the_permalink(); ?>" rel="bookmark"><img src="<?php bloginfo('template_url'); ?>/images/yourwebsite.gif" alt="Screenshot" width="200" height="200" /></a>

After you are finished copying over the code and pasting it in index.php, save the file. Your posts will now place whatever image you chose as your default (customimage) earlier beside each entry. That’s good, but you really want to be able to change that image – the point of this entire exercise is to make each post different.

All that you need to do is create a custom field with each entry called customimage (not in italics, of course). Change the value each time to the URL of whatever image you would like to display beside the particular post and you will be set to go. Enjoy having a unique thumbnail beside each post, unless you allow it to fall to the default.

Images clearly make for a more attractive blog post for the majority of readers. Are you one of those? Photos attract, so make sure that you blog is attractive and attracting.

Update from Martin:

You do not necessarily have to paste the code into index.php. You can alternatively paste it into single.php for individual posts, category.php for categories or tags.php for tags.

If you are not familiar with web development you may want to select a theme that supports post thumbnails out of the box. There are even some that take the first image of each post automatically and use it as the post thumbnail provided that you have not added a thumbnail image of your own to the post.

You also need to consider that images will increase the loading time of the site. If you have a slow loading site, it is probably best not to add more images to the blog, or at least not before you started to optimize the blog code for speed.

The WordPress blog lists the following security enhancements and fixes in WordPress 3.1.3.

• Various security hardening
• Taxonomy query hardening
• Prevent sniffing out user names of non-authors by using canonical redirects.
• Media security fixes
• Improves file upload security on hosts with dangerous security settings.
• Cleans up old WordPress import files if the import does not finish.
• Introduce “clickjacking” protection in modern browsers on admin and login pages.

Interested users can consult WordPress trac for detailed information on all fixes that have been applied to this release.

The developers have added quite some security hardening to the new release as you can see from the list of changes above. It is still recommended to update WordPress installations as soon as possible to improve security and close the security and privacy vulnerabilities fixed in the release.

Self-hosted WordPress blogs are already picking up on the update and notifying administrators in the dashboard about the update.

It is as usual possible to apply and install the WordPress update right from the admin dashboard, or by downloading the new release from WordPress to install it manually by uploading file to the server.

The WordPress Codex lists the file changes in this new release.

The WordPress developers suggest to update immediately, especially if users can register as contributors on the blog. WordPress 3.1.2 fixes several non-security related issues which you can see a list of at the issue tracker over at the WordPress website.

Nothing to spectacular fixed though, take a look below for the list.

• It’s tricky to drag metaboxes
• Apostrophe in first/last/nickname causes JS error on user profile page
• Missing closing </fieldset> in user-edit.php for “show admin bar”
• Multiple tag queries broken
• WP_User_Query ordered by post_count doesn’t work if prefix is not wp_
• WordPress 3.1.1 breaks date archive filtering by tag or category
• Walker_PageDropdown doesn’t filter titles correctly
• Too much escaping for pages when using Quick Edit

WordPress administrators can update their blogs either directly from the WordPress Dashboard with a click on the Update Automatically button, or by downloading the new release from the official WordPress website, uploading the files manually to the server and running the upgrade script afterwards.

I have just updated more than a dozen WordPress blog to version 3.1.2 and the automatic update worked without difficulties in every instance. WordPress admins should not encounter any page display problems on the frontend or backend after applying the update.

That alone should be reason enough to update WordPress to the latest version. The post mentions performance improvements without going into further details. It is therefor not clear if the improvements are measurable, and which areas of the platform have been improvement. The remaining changes list fixes for IIS6 support, taxonomy and pathinfo permalinks and various “query and taxonomy edge cases that caused some plugin compatibility issues”.

Update notifications are not displayed on all WordPress blogs yet. Webmasters should click on Dashboard > Updates to force WordPress to check for new updates. The WordPress 3.1.1. release should be listed on that page then. It is then possible to update the WordPress blog automatically from within the admin interface, or to download the new release and update the blog manually by uploading all files to the server and running the wp-admin/update.php script afterwards.

I have just finished updating 20 different WordPress blogs and the automatic updating worked on all but one without errors or problems. The one blog is a special case and it is likely that a plugin or special script interfered with the update.

The latest version of WordPress can be downloaded from this page.

Webmasters can do several things to reduce the page loading time of their websites. Services, such as Page Speed, GTMetrix or various browser add-ons aid in finding the page elements that take the longest to load.

Images that have not been optimized are usually listed as a recommendation. Optimized in this regard means a reduction of an image’s size without a reduction in image quality.

WordPress blog owners can install the free WordPress plugin WP-Smush.it that uses Yahoo’s Smush.it service to reduce the size of images. The plugin works automatically in the background: It sends all uploaded images to Yahoo’s image compression service and uploads that optimized version to the server, instead of the unoptimized original version.

It furthermore allows to optimize already uploaded images. WordPress users need to go to Media > Library where they see a Smush.it column next to each uploaded imaged and a link to Smush.it now!.

A click on the link sends the individual image to the Smush.it service where it will be processed and then re-uploaded to the web server.

The size reduction depends largely on the original state of the image. It usually ranges between 0% to 30%.

A big usability issue is that there is no option to mass optimize existing images. We host more than 10,000 images here at Ghacks and optimizing them all individually would be to time consuming.

While it is possible to download and optimize the images locally, or run an external optimization script, it is also possible to utilize the Firefox add-on Multi Links, or one of its alternatives, to speed up the image processing.

Multi Links users can select all links on a media library page at once. For this they need to install the Firefox add-on first. They can then hold down the right mouse button to draw a rectangle around all Smush.it links on the WordPress library page to execute all of them at once. This works very well. All links are opened in new tabs that can be closed after they have loaded.

What I could not figure out at first was how to use custom headers for each category. Headers in WordPress contain all the HTML head information, like meta tags and the page’s title, and often the site’s logo and main navigation.

Before I go into details I’d like to explain how to create custom category pages. This works similar to creating custom tag pages. You basically copy and rename the standard category.php file of WordPress, and name it category-name.php where name is the name of the category. A custom template for the Firefox category here at Ghacks would have the name category-firefox.php, one for the Operating Systems category category-operating-systems.php

You can then edit the code of each category page individually, for instance by adding category specific information or images to the category listing.

A big problem, from a search engine optimization perspective, is that it is not possible to define custom head information for each custom category page. Why is that a problem? Because you cannot define meta tags and description or the page title in WordPress. Sure, you can modify the category name to a suitable one to get the page title you want, but this one shows up everywhere on your blog where you reference the category, not only as the title (for instance in the category listing in the sidebar).

This was not an option after all. After some dabbling and searching I came up with the perfect solution to use custom headers for the categories here at Ghacks. It again means that you have to copy and rename files but the solution works nicely and has been tested extensively.

Copy the WordPress header.php file and rename it. You are free to name it anyway you want, I suggest to name it header-categoryname.php for easier identification.

You should now have two header files in the WordPress theme folder, in my case they are named header.php and header-firefox.php.

Modify header-firefox.php as you see fit, you can for instance add meta descriptions, modify the page title or add a custom header image to it.

All that’s left now is to link that custom header to the custom category file. Open the custom category file, in my case it is category-firefox.php.

You should see <?php get_header(); ?> at the very top. This command tells WordPress that it should load the default header. We now replace that command to make WordPress load the custom header file instead.

<?php
include(TEMPLATEPATH.'/header-firefox.php');
?>

You need to modify the header-firefox.php part with the name of your category page, but that’s the only change.

This command tells WordPress to load the custom header if that category page is opened by a visitor of the website. And that’s basically it. Now you need to repeat the process for all remaining categories that you would like to add a custom header to.

The very same principle works for tags and pages as well.

The update is not a security update which means that there is no rush to install it directly.

Among the new features is the option to link to existing content easier. This is done via the standard link button in the WordPress writing panel and the selection of “Or link to existing content”.

It is possible to search for related content or select one of the most recent items. The writing interface has been overhauled. The developers have many interface elements that were shown by default of the screen which should be beneficial to new users. All writing elements can be added again via the Screen Options at the top of the page.

Another addition is the new admin bar that is displayed to WordPress administrators when they navigate the WordPress frontend. The bar is actually not displayed on all of my blogs right now. I’m not sure why that is the case (likely because of CSS minifying or merging) but there is thankfully a way to disable the admin bar.

Open Users > Your Profile and locate Show Admin Bar near the top.  Remove the checkmark from “when viewing site” to disable it.

Other noteworthy features are:

• post formats, meta information used by themes
• network admin, moves the Super Admin menu out of the regular admin interface
• list-type admin screens, now sortable by column, better pagination
• exporter / importer, was overhauled.
• advanced queries, again something for developers
• custom content type improvements, again developer related
• refreshed blue admin color scheme

Interested users can visit the WordPress Codec for an in depth overview of all the features that have been added, improved or changed in the recent release.

WordPress administrators can upgrade their blog to WordPress 3.1 either directly from within the admin interface or by downloading WordPress 3.1 from the official website and installing the new version manually.

One such tool allows me to blog to my various blogs quickly. I want to introduce you to this tool so that you are quickly blogging from your GNOME desktop.

Compatible blogs

Naturally you can’t expect GNOME Blog to handle every type of blog in the blogosphere. But it does handle:

• blogs.gnome.org
• Blogger
• Livejournal
• Avogato
• Self-run WordPress
• Self-run Moveable Type
• Self-run Pyblosxom

Obviously each type of blog will have different setup requirements. Let’s examine how to connect GNOME Blog to a self-run WordPress blog.

Configuring WordPress

Figure 1

In order to blog to WordPress from GNOME Blog you have to enable remote publishing via XML-RPC. Without this set, you will not be able to blog from outside of the web interface. To configure this option you must first log on to your WordPress blog (with administration rights) and then click on Settings > Writing. In that section (near the top) you will see the spot where you can enable this (see Figure 1).

Once you have checked off the box associated with XML-RPC, scroll down and click Save Changes.

Now let’s install and use GNOME Blog.

Installation

Installation is simple. I will demonstrate the installation on a Ubuntu 10.10 desktop. Follow these steps:

1. Open up the Ubuntu Software Center.
2. Search for the term “blog” (No quotes).
3. Click the Install button associated with GNOME Blog.

That’s it. You will now find the tool in Applications > Internet > Blog Entry Poster.

Using GNOME Blog

Figure 2

When you fire up GNOME Blog click on the Preferences window so you can choose the type of blog you want to write to. From this new window (see Figure 2) select “Self-Run WordPress” from the Blog Type drop-down and then fill in the rest of the information.

You will not be able to select the Blog Name from the drop-down until you have configured the URL, username, and password. Once you have done that click Lookup Blogs and select the blog you want to post to from the drop-down.

Once you have selected your blog, click the Close button, and you’re ready to begin.

Posting

Figure 3

Posting with GNOME Blog is simple. From the main window (see Figure 3) you can enter a title and the body of your blog. You can also add a link into the body of the blog by clicking the Add Link… button and entering the link title and url.

Upon completion of your blog entry, click the Post Entry button and your blog post will make its way through the ethernet to your blog.

Final thoughts

It should be obvious that you can not do much as far as formatting, adding images, and the like. But for simple text-based blog posts, you can’t beat the simplicity and ease of use of GNOME Blog.