Behaviour of URL Key field is different in Magento 2 then in Magento 1

[dverkade]

The behaviour of the URL Key field is different in Magento 2 then in Magento 1. This might be a (undocumented) feature of Magento 2 or a bug.

Preconditions

1. Install latest version of Magento 2. This behaviour still exists in Magento 2.2 as well.

Steps to reproduce

1. Add 2 products and enter the same URL Key for those products. When you try to add the second product the error "URL key for specified store already exists." appears.

Expected result

1. Same behaviour as in Magento 1. The products saves and is only available with the {{url_key}}-{{entityid}} URL.

Actual result

1. Throws the error "URL key for specified store already exists."

Causes

1. Further more, when you import products from an external source or with the Magento Data Migration tool and the same URL Key is being imported into your database, you'll get issues with saving products, saving categories and moving categories since these actions will trigger URL rewrite rebuilds. When this happens it will trigger the following issues, which are related and will be resolved when this issue is resolved:

• Category - URL key for specified store already exists. #6531
• URL key for specified store already exists in Magento 2.1.1 #6671
• "URL key for specified store already exists." cannot save category #7298
• URL key for specified store already exists when Creating new Products, secondary store view #5527

Debugging

Did some digging into Magento 1. In the class Mage_Catalog_Model_Url the following code is executed in order to check if the request path is available and saves only the correct path. This behaviour is not present in Magento 2.

$validatedPath = $this->getResource()->checkRequestPaths( array($requestPath.$suffix, $requestPath.'-'.$product->getId().$suffix), $storeId );

[orlangur]

Behavior of Magento 1 is totally incorrect from SEO perspective. Generated once URLs shall be preserved and not changed at random point with random numeric suffix. In Magento 2 merchant has full control over generated URLs and resolves any collisions immediately.

What should really be improved in Magento 2 instead of restoring poor Magento 1 behavior is:

1. Better collision resolution UI so that merchant clearly sees which product/category/CMS page causes trouble. Here some "plz autogenerate for me" button could be implemented with similar to M1 behavior, BUT it should never change existing URLs unless merchant intentionally asked for this.

2. Better URL Rewrite regeneration mechanism so that saving category with a lot of subcategories and products does not take seconds to minutes.

trigger the following issues, which are related and will be resolved when this issue is resolved

All referenced issues are easily solvable in current Magento 2 implementation, they just indicated misunderstanding of differences between Magento 1 and Magento 2 URL Rewrite behavior. They are already resolved, there is nothing to "fix". Reimplementing Magento 1 oddities just because of Magento 2 nuances misunderstanding is a road to nowhere as to me.

[dverkade]

Only the @magento-team can tell if this is a bug or a feature. If it's feature, this issue and the related issues can be closed.

[orlangur]

Surely. Many core team members can tell if it is a bug or feature, related issues are already closed. I just tried to give some insight having deep understanding in this area of Magento.

URL Rewrites is definitely a pain point currently from usability (especially performance) perspective. I would be glad to hear if something planned in roadmap to improve this as well.

[dverkade]

Issue #6671 has been open for more then a year, which relates to this as well, so I updated this issue with the link. URL rewrites performance is out of scope for this issue, it only deals with the changed URL key field behaviour between Magento 1 and Magento 2.

[mowny]

This is especially a problem when upgrading from Magento 1, and a pain to fix.

[orlangur]

@mowny why? There will be no URL Rewrites collisions if data migration done properly.

[choukalos]

Hi @orlangur,

You're spot on. We've been alerted to a few URLRewrite bugs which we've resolved along with some performance tuning using our current architecture.

We have an epic (MAGETWO-69145) that's in my short/medium term backlog to change our architecture to be more efficient in managing large # of URLRewrites. That work includes improved merchant facing notification/resolution of URL conflicts (you'll see some of that in 2.2 and patched back into 2.1.x) and improvements in managing historical URLRewrites.

So I'll close with it's complicated, as written this isn't a bug but a feature request to expand our performance envelop of our current URLRewrite architecture. However, we see gaps/issues around usability (bugs) of current URLRewrite architecture that will be resolved in the short term.

[mowny]

@orlangur Only if the magento 1 database was clean in that regard. We still run into this problem with old (even deactivated) products that have once been duplicated, and the source of the problems is a pain to locate.

[dverkade]

@choukalos why did you close, then reopen and then close this issue again? No comment from Magento why this issue has been closed. So this should still be open because this issue has not been addressed properly.

[choukalos]

@dverkade - sorry for the confusion; basically URLRewrite behavior is as designed and correct but our current architecture/implementation has several issues that need to be resolved and are (mostly) identified as a short/near term feature request ( internal epic MAGETWO-69145 ).

Issues (based on this thread, other reported issues, current market research):

• We don't appropriate notify merchant of URL collisions (we have resolved this for category/product saves in 2.2; but not for product imports - it's in the logs but not as a notification during import; future-longer term product import work is centered around improving notifications. I'm working with our PM for import to get the priority of this work bumped)
• Our current architecture with large # of websites or large # of sku's has very long category/product save times due all the writes to URLRewrite table (MAGETWO-69145 is targeted at changing this architecture to eliminate this bottleneck).

So my suggestion would be to

• Link to feature request/internal epic MAGETWO-69145 to address save/scalability needs
• Link with product import issue(s) around lack of notification granularity on failure
• Either close this issue as dup of those linked issues or leave open and when those linked issues are closed close this issue as well (though that creates quite a bit of duplicate open issues; not sure if balancing issue identification paths vs # of issues outstanding improves clarity)

[dverkade]

Hi @choukalos,

Thank you for your reply. I understand that the behaviour of Magento is working as designed, however this does not mean that the chosen design is not flawed. First of all, I'm wondereing what the theory, reasoning and user story was behind this design decision. I hope you will be able to clarify on that. There are some major disadvantages with the design chosen:

• First of all you have created an almost near impossible upgrade path from Magento 1. The Data Migration tool just dumps the data from Magento 1 into Magento 2 and due to the behaviour of Magento 2 saving of a product or category becomes impossible.
• A lot of users are strugling to get this concept as can be seen by the many issues on Github.
• The introduced behaviour is different then it was in Magento 1 and is different from other platforms as well. For instance Wordpress, which will automatically append "-1" to the URL when the URL key was already taken.

I do agree that from a SEO perspective URLs should be persistent, and once they are set should not change randomly. This is something that occurred in Magento 1 under specific circumstances and should be avoided at all costs.

I think we should introduce behaviour in order to not only notify but als prevent URL collisions. Magento 2 introduced behaviour in order to deal with SKU collosions, where "-1" or "-2" wil be appended to the SKU when it's already been taken. The user is also notified of this change as well. So in my opinion you are removing such behaviour from Magento 2 on the URL Key field to make sure user input is not changed automatically and Magento 2 introduces it on the SKU field.

User story:

• As a merchant, I want to have full control over the URL key, so that I can change it to the desired value.
• As a merchant, I want to have persistant URL's, so that once an URL key is set it will not change automatically.
• As a merchant, I want to edit and save a product even when the URL key is already been used. So when I'm as a merchant, not interested in the exact URL key or appending a "-1" to the URL key is not an issue I will still be able to save the product.
• As a merchant, I want to be notified of a collission in the URL key, so I can change it to a different URL key.
• As a merchant, I want to be notified of the products or categories which collides with my URL key so I can easily check or change the URL key of those products / categories as well.

Example of notification to a user that a collision in the URL key field occured:

How do you feel about introducing the behaviour for checking if an URL key collides and appending for instance "-1" or "-$entityId" to the URL key and notifying the user of this change in the URL key? Just the way it's currently working with the SKU field in Magento 2. I think you have a real workable solution for this and the other issues regarding the URL key. It gives the user complete control over the URL key and you will also be able to save products which somehow got the same URL key (for instance from migrating data from Magento 1).

So this issue should definately not be closed as a duplicate, because this issue will not be resolved with performance improvements as mentioned in internal ticket MAGETWO-69145. It's also not solved by notifying merchant about the collisions. Magento should take care of this for the merchant and give them the ability to change or overwrite the URL key when they like to do so. As mentioned earlier I have know deep knowledge of the url-rewrite and catalog-url-rewrite modules, so I'm happy to help you out on the issues regarding the URL rewrites.

[orlangur]

@dverkade,

First of all you have created an almost near impossible upgrade path from Magento 1. The Data Migration tool just dumps the data from Magento 1 into Magento 2 and due to the behaviour of Magento 2 saving of a product or category becomes impossible.

This could happen in the past and was fixed in magento/data-migration-tool#81. Just provide additional details if you still experiencing the problem.

Not commenting other items as they are irrelevant.

[magento-engcom-team]

@dverkade
Thank you for your submission. We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues. Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

[SnowCommerceBrand]

Something I found very Usefull was the comment from @mowny

"We still run into this problem with old (even deactivated) products that have once been duplicated, and the source of the problems is a pain to locate."

If you have folks on your team that disable a product then create a new one and enable that with the same url key you will get your {SEO url} + {Entity ID} This url key issue was noticed by our team because when the products are saved the url changes Entity ID and google creates 404's in search Console. Would almost be better if you couldn't even save a second thing with the same url key to avoid this.