Developer forum

Hi,

If you have products with the same name we recommend you to use the "Include product ID in product url" setting in the Customized urls setup in order to distinct the products from each other.

Check attached screenshot.

Kind regards,
Merethe

Well, that's not a very good solution to the problem.
I have posted this problem in different situation.

The solution would be to change the way you identify duplicate URL's. The whole URL should be unique. Not just product name or combination of group name and product.

I have a lot of headaches with this behavior for multilanguage websites that use the same catalog. It ends up with product url's with -15 or more at the end of the url although the website has an identifier (be it lanaguge or subdomain).

I am sorry to say this but this friendly URL feature is still a weak point of DW. Any workaround is, in the end, just a workaround that will probably not work at the next release and we end up recreating a bunch of 301 rules to cover for this.

Hi Adrian and Umar

@Umar: In the screen Merethe has attached, set the checkbox for "404 for products not in website shop" and "404 for products not in website language". That will solve this issue.

@Adrian: If you make sure all products have a primary group and all groups have a primary parent group and all groups have a primary page and enable the "Enable strict URL recognition" you will be far further. That will also give you a canonical for each product.

We could say that each product has one and just one URL including the website/page/group/product - but that is just not the case. Products have more than one URL because they are published in more groups or on more websites - the only unique identifier is the product id (and that is not even unique because of languages) and that can be enabled. Forcing ONE URL to each product would be possible but it would be an error in most cases.

Hi Guys,

Thanks a lot for the info. "Enable strict URL.." is a new one. Have not used before.

Even so, it does not seem to work.

http://us.mbt.com/en-us/men/mens-dress

First product has a link that looks like this: http://us.mbt.com/en-us/men/mens-dress/isimo-2-black-8

-8 means there are 8 other products in other shops with the same name.

Product has primary group (it is assigned only to one group anyway

Group has primary group (took some time to find where to store it)

Parent group has primary page

Hi Adrian

Yes - the setting does not prevent you from having the -N numbering. You could be publishing 2 catalogues on the same website or have 2 products with the same name in the same shop.

URLs are language specific. If you combine the settings you have made now, with canonicals and with the 2 404 options, you would ensure that going to isimo-2-black-9 would give you a 404 avoiding the DC problem.

The product URL index is currently in an index for each language - if we made that index for each shop and language combined, we could remove the -N naming, but then you would not be able to publish products from 2 catalogs on the same website. Again - the 404 setting gives you just that, except it still has the -N naming...

Nicolai

Hi Everyone,

Thanks for the your input on this matter. the solution which Merethe suggested did the trick but again as Adrian said its not a very good solution to the problem.

@Nicolai: I tried those 404 settings but it didnt helped much. as far as i can interpret from the those settings is that when the  products not in website language it will through 404 error or i missunderstood it or i am missing somethig?

In my senario I have 3 langauge layers with the same regional settings "da-DK" and there are different ecom groups assigned to the each language layers which have products with the same name but with different prices. As far as i know it is not possible but it will be great that we can assign the users to ecom groups so only the loggin users can see these products with special prices and i believe we can use it in many different ways.

Best regards,

Umar  

Hi Guys,

While I totally understand the challenges of this functionality, the client is not that receptive. Especially when they come from a competing platform that does not have this problem. Actually nor Magento or any other open source platform has this option and some of them deal with multi-catalogues/multi-websites as well.

If you know the SEO purists as I do, you will understand that this is deal breaker for some.

Maybe you should consider limiting some options of the catalogue use cases in order to find a solution for this.

In our case (the MBT website) there are more than 20 separate websites from which about 10 are using the same language. They are not using subdomains but language names subfolders. We have managed to duplicate the products for each shop keeping the name, product number and other details but changing ProductID. They are not re-using the catalogue in different shops. Each website has its own shop/catalogue.

So far I have managed to keep this under the rug since they have not started any SEO activities or analysis. But I expect some action on this area in the first part of next year.

Thanks a lot,

Adrian

A long term solution...

How about making all products item based? A product item would be any item inheriting from "buyable item" (a standard code first item?), which means that it can have prices, stock states, etc. and it can be added to a cart. That way each product would always have a single unique (canonical) URL, because it can only exist in one place. It would be possible to create multiple lists with the same products by using Item Publisher or similar, but each product would still have a unique URL. This might create some limitations, but it would be a lot simpler to set up and it would just work out of the box.

While we are at it, why not make all of eCommerce item based? It doesn't necessarily mean that everything should live in the site structure.

This has not been fully thought through (no shit), but maybe it's worth investigating. I think most would agree that some major breaking changes are better than having to deal with stuff that is already broken on a daily basis. This change could even be done gradually while preserving some backwards compatibility.

Once all content is item based the API could be reduced considerably and it would make it so much easier for Dynamicweb to maintain and for partners to extend. A single API for all content instead of having multiple APIs that happen to coexist inside the belly of Dynamicweb.

It would definitely worth considering. 

The current setup speeds up things a bit when publishing the products and keeps the structure clean. I am talking about Ecom Navigation and Product Catalog with all its ups and downs. It's not entirely wrong as principle. It's just not consistent enough. I cannot rely on a behavior. I know it's a different matter, but I've been working with umbraco for some time now and I did not had an issue with url's ever. Actually Umbraco made me used to ItemTypes before Dynamicweb. But Dynamicweb made them more advanced. And many thanks for that. I believe that the Product option of the ItemTypes is a step in the direction you suggested.

While I uderstand the reasons, I believe the current URL system is too much legacy. And I am also referring to the URL for pages as well. Not just the products.

Also, the current system adds some burden on the performance as well since it has to process all those URL's at page load. 

I think there are lot of very talented people in this forum, many of which have a history with Dynamicweb. Maybe it's something that should be discussed in an extended group. 

I totally agree, the current URL handling needs to be replaced with something more reliable. It could be based on routing in ASP.NET

Dynamicweb has previously been experimenting with some features of ASP.NET MVC and I think the API already contains parts of this. I'm hoping for some great news and ambitious plans to be revealed at the Tech Conference in february. Dynamicweb is a pretty good CMS, but it needs to keep up with the competing products out there and that will require some radical changes in my opinion.

If Dynamicweb was open source, we could fork it, experiment with it and make pull requests. Make it happen! :-)

:)