There are countless posts in the WordPress.org forums about errors that occur when using the media uploader.

Otto does a pretty good job of outlining the main issues and solution in this post.

In my experience these errors usually occur because of your server setup or memory issues. To help you diagnose where your problem lies:

1. If the file appears to upload and then you get an HTTP Error, this is most likely your server settings preventing you from uploading or processing large files in some way.

2. If you get as far as “Crunching…” being displayed, this is most likely a memory issue – the image is so big that the server struggles to create the other images sizes. Also note that it is often the actual physical dimensions of the image not the filesize that is too big and causes the memory issue.

MaxLen

The most recent occasion when I ran into this issue was on a 1&1 Virtual Server. None of the fixes I could find solved my issue and I eventually tracked it down to needing to increase to MaxLen setting on the server.

The Solution

To do this I needed to add the following into the vhost.conf file on the server. My vhost.conf file was located here:

/var/www/vhosts/domain.com/conf/vhost.conf

The following sets to value to 31457280 bytes which is 30MB:

<IfModule mod_fcgid.c>
FcgidMaxRequestLen 31457280
</IfModule>

I also added some additional settings to help with timeout issues:

<IfModule mod_fcgid.c>
FcgidMaxRequestLen 31457280
ProcessLifeTime 7200
IPCCommTimeout 7200
IPCConnectTimeout 300
</IfModule>

Then I needed to tell Plesk to update it’s information but running the following:

# /usr/local/psa/admin/sbin/websrvmng -u --vhost-name=domain.com

This configures Plesk only for one single domain, in this case domain.com. If you want to configure it for all sites run:

# /usr/local/psa/admin/bin/websrvmng -a

All done.

The latest version of WP e-Commerce (3.8.x) for WordPress is a significant move on both in terms of stability and extensibility.

This is partly down to an extensive re-build on the codebase to take advantage of some of WordPress’ latest features; custom post type and taxonomies. This has the added benefit of making it much easier for plugin developers to create add-on plugin to enhance WP e-Commerce functionality.

The key objectives now seem to be to keep WP e-Commerce ‘lean and mean’ to provide a solid platform on which to develop WordPress-based e-commerce sites, and provide additional functionality through plugins.

Part of this process includes stripping out some of the less-used parts of WP e-Commerce and turning them into plugins. Once such example is the automated ‘Also Bought’ functionality which can be found in the Marketing tab of WP e-Commerce settings.

I have worked extensively with WP e-Commerce over the last 2-3 years and frequently try to get involved wether it be fixing the odd bug or helping out on the forum – when I have time ;) so I jumped on board to help separate the ‘Also Bought’ functionality into a WordPress plugin.

Also Bought > Cross Sales

The ‘Also Bought’ functionality is now available to download as the ‘Cross Sales’ plugin on WordPress Extend.

The plugin will function exactly the same way as the current Also Bought feature in WP e-Commerce. When someone buys multiple products, this information will be saved so that we can identify that “someone who bought this also bought that”.

There are few small additions though:

You will be able to set a limit for the amount of cross sales you want to show – what looks best may  depend on the theme you are using.

By default, cross sale product images will be the same size as product thumbnail images, but there are now settings to override this if you want.

Installing/Upgrading

In WP e-Commerce 3.9 the also bought functionality will not be available by default, you’ll need to install the plugin. For those of you who are already using that functionality, don’t worry, I’ve made it easy for you… you’ll be able to install the plugin directly from the Marketing tab in WP e-Commerce and have it back up and running straight away.

You can even install the plugin now if you like. It won’t do anything until you upgrade to WP e-Commerce 3.9 and the transition will be seamless.

I recommend that you change the wpsc_also_bought() references in your single product theme template to the following:

<?php if ( function_exists( 'wpsc_cross_sales' ) ) wpsc_cross_sales( $product_id ); ?>

This will ensure compatibility in the future if you deactivate the plugin, and ensure it works with future versions. You don’t need to change this as the wpsc_also_bought() function should work for the time being, but it will cease to work in a future version of this plugin so do get around to changing it sooner rather than later.

What next…?

Expect to see other areas of WP e-Commerce being moved to separate plugins. My guess is the following features may at some point find themselves moved to external plugins:

• Social Integration, Like, Tweet etc…
• Intense Debate comment integration
• Custom survey
• Off site product links
• Personalisation options

You may (or may not) have noticed that in WordPress if you want to insert an image gallery into your post it does not give you the option of insert a gallery only 1 column wide.

This seems like an oversight. I have seen loads of photo and inspiration blogs around that often include multiple images in a single column so it would seem that being able to easily insert a single column gallery would be a useful feature.

Fortunately it is possible to insert a gallery one column wide, just not through the popup media window. Here’s how…

How to insert a single column gallery

It’s just a simple shortcode:

[gallery columns="1"]

Unfortunately in the Visual editor, when you go back to edit your post the gallery shortcode will be displayed as a gallery preview. If you click the gallery edit button (top left) then the media window will pop up but the columns menu will default to 3 as there is no value of 1.

So, what’s the fix?

It’s a change to WordPress core code but it’s really simple. Just edit wp-admin/includes/media.php and around line 1818 insert an select menu option with a value of 1.

1817
1818
1819
1820
1821

<select id="columns" name="columns">
	<option value="1">1</option>
	<option value="2">2</option>
	<option selected="selected" value="3">3</option>
	<option value="4">4</option>

I’ve submitted a WordPress patch here. If you would like this change to be made to WordPress please add your support to the Trac ticket.

When registering a new custom post type in WordPress, there are a whole array of labels you can set for how your post type will be displayed in the admin.

The post type I was creating had quite a long descriptive label which was fine in most scenarios but in the case of the main admin menu it pushed the menu text onto several lines.

See the example on the left below – I have deliberately shown any extremely long title to illustrate the point.

It would be really useful to have an extra label for ‘menu-name’ so that you can use a different title for the menu item as illustrated in the example on the right.

I have submitted a WordPress patch which Andrew Nacin seems to have taken under his wing. You can follow the progress of the patch here.

I frequently install HeadSpace, the WordPress SEO plugin by John Godley, when I work on a WordPress site.

Recently I have been making use of the new custom post type features of WordPress 3.0 but found that the HeadSpace meta box for editing the title and description tags did not show on my custom post type edit screens.

After a bit of delving through the code I figured out the way to do this – note that this may only work if your custom post type uses the default post capabilities.

It checks that the HeadSpace class is available and if so adds the meta box to your custom post type edit screen. Just add the following code into your plugin or theme’s functions.php file replacing ‘myposttype’ with your custom post type.

/**
 * Add Headspace plugin support for myposttype
 */
function myposttype_headpspace_add_custom_box() {
 
	global $headspace2;
 
	if ( function_exists( 'add_meta_box' ) && is_object( $headspace2 ) ) {
		add_meta_box( 'headspacestuff', __('HeadSpace', 'headspace'), array( &$headspace2, 'metabox' ), 'myposttype', 'normal', 'high' );
	}
 
}
add_action( 'wp_print_scripts', 'myposttype_headpspace_add_custom_box' );

I recently tried out Joost de Valk’s Google Analytics for WordPress (version 4) and was happy to see it supported ecommerce tracking for WP e-Commerce.

I had the latest version of WP e-Commerce installed, version 3.7.6.7, and configured the analytics plugin to track transactions but for some reason my ecommerce purchases were not being tracked by Google Analytics.

I did a bit of digging around and discovered the Analytics plugin was looking for the global variable $cart_log_id from which it could get the transaction details, but this variable did not seem to exist (it did seem to be in pre 3.7.6.x versions of WP e-Commerce though).

I have submitted a patch for this for the forthcoming WP e-Commerce version 3.8 (which is currently in beta and looking great, by the way).

In the meantime, if you’re having this problem here’s how you can fix it…

The Fix

You’ll need to get your hands a little bit dirty, but fortunately you only have to edit one file. In the WP e-Commerce plugin folder open the transaction_results.php file.

Step 1

Change the first line that defines global variables to add the $cart_log_id variable:

2

global $wpdb, $user_ID, $nzshpcrt_gateways, $sessionid, $cart_log_id;

Step 2

At the end of the file just before the closing php tag we’ll query the database to get the $cart_log_id that will be used by the analytics plugin:

46
47

$cart_log_id = $wpdb->get_var( "SELECT `id` FROM `" . WPSC_TABLE_PURCHASE_LOGS . "` WHERE `sessionid`= " . $sessionid . " LIMIT 1" );
?>

…and hopefully that should fix it.

I haven’t tested this for all versions of WP e-Commerce but it should certainly work on the latest 3.7.6.7 version.

Was just browsing WordPress.org and got this server error message.

Matt, if there’s a WordPress problem is it always your fault?
Made me chuckle ;)

I recently noticed that WordPress does not seem to add style classes to the body tag for custom taxonomies in the same way that it does on category archives.

You can fix this by adding the following to your functions.php file.

function taxonomy_body_class( $classes ) {
	if ( is_tax() ) {
		$tax = get_query_var( 'taxonomy' );
		$term = $tax . '-' . get_query_var( 'term' );
		$classes = array_merge( $classes, array( 'taxonomy-archive', $tax, $term ) );
	}
	return $classes;
}
add_filter( 'body_class', 'taxonomy_body_class' );

I don’t know why WordPress doesn’t do this automatically – I guess it should be added to core. What do you think?

Getting to grips with custom post types in WordPress 3.0?

I am, and am finding they’re a great way to organise different content on your site and very easy to implement in just a few lines of code.

However, the challenge now is for plugin developers to make their plugins play nice with custom post types. The main thing I’ve noticed so far is that most plugins only tend to add meta boxes to posts and pages, so here’s the first step – getting your WordPress plugin meta boxes to work with custom post types.

A Real World Example

I needed to set some of my custom post type pages not to be indexed by search engines so I picked out the Robots Meta plugin by Joost de Valk – the best plugin for the job in my opinion – installed it, and found it was only showing a meta box when editing my posts and pages.

I’m going to use Joost’s plugin (version 3.3.1) to illustrate how you can get meta boxes to show for custom post types so download it and continue reading below.

The Meta Boxes

The file you’ll need to edit is robots-meta.php. The meta boxes are added to posts and pages by the meta_box function on line 24:

24
25
26
27

function meta_box() {
	add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'post','side');
	add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'page','side');
}

Meta Boxes for Custom Post Types

Firstly we’re going to check that the ‘get_post_types’ function exists. If it does then we’ll loop through all the post types and add meta boxes. If not we’ll continue just to add for posts and pages.

24
25
26
27
28
29
30
31

function meta_box() {
	if ( function_exists( 'get_post_types' ) ) {
		// Handle posts, pages and custom post types here
	} else {
		add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'post','side');
		add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'page','side');
	}
}

The next step is to get all the post types that have been registered – this will include the built-in post types for posts and pages. We then loop through them:

$post_types = get_post_types( array(), 'objects' );
foreach ( $post_types as $post_type ) {
	// Handle each post type here
}

Then for each post type we are going to add a meta box. It is import to note that when you add a custom post type you can choose wether or not to automatically create the WordPress UI in the admin. We only want to add meta boxes if the UI is generated by WordPress so we add in an ‘if’ statement to check.

24
25
26

if ( $post_type->show_ui ) {
	add_meta_box( 'robotsmeta', 'Robots Meta', array( 'RobotsMeta_Admin', 'noindex_option_fill' ), $post_type->name, 'side' );
}

The Finished Function

So put all that together and this is what you get:

24
25
26
27
28
29
30
31
32
33
34
35
36

function meta_box() {
	if ( function_exists( 'get_post_types' ) ) {
		$post_types = get_post_types( array(), 'objects' );
		foreach ( $post_types as $post_type ) {
			if ( $post_type->show_ui ) {
				add_meta_box( 'robotsmeta', 'Robots Meta', array( 'RobotsMeta_Admin', 'noindex_option_fill' ), $post_type->name, 'side' );
			}
		}
	} else {
		add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'post','side');
		add_meta_box('robotsmeta','Robots Meta',array('RobotsMeta_Admin','noindex_option_fill'),'page','side');
	}
}

Please Note: This only deomstrates how you can add meta boxes for custom post types. There are other aspects such as checking user capabilities for different post types that may be applicable when you are saving your meta box data. See the capabilities arguments you can set in the register_post_type function.

WP e-Commerce 3.7.6 now includes better support for paging on category pages.

The latest release contains a suite of functions (my little contribution) to help you customise how pagination is displayed in your WPSC templates.

You can find an in-depth look at these functions and how to use them in the WP e-Commerce Documentation.

Below are some quick examples of what you can do…

Basic paging

Some fairly standard paging with linked page numbers, previous and next links, and arrow links to take to to the first and last pages. You can customise the text that is used for previous, next, first and last links.

<?php echo wpsc_first_products_link( '&laquo;', true ); ?>
<?php echo wpsc_previous_products_link( 'previous', true ); ?>
<?php echo wpsc_pagination(); ?>
<?php echo wpsc_next_products_link( 'next', true ); ?>
<?php echo wpsc_last_products_link( '&raquo;', true ); ?>

Limit the amount of pages

You can limit the amount of page links to show at one time. The above example shows what happens if there are 10 pages of products, but only showing 7 page links at a time. Notice also the text describing which page you’re on and that the previous and first links are greyed out when not applicable – you can also choose to hide them instead of showing inactive links.

Page <?php wpsc_showing_products_page(); ?>:
<?php echo wpsc_first_products_link( '&laquo;', true ); ?>
<?php echo wpsc_previous_products_link( 'previous', true ); ?>
<?php echo wpsc_pagination( 7 ); ?>
<?php echo wpsc_next_products_link( 'next', true ); ?>
<?php echo wpsc_last_products_link( '&raquo;', true ); ?>

Total number of products

There is a function to easily display the total number of products. You can detect if the category has multiple pages and if it doesn’t display something like this instead.

<?php if ( wpsc_has_pages() ) : ?>
   <!-- Insert pagination for multiple pages -->
<?php else : ?>
   Showing <?php echo wpsc_total_product_count(); ?> products
<?php endif; ?>

Number of products showing

You can display an indication as to which products are showing depending on which page you’re viewing.

Showing <?php echo wpsc_showing_products(); ?> of <?php echo wpsc_total_product_count(); ?> products:

What next?

The new WP e-Commerce default themes contain examples of pagination so hop into your templates and create some nice pagination…

I had a bit of a problem recently trying to convert a WordPress .htaccess file to a rewrite.script file for a Zeus server. My knowledge of the syntax for rewrite.script was non-existant so I tried the .htaccess converter provided in the Namesco admin.

This managed to get me part of the way there but the permalinks included “index.php” before the custom permalink setting.

Hunting around I found this blog post by Adam Christie in which he documents a rewrite.script for WordPress – and it works! I have provide the code below for your reference.

RULE_0_START:
# get the document root
map path into SCRATCH:DOCROOT from /
# initialize our variables
set SCRATCH:ORIG_URL = %{URL}
set SCRATCH:REQUEST_URI = %{URL}
 
# see if theres any queries in our URL
match URL into $ with ^(.*)\?(.*)$
if matched then
set SCRATCH:REQUEST_URI = $1
set SCRATCH:QUERY_STRING = $2
endif
RULE_0_END:
 
RULE_1_START:
# prepare to search for file, rewrite if its not found
set SCRATCH:REQUEST_FILENAME = %{SCRATCH:DOCROOT}
set SCRATCH:REQUEST_FILENAME . %{SCRATCH:REQUEST_URI}
 
# check to see if the file requested is an actual file or
# a directory with possibly an index.  don’t rewrite if so
look for file at %{SCRATCH:REQUEST_FILENAME}
if not exists then
look for dir at %{SCRATCH:REQUEST_FILENAME}
if not exists then
set URL = /index.php?q=%{SCRATCH:REQUEST_URI}
goto QSA_RULE_START
endif
endif
 
# if we made it here then its a file or dir and no rewrite
goto END
RULE_1_END:
 
QSA_RULE_START:
# append the query string if there was one originally
# the same as [QSA,L] for apache
match SCRATCH:ORIG_URL into % with \?(.*)$
if matched then
set URL = %{URL}&%{SCRATCH:QUERY_STRING}
endif
goto END
QSA_RULE_END:

By default the terms and conditions link on the checkout page in WP e-Commerce activates an overlay popup containing the terms and conditions text you have specified in the admin.

But what if you want the link to redirect to a page instead of triggering this popup? You just need to make a small change to your checkout template. Here’s what you need to do…

In The Admin

In the admin, instead of specifying terms and conditions text we are going to enter a URL. Make sure your URL is a full path including ‘http://’ as this will make it easier to detect wether the content is a URL or plain text.

Changes in your WP e-Commerce Theme

Your WP e-Commerce theme files usually reside in the ‘wp-content/uploads/wpsc/themes/your-theme’ directory. To change the terms and conditions link to link to another page rather that popup you will need to edit the ‘shopping_cart_page.php’ file.

In this file look for the terms and condition code. It will be near the bottom and should look a bit like this:

297
298
299
300
301
302
303

<?php if(get_option('terms_and_conditions') != '') : ?>
<tr>
   <td colspan='2'>
      <input type='checkbox' value='yes' name='agree' /> <?php echo TXT_WPSC_TERMS1;?><a class='thickbox' target='_blank' href='<?php echo get_option('siteurl')."?termsandconds=true&amp;width=360&amp;height=400'"; ?>' class='termsandconds'><?php echo TXT_WPSC_TERMS2;?></a>
   </td>
</tr>
<?php endif; ?>

What we will do is change this code so if the contents of your terms and condition is a link (beginning http://) it will write a link to that page rather than a popup. The new code with the if statement should look like this:

297
298
299
300
301
302
303
304
305
306
307
308

<?php if ( get_option('terms_and_conditions') != '' ) : ?>
<tr class="terms">
   <td colspan='2'>
      <input type='checkbox' value='yes' name='agree' /> <?php echo TXT_WPSC_TERMS1;?>
      <?php if ( substr(get_option('terms_and_conditions' ), 0, 7) == 'http://' ) { ?>
         <a target='_blank' href='<?php echo get_option('terms_and_conditions'); ?>' class='termsandconds'><?php echo TXT_WPSC_TERMS2;?></a>
      <?php } else { ?>
         <a class='thickbox' target='_blank' href='<?php echo get_option('siteurl')."?termsandconds=true&amp;width=360&amp;height=400'"; ?>' class='termsandconds'><?php echo TXT_WPSC_TERMS2;?></a>
      <?php } ?>
   </td>
</tr>
<?php endif; ?>

And that’s all there is to it.

Just released an update to the List Pages at Depth plugin for WordPress.

This update fixed a pretty major bug which prevented the list showing the correct branch of subpages when the start depth was greater than 1 (secondary level pages).

Now this is fixed you’ll be able to display a list of only tertiary level pages – Useful if you have a site with a horizontal navigation with drop down menus for secondary level navigation, and want to show and subpages of the secondary level as a list in your sidebar.

What’s more the plugin now includes a widget so you can easily add a list of subpages into your sidebar.

Widget Examples

The following configuration will display a list of secondary and tertiary level pages (depths 1 to 2) for the currently selected primary navigation item. The list of pages will show for all pages that are subpages (or sub-subpages) of that primary page.

The widget below will only display the tertiary level (depth 2) of navigation for subpages of the currently selected secondary level page.

There are many occasions when you may want to create multiple WordPress Loops – instructions on how to do this can be found on the WordPress Codex.

If you need to keep the original query, it is suggested you create you second loop by creating a new query object.

<?php $my_query = new WP_Query('category_name=special_cat&posts_per_page=10'); ?>
<?php while ($my_query->have_posts()) : $my_query->the_post(); ?>
   <!-- Do special_cat stuff... -->
<?php endwhile; ?>

This works fine, but if you use more template tags after this loop, they display the content from the last post in the $my_query loop. So, if you want to reference the original loop how should you go about it?

What’s going on?

In the above example the $my_query variable is an instance of the WP_Query object containing the results of the custom query.

The ‘while’ loop iterates through all the results of our query. Each time $my_query->have_posts() is called it checks wether the next post in the loop exists and if it does the loop continues to run.

For each post in the loop the $my_query->the_post() function is called. This populates the global $post variable with the post data which can then be accessed directly through the $post variable or using WordPress template tags like the_title() and the_content();

After the $my_query loop has finished the global $post variable remains populated with the last post from the $my_query loop so any template tags used will use this post’s data, not the data from the post before we started our custom loop.

So what should we do?

Because we created a new query $my_query, the previous query still exists in the main $wp_query variable, so all we have to do is repopulate the $post variable using $wp_query and setup the post data again.

<?php
$post = $wp_query->post;
setup_postdata( $post );
?>

Could this be made more easy?

Not really, but maybe a WordPress template tag to do this should be added to WordPress core – maybe somthing like refresh_post(). This can then be documented in the Codex to provide an ‘official’ way of handling multiple loops.

What do you think?

I was just about to update an old plugin I created to create an XML site map for products in WP e-Commerce…

…then I stumbled across the WP e-Commerce XML Sitemap plugin by Lee Willis.

The plugin worked well with WP e-Commerce 3.7.5 (the latest version) apart from a few minor issues. I got in touch with Lee and suggested a few tweaks/fixes – he has just released an updated version:

• Unpublished products are now not added to sitemap.
• Is now compatible with WordPress installations with custom table prefix.

You can download the latest version here…

The latest version of Instinct’s WordPress e-commerce plugin uses the WordPress body_class filter to add classes to the HTML body tag.

WP e-Commerce 3.7.5 adds the following styles to the body tag:

• wpsc
• wpsc-home
• wpsc-single-product
• wpsc-single-product-id
• wpsc-category
• wpsc-category-id
• wpsc-group-id
• wpsc-shopping-cart
• wpsc-transaction-details
• wpsc-user-account

These extra classes will give you more flexibility when designing themes for WP e-Commerce.

Where are these classes included?

wpsc
Included in every WP e-Commerce page.

wpsc-home
Included on the main WP e-Commerce shop page.

wpsc-single-product & wpsc-single-product-id
Included on single product pages. The wpsc-single-product-id class allows you to set css rules for a single product based on the product id.

wpsc-category & wpsc-category-id
Included on category and individual product pages. The wpsc-category-id class allows you to set css rules for different categories. As these classes are also applied to single product pages, if a product appears in more than one category you could style a product page differently depending on which category you click through from.

wpsc-group-id
Included on category and single product pages. The group id is set based on the group in which the current category resides.

wpsc-shopping-cart
Including on the shop cart checkout page.

wpsc-transaction-details
Including on the transaction details page displayed after a successful purchase.

wpsc-user-account
Including on the WP e-Commerce user account pages.

Ideas how to use these classes in your WP e-Commerce theme…

1. Style a special product differently using wpsc-single-product-id.
2. Style products in a sale category to display differently using wpsc-category-id.
3. Create a group for brands with brands as sub-categories and differentiate this view from your standard product categories using wpsc-group-id.

I’ve been using the WP e-Commerce plugin for WordPress a lot recently and delving behind the scenes to make it do want I want it to. In the process I have submitted a couple of style changes to the core to style it to be more like WordPress out-of-the-box.

One thing I think should be changed to bring the product edit screen in-line with the WordPress post/page editing layouts is the separation of the Categories and Tags boxes.

How things are…

The WordPress post/page edit screen looks like this:

Currently, editing Categories and Tags in WP e-Commerce looks like this:

How I think things should be…

A few times I have run into problems with the current WP e-Commerce categories and tag box in that if I have long category names, they wrap very badly on smaller screens where there isn’t much space – the tags filed squashes everything over to the left.

I propose that the categories and tags box be separated into a similar layout to the way WordPress does things. This would add UI consistency throughout the admin and the boxes would be expandable allowing you to easily minimise the tags box if you only use it infrequently.

So you would end up with something like this:

It is essentially a mirror version of the panels in the main WordPress admin but with some of the extra functionality removed.

In WP e-Commerce it is possible to have multiple types of category grouping such as Categories and Brands. In this scenario I would suggest that the scrolling categories area in the Categories box (illustrated above) is duplicated so that there are two scrolling areas – one for categories and one for brands.

So, what do you think?

That’s just my opinion so please vote and leave your comments below and who knows, if enough of you like my idea then it might find it’s way into a future release of WP e-Commerce.

A great feature being worked on for a future version of WordPress (hopefully 2.9) was added to the the development version today.

The ‘Trash’ functionality will work in the same way as your Mac or the Recycle bin on Windows – when you delete an item, it will be moved to the Trash from where it can be recovered or permanently deleted.

The functionality is currently being tested out with comments and hopefully if it works well will be roled out to other WordPress assets like post, pages and links.

So no more impulse deleting of something, then wishing you hadn’t… Phew!

One plugin I recommend that everyone should add to their WordPress installation is the Google XML Sitemaps plugin.

This plugin will automatically generate an XML sitemap of your posts and pages and ping supporting search engines to notify them that the sitemap has been updated.

But the best thing about this plugin for other plugin developers is it provides hooks so you can ‘borrow’ it’s functionality so that your plugin can add additional pages into the XML sitemap that is generated.

So if you’re a WordPress plugin developer, read on…

How to add pages to the XML sitemap

To illustrate how to implement the XML Sitemaps hook, I will base the example on the WP e-Commerce plugin (please note, I originally implemeted this with version 3.6.12 of the WP e-Commerce plugin so it may not work with more recent versions). We will create a function that will add all of this plugin’s product pages into the XML sitemap produced by Google XML Sitemaps.

The Google XML Sitemaps plugin provides the hook “sm_buildmap” which gets triggered whenever the plugin re-builds the sitemap file. We are going to create a function “wp_ecommerce_sm” which will get called by this hook.

So, here’s the function code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function wp_ecommerce_sm() {
   global $wpdb;
   if ( class_exists('GoogleSitemapGenerator') ) {
      $generatorObject = &GoogleSitemapGenerator::GetInstance();
      $sql = "SELECT DISTINCT * FROM `" . $wpdb->prefix . "product_list` WHERE `active` IN('1') ORDER BY `id` DESC";
      $product_list = $wpdb->get_results($sql, ARRAY_A);
      foreach ( $product_list as $product ) {
         $purchase_link = wpsc_product_url($product['id']);
         $purchase_link = str_replace('&', '&', $purchase_link);
         if ($generatorObject != null) $generatorObject->AddUrl($purchase_link, time(), "daily", 0.5);
      }
   }
}
add_action("sm_buildmap", "wp_ecommerce_sm");

The main points to note in this function are…

Check that the Google XML Sitemaps exists (is installed):

3

if ( class_exists('GoogleSitemapGenerator') ) {

Get an instance of the Google XML Sitemap plugin:

4

$generatorObject = &GoogleSitemapGenerator::GetInstance();

Loop through all our additional pages that we want to add to the sitemap, in this case the WP e-Commerce product pages:

5
6
7
8
9

$sql = "SELECT DISTINCT * FROM `" . $wpdb->prefix . "product_list` WHERE `active` IN('1') ORDER BY `id` DESC";
$product_list = $wpdb->get_results($sql, ARRAY_A);
foreach ( $product_list as $product ) {
   // Add pages to sitemap here
}

And within our loop, add our pages like this:

10

if ($generatorObject != null) $generatorObject->AddUrl($purchase_link, time(), "daily", 0.5);

And lastly we need to add the hook to call this function whenever the XML sitemap is rebuilt:

add_action("sm_buildmap", "wp_ecommerce_sm");

Is that all there is to it?

Well, not really. Your still have to trigger the sitemap to re-build to include your new pages. You can do this manually by going to your XML Sitemaps setting page and clicking the link to rebuild to force the sitemap to re-build. Ideally however you would try to get your plugin to do this automatically whenever you add/edit/delete one of your pages. I couldn’t find an obvious hook to easily do this so that is something I would like to see adding in a future version of the Google XML Sitemaps plugin.

Download

Download the above code packaged as a WordPress plugin using the link below:

I love the new widgets API in WordPress 2.8

I followed the excellent tutorial at WPengineer.com which gives a great overview about how to create a widget using the new API. Initially, the widget I created by following the guide seemed to ‘crash’ WordPress when I installed it. After a little investigation I tracked this down to the following…

1
2
3
4

function widget_myuniquewidget_register() {
   register_sidebar_widget('My Unique Widget','widget_myuniquewidget');
}
<strong>add_action('init', widget_myuniquewidget_register);</strong>

You must initialise the register_sidebar_widget function by hooking into the ‘init’ action. Failure to do so means the function is called too early which will cause problems. For more information read WordPress Widgets API on the WordPress Codex.