Magento2: Saving Product does not update URL rewrite in Magento 2.1.0

[JacobDrummond]

Preconditions

1. PHP 5.6.16
2. MySQL 5.6.21-log
3. Magento 2.1.0

4. Nginx 1.4.6

   Steps to reproduce

5. Confirm old URL rewrite works:
   

6. Update product URL:
   

   Expected result

7. Product should be visible at /{new product url}

   Actual result

8. 404 error:
   

9. url_rewrite entry for product saved above still shows old request_path:
   

[JacobDrummond]

Hi @veloraven,

Thank you for labeling this issue as a bug. Do you know if/when it will be escalated to "acknowledged" by developers?

This bug, along with #5923 and #5942, is blocking a go-live. What's the usual workflow and timescale for the Magento team to address bugs?

[Cacasapo]

Confirmed on 2.0.8->2.1 upgrade.
My product urls end in .html, too, but I'm too new to Magento to know if that's normal.
/myproduct,html works, but /myproduct does not.

[JacobDrummond]

@Cacasapo,

Rewrite bug

Thanks for narrowing it down to 2.0.8->2.1 upgrade. Were you able to find the commit that broke it?

URL suffix feature

You can change the default ".html" URL suffix in Stores > Configuration > Catalog > Catalog > Search Engine Optimization. I usually set it to blank for nice clean URLs:

[Cacasapo]

@JacobDrummond I've looked at url_rewrite commits, just out of curiosity, and saw that there was a lot of activity on it not too long ago, alas I'm not a coder and thus useless inside Magento's guts.

Thanks for the info on the URL thing. Didn't think to look under SEO for it!

[Cacasapo]

This bug is also present on a 2.1 fresh install.

[andimov]

@JacobDrummond
Thank you for reporting this issue!
Can't reproduce this bug.
Please, check, did you have made changes in the section "Search Engine Optimization" below?
You can change URL rewrite in this section while you changed product or category name.

[JacobDrummond]

@andimov,

Yes, I updated "[product] > Search Engine Optimization > URL key" which saved the url_key attribute, but didn't update the url_rewrite table. This issue appears to be with Magento_CatalogUrlRewrite not Magento_Catalog.

Are you trying to reproduce on a 2.1 fresh install, or on a 2.0.7->2.1 upgrade? So far the only reports are from people who upgraded.

[Cacasapo]

@JacobDrummond I tested this and the other bug you found on a fresh 2.1 composer install. This bug is present on fresh and upgrade, while the other is only present on an upgrade.

[JacobDrummond]

My mistake, @Cacasapo. #5923 and #5929 are so similar I'm getting my wires crossed

[Cacasapo]

@JacobDrummond Understandable. They're also pretty nasty, so I'm surprised more people aren't chiming in with https://github.com/magento/magento2/issues/5929

[JacobDrummond]

Hi @Cacasapo,

Similar to #5923, this issue can be resolved by disabling single-store mode.

The issue appears to be that URL-rewritable entities only regenerate their URLs when a website/store field is present. These fields only show when single-store mode is disabled.

[JacobDrummond]

@Cacasapo,

To clarify, here's how you regenerate URLs on a site where url_rewrites has become out-of-sync with product entities:

1. DIsable single-store mode:
   
2. Select all products, then click "Update attributes":
   
3. Assign products to all stores, then click save to regenerate all URLs:
   

[Cacasapo]

@JacobDrummond Nicely done.

@andimov Does this keep the two bugs in your neck of the woods?

[andimov]

@JacobDrummond @Cacasapo
Thanks! I've created an internal ticket for this issue - MAGETWO-56862 and linked it to this one.

[Dart18]

Same issue in Magento 2.1.2:
After a migration from 1.9.2.4 to 2.1.1 and update to v.2.1.2, when I change the url key of a product, the new frontend url returns a 404 error. The original frontend url still working.
I noticed that after saving the product, the field url_key is updated, but not the field url_path.

mysql> select * from catalog_product_entity_varchar where entity_id = '1';
+----------+--------------+----------+-----------+----------------------------------------+
| value_id | attribute_id | store_id | entity_id | value                                  |
+----------+--------------+----------+-----------+----------------------------------------+
|        2 |           86 |        0 |         1 | bouquet-natalizio                      |
|       13 |           87 |        0 |         1 | bouquet-default                        |
|       12 |           87 |        1 |         1 | bouquet-default                        |
|     2297 |           87 |        4 |         1 | bouquet-default                        |
|     2231 |           87 |        5 |         1 | bouquet-default                        |
+----------+--------------+----------+-----------+----------------------------------------+

The store_id 0 is admin, my store ids are 1,4,5,6 (and there is a row for each store id except for the store 6, but I don't know why).

mysql> select attribute_id, entity_type_id, attribute_code, frontend_label from eav_attribute where attribute_id IN(87,86);
+--------------+----------------+----------------+----------------+
| attribute_id | entity_type_id | attribute_code | frontend_label |
+--------------+----------------+----------------+----------------+
|           86 |              4 | url_key        | URL Key        |
|           87 |              4 | url_path       |                |
+--------------+----------------+----------------+----------------+

So the url _www.mysite.com/bouquet-default.html_ works, but the expected url _www.mysite.com/bouquet-natalizio.html_ doesn't work and returns a 404.
In the rewrite url table the request_path field is related to the value of the field url_path

mysql> select url_rewrite_id, entity_type, request_path, target_path, store_id from url_rewrite WHERE `target_path` = 'catalog/product/view/id/1';
+----------------+-------------+----------------------+---------------------------+----------+
| url_rewrite_id | entity_type | request_path         | target_path               | store_id |
+----------------+-------------+----------------------+---------------------------+----------+
|         158427 | product     | bouquet-default.html | catalog/product/view/id/1 |        4 |
|         158429 | product     | bouquet-default.html | catalog/product/view/id/1 |        6 |
|         158431 | product     | bouquet-default.html | catalog/product/view/id/1 |        5 |
|         158910 | product     | bouquet-default.html | catalog/product/view/id/1 |        1 |
+----------------+-------------+----------------------+---------------------------+----------+

The expected value for request_path in my case is wrong (bouquet-default.html instead of bouquet-natalizio.html).

No error appears in exception.log, system.log or debug.log during the save process.
I have no idea about how to solve this problem. I read a mountain of posts about similar issues, but unfortunately I have not found one focusing on the url_path.
Any suggestion is welcome. Thanks in advance.

[JacobDrummond]

I have no idea about how to solve this problem.

Short-term: workaround outlined here.

Long-term: No closer to solving single-store bug. Do we even need single-store mode, if we can assign manually?

[Dart18]

I already tried this workaround, but in my case it was not successful. I'm debugging to understand where is originated the issue.

[thlassche]

I developed a CLI command as a workaround (which can be run from cron), let me know if you are interested

[maxhanna]

What does not make sense here is that someone is selling a solution to this rather then having the developers actually fix the problem. Thlassche vs magento devs, Thlassche 1, magento dev 0.

This is my problem too. I have a native 2.1.3 magento install, ive once had over 18000 sku, which, because of other magento problems, i had to delete. Now ive got only 200 products in my catalog, yet my url_rewrite table is 800 mb large. Makes no sense. I guess i have to delete everything and restart.

[fedeverdi]

Any news about the rewrite issue ?

[jarhody]

I am experiencing similar rewrite issues on 2.1.5.

[JacobDrummond]

@ Everyone having issues,

Have you tried this fix to get your URLs back in sync?

[thlassche]

I just released a new version of my command, which fix even more issues with URL Rewrites

[peterkeijsers]

@Dart18

I think I just figured out what is causing your issue. As seen in your screenshots. The product in question has a url_path value for store_id = 0. I think this is causing the issue. In my case, when i delete all url_path values from the table: 'catalog_product_entity_varchar' where 'store_id = 0'. Then the whole url_rewrite function is working normal.

I think the importer is causing this when importing product attribute values for store_id = 0 or empty in the import sheet. Magento's url_rewrite module of url_path method can't handle this properly.

Solution for me:
Delete in the database all url_path values for store_id = 0 and then trigger a mass product save to update the url_rewrite table for products.

[jarhody]

I have tried all solutions listed here and nothing seems to work for me on 2.1.5.

Always have been in single store mode, mass product update to no avail.

Tried deleting entries in catalog_product_entity_varchar with url_path and store =0, then trigger update. Nothing.

Notes:
I am using .html extension on products and categories (this should not be an issue). I tried removing the extension, flushing and repeating the process and the results were the same.

When I do a mass update I receive the error "URL key for specified store already exists."

Not sure if this is tied to the issue but my eav_attribute table has 2 instances of url_path

[peterkeijsers]

@jarhody

The 2 instances of url_path are normal. One for categories (attribute_id 47) and one for products (attribute_id 83). I removed both of the entires. After saving a categorie I noticed that for categories the 'url_path' for store_id 0 gets added by Magento itself too. But for products, no new entries for
'url_path' where added after saving the products again. So that strengthens my guess that for products a 'url_path' for store_id = 0 is causing issues for the url_rewrite's in Magento 2.

[jarhody]

@peterkeijsers

After removing the product urls for store = 0 your rewrites are then working correctly?

[Dart18]

@peterkeijsers

Solution for me:
Delete in the database all url_path values for store_id = 0 and then trigger a mass product save to update the url_rewrite table for products.

I've done the same before reading your comment and I can confirm that also in my case the solution worked.
I have also manually renamed via SQL queries in the database all categories with the same url identifier but placed in different branches of the the categories tree.
I did a deep check on urls of all products and I removed the url_path as you described.
Then I launched a mass action to save products.
All properly works now.

Magento is causing me a split personality. I do not know if I love it or I hate it.
Do you have a solution for this issue or I have to open a new ticket? ;-)

[thlassche]

My solution now works for categories as well, contact me if you need it. It uses the categoryUrlRewriteGenerator for that purpose

[shahankitb997]

Still issue on 2.1.7. Any ETA @magento-admin @magento-team In which version will get?

[jordanbrauer]

Magento is causing me a split personality. I do not know if I love it or I hate it.
Do you have a solution for this issue or I have to open a new ticket? ;-)

@Dart18 Don't bother opening a new ticket - they will just find a reason to link it to an unrelated issue and close your ticket! :laughing:

[andidhouse]

I is really a mistake from magento side not to implement a function to regenerate URLs and Rewrites via the command line. If you search on google many people have the problem and some developer offer extensions which are not in every case doing what they seem. This ends up in time consuming of developers and users of M2. Simply because the magento2 team decides to leave this function out of m2? Because it slows down the indexing process or what is the reason here exactly? I am not shure this is a right way to do it - in my opinion it would be better to make this optional to run via ssh....

[thlassche]

@andidhouse My extension does, for both categories and products

[andidhouse]

@thlassche many thanks! maybe we will try the extension.

Does it complete delete and regenerate the catalog_url_rewrite_product_categoryand url_rewrite tables? or what is the exact behavior?

We are little struggling with a complete data migration from an 1.7 system so for us best would be to have all URL rewrites deleted and built up again.

Thanks!

André

[thlassche]

@andidhouse Yes, it replaces the existing URL rewrites and regenerates them based on the current url_key attribute. Note: the current Marketplace version does not have the category rewrites yet, because it's still in review (for a few weeks already..). Just send me an e-mail after purchase, then I'll send you the version with category rewrites by e-mail

[jordanbrauer]

@thlassche It's hilarious you are making money off of something Magento should never have taken out to begin with like @andidhouse mentioned. :laughing: The fact people pay 30$ for this should be enough to show Magento that they need to re-implement the URL rewrite indexer. It doesn't even need to part of the regular indexer - again, as @andidhouse mentioned, this is not the right way to be handling this problem (if you even want to call it that).

[andidhouse]

@thlassche we would like to try your tool. Are you available today to send it. Can we also buy it directly from you? Would be great to get an answer as we plan to migrate tomorrow and this is still an issue on some products.

Thanks!

[thlassche]

@andidhouse Yes I'm available today. E-mail me at [redacted]

[ghost]

This way of selling problem solutions should be forbidden on Github. Github is supposed to be a platform to help people out and report bugs and place repairs and bug fixes. Shows exactly what kind of person you are for asking money for other peoples problems. Share your solution here, to remind you it is open source Magento. Yes i have the same problems, no I am not gonna pay for the solution.

[erik-augustin]

Same problem here:
Need automatic rewrites categies, doing updates manualy is not the solution.

[AaronV-T]

I'm running Magento 2.1.7 (a bit outdated) and had the same issue. I only had to update the URL for 1 product and did it easily by running the following MySQL commands:

UPDATE magento.url_rewrite SET request_path = "{desired-product-url}" WHERE url_rewrite_id = {id of the row to update};
and
UPDATE magento.url_rewrite SET request_path = "{category}/{desired-product-url}" WHERE url_rewrite_id = {id of the row to update};

[magento-engcom-team]

@JacobDrummond, thank you for your report.
The issue is already fixed in 2.2.0

[Bilbaukai]

@magento-engcom-team Is it ever going to be fixed on 2.0.x ?

[paul-javs]

Uhh, news to me. I'm still seeing it in 2.2.2

[ghost]

@paul-javs Yes me too, same on 2.2.2 hoping for a (free) solution still

[orlangur]

@magento-engcom-team needs to be rechecked on 2.2.2.

[robertkent]

So, I've got the same issue on 2.2.3 - we migrated from 1.7 to 2.2, we're on single-store mode. If we update any URL key and ask it to produce a rewrite - nothing happens.

The URL key changes in admin but is still the old one on frontend. If I try to go to the new URL on frontend I get a 404. I can't believe how broken this is?! Is there a way to fix this manually?

I've tried the hack of coming out of single store mode, saving a product with the new URL key to the website and then visiting on the frontend - works with new URL but there's no rewrite for the old one...just a 404.

[wescey]

This problem still exist in 2.2.2 or specifically URL rewrites doesn't do the job. @magento-engcom-team

[JacobDrummond]

For everyone having issues with this issue, a workaround was outlined here.

This bug is annoying, but it shouldn't prevent go-lives.

[wescey]

@JacobDrummond does this affect the categories URL structure aswell? Trying to redirect a category path but it doesn't come through.

[jjcsinke]

I found this somewhere else:
https://github.com/olegkoval/magento2-regenerate_url_rewrites/tree/master/Console/Command

seems to work OK.

[MateuszChrapek]

@wescey have you encountered this problem with fresh 2.2.2 install, or have you upgraded / migrated from one of the previous versions? It'd be helpful to pinpoint if this issue is linked with upgrading Magento version since I can't reproduce this problem with 2.2.2 version.

[magento-engcom-team]

@wescey , @koopjesboom , @paul-javs , We were not able to reproduce this issue by following the steps on lates 2.2.3. Please provide more detailed steps to reproduce or try to reproduce this issue on a clean installation or latest release.

[magenx]

magento 2.2.3.
we have two stores , product assigned to both.
changing product names and url keys in selected store view scope.
saving.

indexer:reindex
cache:flush

seo url NOT created.

url left like this:
http://shop.tld/catalog/product/view/id/2/s/product-en-store/category/4/
http://shop.tld/catalog/product/view/id/2/s/product-se-store/category/5/

=======

UPDATE:
it only works for new products entered manually ,
old, migrated and imported products - not working.

[hypershopbv]

This issue is still present in 2.2.2 and 2.2.3. When will there be a fix?
Updating url_key on specific store view level does not update the url_path, which makes the url rewrite incorrect.

[parthipanpargunan]

Working on #dmcdindia

[magento-engcom-team]

@parthipanpargunan thank you for joining. Please accept team invitation here and self-assign the issue.

[parthipanpargunan]

@magenx @ hypershopbv

We can't reproduce this issue and tried with Magento 2.2.1 and Magento 2.2.3 versions its working fine. Please provide more detailed steps to reproduce or try to reproduce this issue.

Note :
Tried with new product as well as imported products.

[hypershopbv]

It only appears to happen on products that have been imported by the migration tool. Does not matter if we use single store or multistore.

Using a rewrite module is a patch, but does not solve the actual problem. Somehow the rewrite engine does not kick in on imported products.

[orlangur]

Hi @hypershopbv, then there is nothing to fix here from this repo perspective, problems with data migration from 1.x must be reported in https://github.com/magento/data-migration-tool repository.

[hypershopbv]

Sorry, this also happens on new added products. I know you guys want to close issues as soon as possible, but this is a serious core bug.

[archonkulis]

I'm also seeing this in the Magento 2.2. All I know is that the client used some kind of migration tool ( don't know the details, nor the from which version, nor which migration tool, etc )

But, what I have noticed, is following:

There are url_path entries in the database for the product, which aren't updating when you save the product in the back-end. Only url_key is updating.

Then, there is the following function:

vendor/magento/module-catalog-url-rewrite/Model/ProductUrlPathGenerator.php::getUrlPath(...)
Which has the following code:

        $path = $product->getData('url_path');
        if ($path === null) {
            $path = $product->getUrlKey()
                ? $this->prepareProductUrlKey($product)
                : $this->prepareProductDefaultUrlKey($product);
        }

Which basically gets url_path and if it doesn't exist, it gets url_key. ( called from vendor/magento/module-catalog-url-rewrite/Model/ProductScopeRewriteGenerator.php::generateForSpecificStoreView(...) )

And, because url_path isn't updating when you save the product in the Magento back-end, what I tried is to simply remove all entries with url_path from catalog_product_entity_varchar. ( Be careful to remove only products url_path and not category url_path ).

It's similar to what @peterkeijsers suggested, except that I deleted it for all stores, not only for '0' ( delete from catalog_product_entity_varchar where attribute_id = (select attribute_id from eav_attribute where attribute_code = 'url_path' and entity_type_id = 4); ).

Now, when you re-save the product ( you will need again to change the url key, then save product and then change it to the value you need ), it will update the url_rewrite table and new url will work.

I think Magento devs should check if url_path is even needed for the products and if it's not needed, then remove it from migration tool ( so that it doesn't create this url_path at all ). And, if it's used, then the value of url_path should also be updated when the product is saved. It's really surprising how no one has debugged this so far for almost 2 years. Turned out to be relatively easy fix ( taken into account this hasn't been closed for 2 years ).

Cheers

[orlangur]

@hypershopbv new products on a clean instance or on instance migrated from M1?

Just that bugs in migration tool should be fixed in migration tool, not in core.

[hypershopbv]

Hi @archonkulis,

Your fix works perfect! I also noticed that Magento does not use the url_path when saving the product, so should be removed from the code. However, when using your fix, redirects do not work anymore.

When i change an URL key, the new url is created, but the old URL will not redirect to the new one.

[archonkulis]

@hypershopbv Yep noticed that as well. Will try to fix it sometime this or next week and will keep you updated.

[hypershopbv]

@archonkulis, you will find a fix here:
https://github.com/magento/magento2/issues/13240

Has been fixed in 2.2.4, but cannot be used since there is a bug in 2.2.4 for multistores.

It seems the Magento core team finds it more important to include third party extensions (which do not work properly, like Klarna destroying the editor in backend) instead of fixing core bugs...

[DanielRuf]

It seems the Magento core team finds it more important to include third party extensions (which do not work properly, like Klarna destroying the editor in backend) instead of fixing core bugs...

Sorry but this is not true. The team consists of many contributors and volunteers who invest their free time in improving Magento. There are many issues and many people work on them.

Regressions happen and extensions can affect other things too.

[hypershopbv]

@DanielRuf regressions can happen indeed. Can you tell me if there will be a fix like @archonkulis suggests?

[DanielRuf]

@DanielRuf regressions can happen indeed. Can you tell me if there will be a fix like @archonkulis suggests?

Not sure, did anyone who found a solution / fix also provide a PR?

[orlangur]

@archonkulis @hypershopbv repeating my question, are you able to reproduce an issue on a vanilla Magento 2.2 installation?

There was another bug report related to url_path recently, https://github.com/magento/magento2/issues/16202. Is it the same problem? Looks like @hostep suggestion

I believe Magento should get some new command line commands for bin/magento which looks at all category's url_path attributes, and fix those if incorrect, and then also (maybe in a separate command) re-generate url rewrites (with an optional flag for creating 301 redirects, for shops already live vs shops in development).

would solve this issue as well.

[hostep]

@orlangur: this thread is about the url_path of Products, #16202 is about url_path of Categories, these are completely different things.

But, there is indeed a problem with the url_path of products, namely: it should always be empty. If you create a Product in the admin of Magento, it will never fill in the url_path.
But if both a url_path & url_key exist for a product, the url rewrite mechanism takes the url_path into consideration (probably some left over code from Magento1), and it might be that the url_path & url_key are different (because the url_path is never updated by Magento when changing the url_key), so that can lead to incorrect url rewrites being generated.

The fact that the url_path gets filled up, is most likely a problem caused by the data migration tool, which I wrote about in here: https://github.com/magento/data-migration-tool/issues/541

My suggestion for people running into problems like this, is to manually delete all entries in the catalog_product_entity_varchar table for the attribute_id which matches the attribute url_path for the Product entity (can be found in the eav_attribute table), and then regenerate the url rewrites using some third party tool, since there exist no functionality (yet?) in Magento itself for this. And please, never do this on production environment without extensive testing locally or in a staging environment!

But then you still have to deal with the gigantic enormous amount of bugs in Magento2 for generating the correct url rewrites on storeview level, which is an enormous pile of shit which nobody from Magento seems to be bothered with, even though me and others have been posting issues for these things in the last 2 years, and not much has been improved since then, only some slight tweaks here and there, but no full fix yet.
It's one of the biggest problem Magento is having since Magento2 was launched, in Magento1 this was all very stable (except for when you had two products with the exact same url key, but that's a blast from the past).

(All this is from memory, from some experience from a couple of months ago, so it might not be 100% correct)

And I completely 100% agree with @hypershopbv:

It seems the Magento core team finds it more important to include third party extensions (which do not work properly, like Klarna destroying the editor in backend) instead of fixing core bugs...

[archonkulis]

@hypershopbv You said: "Has been fixed in 2.2.4, but cannot be used since there is a bug in 2.2.4 for multistores." - do you know what kind of bugs there are for multistores?

[act3602281]

I am on 2.2.4, I duplicated an existing product, save and then try to edit the URL. It does the same thing as orginal issue it shows the new URL but it really doesn't update.

[KSaho]

Thank you JacobDrummond. Your solution works. It has been an issue for a while. Running Mage 2.2.5.

[ghost]

Issue is not reproducible on a clean Magento 2 installation.

[ghost]

@maxhanna

Thank you for pointing this out.

Quote:
"What does not make sense here is that someone is selling a solution to this rather then having the developers actually fix the problem. Thlassche vs magento devs, Thlassche 1, magento dev 0. "

The magento community and other Open-source platforms will some day be a marketplace for solutions if this continues.
To mention: This particular problem was told me took 10 hours with a hour rate of 90€
But these company's use the tool form Thlassche So the Company 900€ - 50 from Thlassche , Customer -900€

I am not stupid, but feel free to support this steeling from the unknown.
This is a side effect from putting (open-source) solutions in a Extension.

On Topic:
This problem is also still a part of magento 2.2.5

[hypershopbv]

This issue happens when data is migrated from Magento 1 to Magento 2. Magento 2 does not use the eav_attribute url_path, but the migration tool does migrate it. The code for URL rewrite has a check on this attribute. If it exists, the URL will be set from the url_path instead of the url_key. Deleting the migrated url_path values from the database and deleting the url_path from the eav_attributes table did the trick for us.

Please note: in our case it occured when migrating data. On a clean Magento install this issue does not occur, since there is no url_path.

[ghost]

This problem is also still a part of magento 2.2.5

@hypershopbv this is Magento Data Migration Tool issue.

[KSaho]

@hypershopbv
I have just purged MySQL and Magento 2.2.5 from my machine and reinstalled it (I tend to do this frequently for testing purposes) and I reinstalled Magento 2.2.5 via Composer.

URL_PATH is a part of the eav_attribute table by default.
https://imgur.com/a/FQ9tpob

I will continue looking for other URL_PATH values in the live server DB dump and cross reference them with my new Magento install. I don't want to be too hasty in deleting anything from the live server's DB.

Thanks for the info.

EDIT:
I forgot to mention that the previous fix doesn't allow me to change everything (in relation to my post above). Certain product URLs are changed, but a good number have not.

EDIT 2:
Where is the URL_PATH checked in the Magento code? I am looking for it now, but just in case could you tell me where I can disable this? I will put it in my own module as a walk around fix for this issue, and hopefully I can then go on and fix our URL_KEY issue.

[hypershopbv]

Hi @KSaho
That is correct, but Magento does not set an url_path by itself. Only way this might happen is during the data migration.

Please let me know if you have been able to fix your problem. It did work for us.

[KSaho]

It seems that all url_paths are null and that this issue wasn't the problem.
I seem to have this issue:
https://github.com/magento/magento2/issues/9205

I have a working solution for that problem too.
Thanks for the help.

[ghost]

All credits go to my friends of Ubertheme, they gave me this solution:

To re-generate the URLs rewrite for categories and associated products, you could do steps below:
• Create a new root category named ‘Temp Root Category’
• Open Stores management, edit the default Store of the default website and set the ‘Root Category’ form field to the newly added root category ‘Temp Root Category’ and click Save button.
• Once done, open Stores management once again, edit the default Store of the default website and set the Root Category form field to the main root category which you want to publish in the storefront again and click Save button.
• Magento will regenerate categories and associate products URLs rewrite in this step. It might take sometime to complete this task (It depends on the volume of categories and associated products)
• And then, re-index the data and clean the Magento cache.

Tell me if this is working for you.

Best regards

[magento-engcom-team]

Hi @JacobDrummond. Thank you for your report.
The issue has been fixed in magento/magento2#18566 by @oleksii-lisovyi in 2.2-develop branch
Related commit(s):

• 7169f0442658ec21c6a5c215269d8bafcff71093
• 9b0586e96248c6753688a417cde68a89e532907c

The fix will be available with the upcoming 2.2.8 release.

[magento-engcom-team]

Hi @JacobDrummond. Thank you for your report.
The issue has been fixed in magento/magento2#19170 by @p-bystritsky in 2.3-develop branch
Related commit(s):

• 284daec007cc9cc5bacc736e3d6ce00ebdf751ef

The fix will be available with the upcoming 2.3.1 release.

[jaxtheking]

I can confirm that saving a product now does update the URL rewrite correctly.
However, since I've upgraded to 2.3.1 from 2.3.0, I've been getting a new odd problem where a URL rewrite does not get created upon creation of a new product and the URL for the product is messed up (catalog/product/view/id/9027/s/test222/ instead of just catalog/product/view/id/9027).

However, if I edit the product and only if I change the URL manually to say test333, the URL rewrites gets eventually generated as expected.

My site is in single-mode. Am I the only one to get this problem on new products created after the upgrade??
@p-bystritsky Does this sound like it could be related to your commit?

Many thanks, Luca

[DavidVaini]

I have run into a problem upgrading to 2.3.1, after doing so, there are random products where the page url will return a 404: catalog/product/view/id/998, some other products work. The broken URL gets fixed only if I go into management and save the product again. Is there any workaround to find all these broken paths and update them?

[chrisbadley]

I have run into a problem upgrading to 2.3.1, after doing so, there are random products where the page url will return a 404: catalog/product/view/id/998, some other products work. The broken URL gets fixed only if I go into management and save the product again. Is there any workaround to find all these broken paths and update them?

Have you noticed that simple products are not affected, in my case only bundle and configurable products are affected. Also using 2.3.1.

[nicholasscottfish]

This does indeed look to be an issue with the data migration. @hostep's post helped me find the steps to "solve" the issue.

Note: Be sure to run the below steps in a development/staging environment and thoroughly test all url's are working prior to running on a live environment. Take a backup of any database before following any of the steps below.

1. Identify a product that has the issue; updating the Search Engine Optimization -> URL Key of the product does not reflect on the site after save as no redirect is generated.

2. In the database, open the 'eav_entity_type' table and get the 'entity_type_id' where 'entity_type_code' = 'catalog_product'

3. Open the 'eav_attribute' table and find the 'attribute_id' where 'attribute_code' = 'url_path' and 'entity_type_id' = {step2entityTypeId}

4. Open the 'catalog_product_entity_varchar' table and delete all entries where 'attribute_id' = {step3AttributeId}

You should now be able to update url's for products via the CMS. If you already have url's in the CMS that you would like to apply then you can follow step 5.

1. Install the olegkoval/magento2-regenerate-url-rewrites extension and run the following command:

php bin/magento ok:urlrewrites:regenerate --entity-type=product --save-old-urls

Note: Be certain to add the --save-old-urls param otherwise redirects won't be created for the old urls

Check your site, this should have updated all product ur's to those specified in the CMS.

[boter3]

We are experiencing same problem after upgrade to 2.3.1 - store is in 'single store mode'. New products get _catalog/product/view/id/9027/s/product_name/_ instead of _/product_name/_.

If we switch to multistore mode everything works as expected, but this is not an option.

For now the only solution for administrators is:

• create new product and save it without assigning it to any category
• assign this product to categories and save it
• now url generation works fine.

[m2-assistant[bot]]

Hi @engcom-Bravo. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [x] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [x] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [x] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [x] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 6. Add label Issue: Confirmed once verification is complete.

• [x] 7. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-Bravo]

Hi, @boter3 @orlangur ! I can't reproduce this issue on fresh 2.3-develop branch(
I tried with single store mode enabled and disabled) . If you want to update this issue you can reopen it.

[Kashiffrq]

@Cacasapo,

To clarify, here's how you regenerate URLs on a site where url_rewrites has become out-of-sync with product entities:

1. DIsable single-store mode:
   ![page-1](https://cloud.githubusercontent.com/assets/8377620/17472170/4a2839fa-5d41-11e6-8e25-20f9f0ea1aa3.png)

2. Select all products, then click "Update attributes":
   ![prod-2](https://cloud.githubusercontent.com/assets/8377620/17473550/efaf4f4c-5d48-11e6-806a-485098ed6e4e.png)

3. Assign products to all stores, then click save to regenerate all URLs:
   ![prod-3](https://cloud.githubusercontent.com/assets/8377620/17473566/ffda9426-5d48-11e6-99ca-d030ffefd606.png)

Great 💯 🥇 👍

[michel334]

Hi @veloraven,

Thank you for labeling this issue as a bug. Do you know if/when it will be escalated to "acknowledged" by developers?

This bug, along with #5923 and #5942, is blocking a go-live. What's the usual workflow and timescale for the Magento team to address bugs?

About 3 years, so good luck

[shrma-smit]

Please check this link for a workaround.

https://magento.stackexchange.com/questions/300948/magento-2-issue-with-product-url-rewrite-on-single-store-mode

[twoatechguy]

@sumitCueBlocks unfortunately your workaround doesn't work for me on 2.3.3.
edit: it's now working

[shrma-smit]

@twoatechguy This will work when you saved a new product or edit and save an existing one. I'm using this code on one of my site in Magento 2.3.3 and it is working fine for me.

[twoatechguy]

@sumitCueBlocks Thanks for following up, I created the module again and this time was successful in my tests on 2.3.3.

[SewHappy58]

I'm on Magento 2.3.4 and just uploaded my products from Magento 1 store and am facing this problem. No matter what I try, I'm still seeing the incorrect URL. Any suggestions? I have a multi-store and not sure if that is causing the issues as well

[dimplemenon]

@SewHappy58 Add url_key column in ur CSV, add unique URL for ur product (ex: name-sku) and then try to upload.

[DanielRuf]

For anyone stuck on this issue, I'd be happy to share a solution that works with Magento 2.0 (and later with some minor tweaks) feel free to contact me

Why not post it publicly? You would help many with this. Also 2.0 (and 2.1) is very old.

[Eddcapone]

If you get "Notice: Undefined offset: 32000 in /vendor/magento/module-catalog/view/adminhtml/templates/catalog/product/edit/action/inventory.phtml" when trying to update the attributes, then try this solution:

A flaw in the migration script left the setting empty for:

Stores -> Settings: Configuration -> Catalog -> Inventory -> Product Stock Options: Minimum Qty Allowed in Shopping Cart

Change the quantity to 1 for "ALL GROUPS" and save.