URL Regenerator

New

• Read-only URL key check for other extensions: Techimprovement\UrlRegenerator\Api\KeyProposalCheckerInterface::check(array $proposals). It checks proposed URL keys of products, categories and CMS pages ({type, id, store_id, key}, at most 500 per call) in order against one snapshot of the catalog and the URL Regenerator plan, and returns for each one ok, unchanged, conflict or invalid with a message, the conflicts found and the redirects that may be replaced (replaces).
• The check writes nothing, takes no lock and works while Enable URL Regeneration is No. Techimprovement SEO Toolkit 1.1 uses it before every URL key change it makes, so a new key never takes the URL of another page.
• A proposal is a conflict when a URL it creates belongs to another product, category or CMS page, to a custom URL rewrite or redirect, or to a redirect left by an earlier URL of another page, or when it would push another page off its planned key. A redirect at the new URL that leads to the same page is not a conflict: it is listed in replaces for the caller to delete before it saves the key. Conflict messages name what holds the URL (its name, or its ID when it has none), the request path and the store view.
• Products that are not visible individually have no URL, so in the check they neither block a key nor lose theirs.
• A default-scope key of a product or category that every store view overrides with its own key is ok with own_keys = true: it changes no URL.
• Simplified check for large stores (Model\TargetedKeyCheck): when the full check cannot run (above 20,000 store-scoped entities or 100,000 rows per source table or generated rewrites, or when the current plan of the store cannot be built), only the URLs of the proposal's own item are compared with the existing URL rewrites, and the ok message says so. Catalogs with content staging are still rejected.

Improved

• Model\Planner::requestPathKey() is public, so the check compares paths exactly as the planner does (case, accents, percent-encoding and a trailing slash are ignored).
• Model\SnapshotCollector::collect() has an optional second argument $reloadConfig (default true). The read-only check passes false and reads the cached configuration instead of rebuilding the configuration cache.
• Model\Planner::build() reads the snapshot option claim_invisible (default true, so batches plan as before); the check passes false.

Upgrade notes

• No database changes. Run bin/magento setup:upgrade and bin/magento setup:di:compile after updating.
• Above the limits of a batch the check falls back to the simplified check. On catalogs with content staging every proposal is invalid.

New

• Admin tool under Marketing › SEO & Search › URL Regenerator that regenerates the URL keys and URL rewrites of products, categories and CMS pages of all storefront store views in one coordinated batch.
• Preview first: a preview changes no URL, shows the key and path changes page by page and can be downloaded as a complete JSON plan. Apply writes exactly the reviewed plan in one database transaction, or is refused when the catalog changed after the preview.
• Journal of every batch with the exact before and after values, and Roll Back This Batch (newest batch first), also while regeneration is disabled.
• Conflict rules: enabled entities win, products before categories before CMS pages, categories with more assigned products and newer products win; losing products get a random six-character suffix, losing categories and CMS pages their entity ID; keys of disabled entities end in -disabled.
• Conflicts checked against the real request path of each store view, including URL suffixes and category paths; manual redirects and manual aliases of existing entities are protected.
• Separate admin permissions for viewing, previewing, applying, rolling back and configuration; the module starts disabled (Enable URL Regeneration, Default Config only).

Other changes

• Initial release.