all these changes to sef have caused multiple problems that have either had to be reverted, fixed or have yet to be discovered. These changes clearly need much more testing in the real world, and not just following the limited testing instructions in the prs. They should all be reverted and bumped to 6.0

hm, I still have it working, you testing on beta or on recent branch?
maybe it already fixed by #43063 ?

And how you get backend "error page" in the preview? Not that it should be frontend "error page"?

I'm unable to reproduce the issue.

Latest 5.1.x dev branch, SEF plugin enabled, "force Trailing slash"-option enabled, preview and accessibility screen both work as expected. I've tested it with enabled and disabled language filter plugin and enabled and disabled SEF mode.

I'm unable to reproduce the issue.

Latest 5.1.x dev branch, SEF plugin enabled, "force Trailing slash"-option enabled, preview and accessibility screen both work as expected. I've tested it with enabled and disabled language filter plugin and enabled and disabled SEF mode.

"force Trailing slash" should be "without traling slash" for the error

Found how you can replicate it and the cause

1. Install the sample testing data
2. Create a new article in the category "uncategorised"
3. Save article
4. Preview article - its broken
5. change the category to "blog"
6. Save article
7. Preview article - its working
8. change the category to "uncategorised"
9. Save article
10. Preview article - its broken

The problem is because there is no menu that would display any article in the "uncategorised" category. Confirm that this is the cause by

1. Create a new menu item of type category list for the category "uncategorised".
2. Repeat steps 2 to 10 above.
3. Everything works
4. Unpublish the menu item and you are back to getting the errors

hmhm, it still works for me.
I have article in "uncategorised", preview works,
the iframe URL is not "sef" like /en?view=article&id=76:test-nomenu-route&catid=2 (that another issue), but it works.

With options:
Search Engine Friendly URLs: yes
Use URL Rewriting: yes
Trailing slash for URLs: Enforce URLs without trailing slash

Maybe there some another option missing?

The problem is because there is no menu that would display any article in the "uncategorised" category. Confirm that this is the cause by

I can reproduce the issue, however it remains the same after disabling the newly introduced option. I even switched back to the 5.0 branch and it shows the same behavior. Are we sure it's related?

it only happens with this one option as shown in this video

Ok, finally I was able to reproduce the issue!

In the described scenario, the preview URL in the iframe without the enforced removal for a site residing in the domain root looks like this: /?view=article&id=73:uncategorized-article&catid=2

After the removal is enforced, the leading slash is gone and the URL, that before was relative to the domain root, is now relative to the current context, which in this case is the administration URL, causing the browser to load administrator/?view=article&id=73:uncategorized-article&catid=2

I see two potential fixes:
a) use an absolute URL while generating the iframe URLs in the backend - we are talking about roughly 10 places
b) don't apply the rule when generating frontend rules from a backend context

Any preferences?

Ok, finally I was able to reproduce the issue!

yay - i am not going mad

I see two potential fixes:
a) use an absolute URL while generating the iframe URLs in the backend - we are talking about roughly 10 places
b) don't apply the rule when generating frontend rules from a backend context

Any preferences?

Revert this code. You are proposing band aids and not solutions. We can't afford to break urls on a live site.

So far we have seen several issues from regular testers. Who knows how many issues we will see when this code hits a live site with real components etc. The risks far outweigh any perceived benefits.

We know from prior experience that touching this code will have consequences breaking sites and that had to be reverted with an emergency release.

Without a test suite that will measure all the types of urls that can be exist now and that this, and any other future changes, can be measured against this should be reverted. Too risky especially as the "gains" are so minor and can be addressed without touching any code as already discussed.

Revert this code. You are proposing band aids and not solutions.

I disagree. Especially option b, excluding the rule in non-site apps, is a commonly used pattern in the existing SEF plugin and a gazilion other places within the CMS.

We can't afford to break urls on a live site.

We don't break live sites. It's a new feature that is not enabled by default. A user has to actively make the decision to use it.

you asked for my preference and I gave it.

you asked for my preference and I gave it.

Perfectly fine! It's a valid opinion! :)

another possibility is to adopt drupal's experimental policy. that would allow the code to be merged knowing that it may cause unkown issues and will not be tied to a b/c policy etc.

because of the different structure in joomla then they could be marked in the ui like below

reference https://www.drupal.org/about/core/policies/core-change-policies/experimental/policy-and-list

This would allow time for the previously mentioned test suite to be created before the code is removed from the experimental list

This would allow time for the previously mentioned test suite to be created before the code is removed from the experimental list

That's a great idea :) like it!

would also be suitable for #42850

Closing since we have a fix with #43074.

@SniperSister I see that neither of your proposed solutions have been applied

Feel free to propose a different PR. Looking at the proposed solutions, I don't really want the router to work differently in the backend than in the frontend, since that would mean the URLs in mails, etc. would be different. I also don't want to change the code at different places because it would mean all other code out there would have to change as well. So I did the third option and solved the problem by not deleting the leading slash when we actually only want to remove the last trailing slash.

I see that neither of your proposed solutions have been applied

Correct, both of them are stupid