baldwin-agency / magento2-module-url-data-integrity-checker

Magento 2 module which can find potential url related problems in your catalog data
MIT License
262 stars 28 forks source link

Ignore Not Visible Products #31

Closed sprankhub closed 2 years ago

sprankhub commented 2 years ago

First, thanks a lot for this useful tool!

Shouldn't we ignore products, which are set to "Not Visible Individually" in the catalog:product:integrity:urlkey command? The reason is that these products are ignored when catalog URL rewrites are generated, see \Magento\CatalogUrlRewrite\Model\ProductUrlRewriteGenerator::generate. Hence, I think we need to add ->addAttributeToFilter('visibility', ['neq' => Visibility::VISIBILITY_NOT_VISIBLE]) here:

https://github.com/baldwin-agency/magento2-module-url-data-integrity-checker/blob/654800a37c48db9a754b10e08337ecb1a9913aa3/Checker/Catalog/Product/UrlKey/DuplicateUrlKey.php#L79-L88

Does that make sense to you?

hostep commented 2 years ago

Hi @sprankhub

Thanks for the feedback.

I'm not really in favor of this because once you put a product to visible and it has an incorrect url_key it will generate an incorrect url rewrite. Suppose a shopowner is preparing some product information in the backoffice while keeping the product invisible and at at certain moment wants to put it visible. In that case it would still be good - in my opinion - if the tool reports issues with that products' incorrect url_key.

sprankhub commented 2 years ago

That is indeed a fair point. However, if you have a lot of configurable products, where the simple products are usually not visible individually, this can lead to a lot of false positives. Yes, theoretically, the URL key should be unique. However, after migrating from M1 or importing data from other systems, they may also be the same.

Do you think it would make sense to have an option for that?

hostep commented 2 years ago

Ah, a configurable with simples, that didn't come to mind yet, thanks for the clarification! I'm still not 100% convinced since if you would generate the products in Magento 2 backoffice they would all have a unique url_key, so I'm considering this more of a bug in the migration process or in the import process if that causes duplicated url_key's.

But I'll see what we can do with an extra option.

Thanks for the suggestion!

sprankhub commented 2 years ago

I'm considering this more of a bug in the migration process or in the import process if that causes duplicated url_key's

In theory, you are right. In practice, M1 had the same URL key for all simple products assigned to a configurable product. Hence, if you simply migrate the M1 data (e.g. via the data migration tool), which is not unusual, you'll exactly get that issue.

Thanks!

hostep commented 2 years ago

Hey @sprankhub

This is now available in version 1.4.0 of this module, you can configure this using: Stores > Configuration > Catalog > Url Data Integrity Checker The option is disabled by default, so you'll need to enable it.

An added benefit of this, is that it makes the product url checkers a lot faster and uses fewer memory, if you have a lot of invisible products on your shop.

Thanks for the suggestion!

sprankhub commented 2 years ago

Thanks, @hostep! Awesome!

mortenbirkelund commented 1 year ago

Ah, a configurable with simples, that didn't come to mind yet, thanks for the clarification! I'm still not 100% convinced since if you would generate the products in Magento 2 backoffice they would all have a unique url_key, so I'm considering this more of a bug in the migration process or in the import process if that causes duplicated url_key's.

But I'll see what we can do with an extra option.

Thanks for the suggestion!

Actually, you can create the products in the backoffice with same url key.

When creating the variants for the configurable products, then they will all get a different name (and thereby also a different url, key). However, if you decide to rename all the variants to the same name before saving, then they will all also get the same url key.

IMO it is a strange decision to give all your variants the same name, but none the less, we actually had a customer who decided to do just that.

So it means that it is not only happening when migrating from M1, but can also happen when working in M2.

Thanks for the new setting @hostep and thanks @sprankhub for debugging and raising the issue.