3.8 permalinks and product category feedback

Hi everyone,

So 3.8 is getting a lot of traction these days, and we are working non stop on getting this to a beta sometime soon. One of our community members working on the project noticed an issue regarding Product Categories and Permalinks.

In 3.7 which everyone is familiar with the checkout page was a child page of the products-page. This worked well, and most people seeme happy with it. In 3.8 we are utilizing custom taxonomies for Product Categories (Yay), the problem however arises when you use a custom permalink such as /%postname%/


You get a 404 on checkout page 🙁 why? because WordPress interprets yoursite.com/products-page/checkout as ‘You are looking for a product category of ‘checkout’ which is , well, not the case. It took a long time for the said community member (Lee Willis) to figure this out, and I’d like to say a big thank you to him for his dedication to the cause!

As part of his investigation he proposed 2 options which we would like your opinion on. We want to implement this as soon as possible so we can keep digging through the code and making sure everything is hunky dory.

Solution #1

Append ‘Something’ between products-page and product category name. i.e yoursite.com/products-page/cat/product-category where cat is just a random text, (if you like this idea, what would you like that text to be?)

Solution #2

Move the Checkout Page and all other ‘child pages’ from being under products-page so they are no longer sub-pages.

My humble opinion, is that Solution #1 would be slightly more robust (how many people upgrading their sites would really want to have to move their checkout page to top navigation?) What if someone wants to have sub-pages under their products-page (i.e pages with shortcodes of different categories?) they won’t be able to cause they would get the dreaded 404… There would be ways around this, but do we really want to go that route?

Hence we ask you, users of wp-e-commerce? Which solution would you prefer?

If you choose Solution #1 – what would you like that slug to be ?

30 responses... add one

What if we made it so that users could choose either 1 or 2.

If we went with option #1, then maybe the slug should be optional that the users get to enter themselves.

I think this is an important question because the results may have SEO implications. I’m looking forward to community feedback on this one!!

I’m for Solution #1, shake and bake, look how WordPress does Category views with Posts.



Makes sense for WP e-Commerce to follow suit, on a related note by default I drop the Checkout, My Account and Transaction Results as Parent Page’s. Just looks better organised for dedicated stores.

Well, I totally agree Dan. This isn’t going to be a ‘choice paralysis’ problem and is certainly one of the things that we should have the choice of if it’s reasonably possible. I’m loving this ‘open’ planning stage – 🙂

Got a third possible option, you could hook into the wp-query object and convert requests for the checkout “category” into the requests for the checkout page.

This would be quite a bit more complex to implement than the other solutions, however, and will cause problems if someone actually wants to have a category called checkout. ( I have no idea why someone would want to do this, but there is undoubtedly someone who thinks its a good idea.)

Also, you will have to use the correct name for the checkout page, you will not always be looking for the string “checkout”.

Thanks Thomas. I like your thinking. And I kind of think that if somebody is crazy enough to call their category checkout.. well then I think its their own crazy fault.

And as John says collision detection is on the radars. Maybe we should just implements Thomas’s aproach and wait for Dion or somebody to nail collision detection. Just a thought?

Hmmm this is why Valentinas & Jeff need to develop Thomas solution in such a way whereby people can choose the right fix for your shop? Although that of course might not make it into V1…

How does WP e-Commerce 3.7 do it at the moment hmmm

I think we should either stick with WordPress way and add “/category/” to URL (but that’s not very elegant way to do that)
or as Thomas pointed out change the wp-query object. We could avoid collision by adding a filter for categories, which could check if category slug == checkout page slug, and if so – modify one of those.

Like you’ve said… In the past, these have always been child pages off of the products-page. What if there was a ‘page picker’ interface, that lets savvy store administrators pick which WordPress pages equate to which WP e Commerce page? This way they can pick which pages at what position they want to have these functions occur, and it opens the door towards better integration with other plugins like BuddyPress and EventPress which may also want to have their own WP pages too.

At the core of this problem, is a larger WP problem regarding permalinks, unique slugs, and collision detection; something that there are trac tickets for and is a known issue to the WP core devs. I believe dd32 (Dion) took a stab at a patch some months ago, but with the advent of multiple taxonomy queries and other things on the roadmap for 3.1, it’s hard to guess where exactly these issues will end up.

Bizarelly enough – I can’t reproduce this fault with the other sub-pages (/shop/transaction-results/ and shop/your-account/). These seem to work fine – despite parse_request matching them as wpsc_product_category=transaction-results and wpsc_product_category=your-account


Anyway – I liked Thomas’ suggestion the best – something like this should do the job:

`function wpec_remap_shop_subpages($vars) {
if (isset($vars[‘taxonomy’]) && $vars[‘taxonomy’] == ‘wpsc_product_category’) {
if (isset($vars[‘term’]) && $vars[‘term’] == ‘checkout’) {
return array(‘pagename’ => ‘shop/checkout’);
return $vars;

Obviously we’d need to check the actual slugs and page names rather than hardcode shop and checkout – and possibly expand this to cover the other sub-pages – but the idea looks good!

Solution 2 is the better option, perhaps letting user just dictate which page serves what function in WP-ecommerce is even better. Solution 1 definitely isn’t the better SEO option. Google cares a lot about URL’s and adding extra text/words in between doesn’t help out. Google likes /mens-shoes/awesome-shoe not /mens-shoes/shoe/awesome-shoe. Google doesn’t like more than 4 to 5 words in there either. Adding in extras lowers the weight of the URL in the ranking algorithm. Google also doesn’t like static, generic words in them. Adding that in hurts you there too.

Just my thoughts, but definitely built on SEO reality, I’m not just guessing at this. People who us WP-E-commerce need good SEO stuff…regardless of WordPress bad habits.

Believe it.

As far as E commerce is concerned here, I can only agree with you Andrew.
Technic should be secondary concern here, SEO matters.

Can’t wait to see 3.8 release 🙂 keep up the good work dev’ team.

RT @nicolas1106 “Can’t wait to see 3.8 release 🙂 keep up the good work dev’ team.”

A mostly unrelated note, I just found THE nicest ecommerce shop I’ve ever seen online. Altrec.com. Thought you might like to play with it too. I have no idea what they’re built on. But I love virtually every aspect of it, from the url structure to image zoom to shopping cart ajax. And I like how they use brand names as the directory in the url structure b/c, at least IMO, it’s the only truly objective way to choose the url structure (and thus most canonical, if you will, b/c it is least likely to change). And if you lop off the specific product in the url, it displays all the products by that brand. (The CMS Press plugin does similar templating too, if you lop off the specific url and just leave the custom post type slug.)

Question…Since 3.8 is using custom post types, will we be required to use a slug such as /store/, /shop/, or /products/? To my knowledge, that’s the only way custom post types work. But you’ve got an awesome team, so I thought I’d ask. B/c it’d be truly awesome if you found a way to make such a slug optional.

It’s the affect of the URL’s on the products that the problem. And you can get around the custom post types URL problems with htaccess stuff.

Though I am a long time owner of wp-ecommerce I am brand new using it. I dont have an opinion at this point but there is something that I feel I need to say. The way this community works and you guys discussing the options is fantastic. It says a LOT and I personally appreciate everyones hard work. Thank you!

There are no SEO implications, as these aren’t pages you want indexed by search engines anyhow.

Personally I think the error itself is weird: WordPress allows for subpages well enough usually.

But among the choices, I don’t care which you use – and I don’t think shop owners in general would mind having this at home level (looks cleaner to me). So I have a slight preference for option 2.

However, finding out why this bug occurs seems like the proper course of action. Pages can be hierarchically organized fine in WordPress proper.

Wrong. You’re either not understanding what they are saying, or you don’t understand SEO. We’re not talking about three pages, but every category page. Read blog post again.

Quote -> “So 3.8 is getting a lot of traction these days, and we are working non stop on getting this to a beta sometime soon.”

Can you give an approximate idea about “beta sometime soon”? few days? few weeks? few months? more?

If I paid for 3.7.9 Gold, will it be available for a free update?

Will the 3.7.9 current data be easily converted into the 3.8 plarform?

Greetings and good job boys!

Sorry guys, I’ve been working full out on another project and not paying enough attention here, but if you go with #1 you could be setting every existing WP e-Commerce store up for a huge disaster.

When I say “could be” it’s because I am not clear on if this, “Append ‘Something’ between products-page and product category name. i.e yoursite.com/products-page/cat/product-category where cat is just a random text” would apply to existing sites that upgrade. If this is the case, then we can change “could be” to “will be.” Every link in every search engine pointing to products pages on WP e-Commerce sites will be broken.

Unlike Andrew, I am not worried about a little extra /cat/ in there. This isn’t enough to hurt anyone’s seo and search engines have gotten much better at dealing with long URLs, but what I am worried about is changes to existing URLs, this could be a killer. Please tell us this won’t be the case.

Thanks, Dan! That’s a huge relief. I know your intention is to have the most SEO friendly cart possible, just didn’t want this to get overlooked. Like everyone else I am stoked about 3.8. Keep up the good work.

Greetings I am so excited I found your weblog, I really found you by accident, while I was browsing on Bing for something else, Nonetheless I am here now and would just like to say many thanks for a incredible post and a all round enjoyable blog (I also love the theme/design), I donít have time to browse it all at the minute but I have bookmarked it and also added in your RSS feeds, so when I have time I will be back to read much more, Please do keep up the superb job.

Users should be able to choose. But if that is too hard then #2 for sure!! I hate option one. It’s not memorable for users. I already use mysite.com/productname. I do NOT want to change this!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.