I see what you want to achieve here, but:

• how can a new feature not require documentation (especially such a critical?)
• the whole feature sounds like it's solved when we implement canonical tags

Sorry about the documentation. It was late yesterday and I will create documentation for the whole SEF thing in the next 48 hours.

Regarding the canonical tag I would disagree. To me, the canonical tag is just a bandaid to get around using the right URL and thus using the right URL in the output is the first step (which we do in Joomla anyway). The second step would then be to redirect wrong URLs to the right ones instead of keeping them and slapping a canonical on there.

I have tested this item ✅ successfully on 6ae36cb

I have tested this item ✅ successfully on 6ae36cb

RTC

Link to documentation has been added.

I've played around with this PR using the "testing" dataset in Joomla 5.1.x.

I've run into an edge case:

• The testing dataset has an article that isn't accessible via it's own menu item but only via a category list, it's article ID 1, "
  Administrator Components": index.php/content-component/article-category-list/extensions/components/administrator-components
• If I now open the "Archive Module" menu item (/index.php/content-component/archive-module) and add an extra query parameter to override the article id with the ID 1 (/index.php/content-component/archive-module?id=1) I'm receiving a redirect to this URL: /index.php/content-component/archive-module?view=article&id=1, whereas my expectation would have been a redirect to the category list URL mentioned above.

I'm aware that this is not quirk of the current PR but of the router in general. However, the current PR might increase the effects.

That's why I'm asking myself if we should limit the redirection to "clean" URLs without any leftover query parameters.

Thoughts? @Hackwar

I agree, this sounds good. I'll add this to the PR.

I encountered additional issues and will convert this back to draft first.

Back to pending.

What about a generic fetch/xhr request to index.php?option=com_xxx&...
Do you mean that with this option enabled it will no longer be possible to perform a GET request to a raw Joomla URL?
This would be too much generic.

What about a generic fetch/xhr request to index.php?option=com_xxx&...

Fetch / XHR requests do follow redirects automatically.

it works, perfect

I have tested this item ✅ successfully on 33d1153

I've tested the following scenarios:

• local installation for test dataset, crawled whole site before applying the patch and enabling the feature - after applying the patch, i recrawled the site and got no 404s
• I've tried various non-sef URL pattern (index.php?Itemid=..., index.php?option=com_users&view=reset&Itemid=...) and got the expected result
• I've tested the example provided in the test instructions

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42854.}

I refactored the PR to use the new option from #43432 to reduce the number of options we add here.

I have not tested this item.

Sorry, i can't reproduce the error with the given instructions. I always be redirectetd to the error 404 page.

I have tested this item ✅ successfully on 09f8ba3

I tested this using configuration which resulted in a /component/content URL. Then I enabled a menuitem which matched this URL and the code successfully did a 301 redirect to the SEF URL for that menuitem. I repeated this for several cases and they all worked ok.

I also set up a site module which was a list of articles in a given category. The URLs of the articles were based on a category list menuitem, and when I clicked on one of the links it routed me correctly to the article.

I then set up a menuitem pointing directly at the single article and reloaded the site page. It didn't redirect to the new menuitem (as there weren't any query parameters on the URL). But when the module displayed the links it utilised the menuitem for that single article.

RTC

Thanks @Hackwar !