zunxunz

@Nemo As I said, it should be optional, you don't have to use it if you don't like it. And duplicate names is not the only reason. Other reasons are being able to use shorter 'friendly' urls and not having to use redirects when urls change. But, never mind, I'll use my own patch.

@MockoB The point is, I can not (and don't want to) avoid the duplicate names. We have over 1600 categories and 40000 products in a shop and sorting out the duplicate names would be impossible. That is why I've implemented this patch. I'm not sure why you guys are so strong-headed about this, since it would be a really simple extra option to implement. But ok, I'll just keep using my own patch...

@Nemo Nice and useful to some extent. But this will not solve the name collision issue, it will make that more complex if anything, because 'new' urls might now collide with existing ones.

@MockoB Hi, thanks for your reply, but you miss the point I'm making. The 'friendly url' option of TB creates 'static' urls. When you change a name of a category or product, the url also changes, which is bad for SEO because you break your backlinks. This is why I solved this problem in our shops with a unique identifier other than the database id for 'objects'. This 'extra' option is very easy to implement in TB and it will not interfere with any of the current options for urls at all. If you prefer these, you can still use them.

Hi, I've picked "General' because I'm not sure where else to post this issue, could be tech. but applies to SEO too. I don't really want to get into the discussion if urls with db ids in them are bad for SEO or not. I don't think they are really, but nobody likes them anymore so lets get rid of them. Currently the only choices in PS for urls are urls with ids or 'static' friendly urls. By static here I mean urls that have for instance the categories / category / product name / etc. in them in such a way that when either of these names change, the shop's backlinks for this url break, which is not nice for SEO at all. Another problem is name collision, when you want really short urls, but categories/products/brands have identical names, the urls break. Or even in cases where there are -many- product in a shop, names can collide. In several shops I've solved this by not using the internal database id in the url, but another identifier, like the 'reference' or EAN13 for products and a 'reference number' for a categories to identify them so that when the name of the category or product change the specified category or product can still be found (by lookup in the dispatcher). Example: url: www.shop.com/white-gnocci-shorts/S332.112 Where the last part of the url is the products reference. Now, if I have to change the name of the product for whatever reason it won't be a problem because it will be looked up by the reference and backlinks never break. I've chosen to use an identifier like 'reference' or EAN13 because I've been working in situations where name collision between categories/brands/products/cms pages are impossible to avoid. In short what I mean to say is, I'd like (and need) 'nice urls' with a unique identifier other than the database id, like in the examples below: Category urls: shop.com/socks/blue-socks/C321 shop.com/socks/red-socks/C212 Product urls: shop.com/my-nice-product/P32111 shop.com/my-other-nice-product/P43821 shop.com/my-first-product-with-a-changed-name/P32111 Ofcourse the identifiers need to be configurable in the SEO section of the shop... Maybe a SEO identifier field for each object?

The 1246982 rows in the url_rewrite table might be another thing to look at though, it seems that these are way to many rows. After disabling/enabling 'Friendly url's' I ended up with about 80k rows which seems a lot more feasible given the number of 'items' in the shop...

I had an issue with very slow page load speed in a shop (900 categories / 39k products) and seem to have found the problem. There are no indexes on the table url_rewrite (1246982 rows in my shop). After adding the proper indexes to this table the speed issue no longer occurs.

After some more digging I've found the problem. There are no indexes on the table url_rewrite ( 1246982 rows in my shop :) ). After adding the proper indexes to this table the speed issue no longer occurs.

I've set up a new shop with about 30k products and 900 categories and I'm running into incredibly slow first time page load speed issues, page loads of 10-20 seconds or worse. It seems to be a caching problem, since the slow speed occurs mainly on first time page load, but it recurs in cycles. On category pages with multiple pages (pagination) each 'page' will load very slow the first time and then 'ok' after that, but for each every other page (as in ?p=x) the first load is again very slow. And this seems to cycle, after hitting a few pages the ones that have been viewed before become slow again. This shop is a 'mirror' of a PS1.6 shop I have running on the same server, same settings, same content and that one is running fine... Any ideas anyone?