Keep the sitemap <loc> a localized URL - #123
Conversation
The winter.sitemap.addItem listener rewrites <loc> to the alternate for the default locale and clones a <url> for each of the others. When the default locale is not among alternateLinks the rewrite never happens and the element keeps the untranslated URL it was built with — a URL that belongs to no locale and, on an install that prefixes locales, redirects. The sitemap then advertises a redirect instead of a canonical URL. A listener on pages.menuitem.resolveItem may legitimately narrow alternateLinks: serving a subset of the locales per host, for instance. Falling back to the first alternate keeps every <loc> a real localized URL. Unfiltered alternateLinks always contain the default locale, so nothing changes for the usual case.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughSitemap generation now selects the default locale URL for Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Sitemap entries now use the default localized URL when available and otherwise an available alternate locale, avoiding untranslated or redirecting primary URLs for filtered locale sets. No merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 PHPStan (2.2.8)Composer install failed: dependency resolution error. Check composer.json and composer.lock for version constraints. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
The
winter.sitemap.addItemlistener rewrites<loc>to the alternate for the default locale and clones a<url>for each of the others:When the default locale is not among
alternateLinks, the rewrite never happens and the element keeps the untranslated URL it was built with. That URL belongs to no locale and, on an install that prefixes locales, redirects — so the sitemap advertises a redirect rather than a canonical URL, and the page also gets an extra entry no locale claims.A listener on
pages.menuitem.resolveItemmay legitimately narrowalternateLinks. Ours does: three storefronts share one install, each on its own host serving its own subset of locales, and a host's sitemap must not announce hreflang for another host's languages. On the storefront whose locales exclude the global default, every page ended up with a redirecting<loc>.Change
Fall back to the first alternate when the default locale is absent, so a
<loc>is always one of the alternates:Impact
Unfiltered
alternateLinksalways contain the default locale, so$primaryLocaleis the default locale and behaviour is unchanged for a normal install. Verified on ours: the sitemap of the storefront that does serve the default locale comes out byte-identical before and after, hreflang ordering included, while the storefront that does not went from 115 redirecting URLs to none.Summary by CodeRabbit