This looks like it addresses a 7 year old bug #15025

I have tested this item ✅ successfully on 784cfda

I have tested this item ✅ successfully on 784cfda

I have tested this item ✅ successfully on 784cfda

RTC

In favour of the bug fix. Not in favour of the option. As such this should be in 4.4 as a bug fix and not as a new feature in a future release

Link to documentation has been added.

This is a change in behavior and not just a bugfix. That's why we wont get around this option. For Joomla 6.0 this option will be removed again and the behavior added to the normal behavior of the Add Suffix to URL option. So as long as we will stick to semantic versioning we will have to add this as an option.

Failed. Too bad, because it's a strong request from a client of mine and for that reason SEO agency it's working with ask to migrate to another CMS...

@Nuyonuyonoina could you comment what is failing on your end? Otherwise I can't fix that and this PR wont be merged.

failed. followed the instructions, but if I remove .html from the URL it does not get added back

I have tested this item ? unsuccessfully on 784cfda

failed. followed the instructions, but if I remove .html from the URL it does not get added back

Tested on PHP 8.1.27, 10.4.32-MariaDB, Joomla! 5.1.0-alpha4 Alpha [ Kudumisha ] 20-February-2024 16:31 GMT

the pages can now be accessed with 3 URLs: with .html with / and without /. All show the same article

Did you apply the PR #42692 as well?

yes, both patches are installed and active in the patchtester

Found out, why it failed! I had yootheme installed, although not set as standard template, the framework is doing something that interferes with this patch. When I deactivate all yootheme extensions, the patch works

@saschadube the yootheme system plugin is keeping this patch from working. Any idea what is going on?

My assumption would be that they are creating the router object so early in the process that no other plugin is able to run and thus these new options can't attach themselfs to the router. To be honest, this is something Yootheme needs to fix.

I've unset @webfeuerflo 's negative test result as it has turned out that it was not caused by this PR but by a 3rd party plugin.

Thanks, the next YOOtheme Pro version will resolve the problem with booting com_media and by that creating the SiteRouter too early. ?

Hello @Hackwar ,

today in the maintainer meeting we decided, that we would really like to have this function in core but there shouldn't be two parameters (one in the global configuration and one on the plugin). Could you merge them, so we have only one parameter in the global configuration and no in the SEF plugin? (so remove the xml + line 74 in the "if".

I'm sorry, but in that case I rather pull this PR back and not have this in 5.1. I'm not going to take the chances of sites breaking because this is enabled by default. There are way to many sites out there which have weird code to just take the chance on this.

I have noticed to late.

Can you please do not do redirect in parseRule?
The rule should do "rule thing", nothing more.
The same problem with #42702 (that already merged and should be also fixed)

I not very concerned about extra Option, however the redirect is a bigger issue.

Revert as it's a draft.

In the CMS maintainer meeting we talked about this again and the team agreed to the current implementation. Since it is to late for 5.1, I rebased this to 5.2, but 5.2 is in a desperate need of an upmerge... Anyway, this is theoretically ready to test.

Thank you, @SniperSister, I fixed that. @ceford, @nielsnuebel, @viocassel and of course anybody else who is intersted, would you be so kind to test this again, so that we can merge this for 5.2?

I have tested this item ✅ successfully on 5900b39

I see #42692 has been merged. I am using a cms clone - so I did a git pull them npm ci, applied the patch and I get this:

An error has occurred.

0 Call to undefined method Joomla\Plugin\System\Sef\Extension\Sef::setSiteRouter() 

I needed to disable the sef plugin in the database to get admin working again.

I have tested this item ? unsuccessfully on 5900b39

I see #42692 has been merged. I am using a cms clone - so I did a git pull them npm ci, applied the patch and I get this:

An error has occurred.

0 Call to undefined method Joomla\Plugin\System\Sef\Extension\Sef::setSiteRouter() 

I needed to disable the sef plugin in the database to get admin working again.

@ceford The comment about #42692 actually isn't true anymore and that PR actually has been reverted before the release of 5.1. Since this PR also doesn't touch that code, your git clone most likely is very outdated and should be updated to latest 5.2-dev before testing this.

My clone is up to date. I checked out 5.2-dev - title bar shows ‎5.2.0-alpha1-dev

The SEF plugin is enabled. I apply the patch and then all menu items in the back end give:

     0 Call to undefined method Joomla\Plugin\System\Sef\Extension\Sef::setSiteRouter() 

Call Stack
# 	Function 	Location
1 	() 	JROOT/plugins/system/sef/services/provider.php:42
2 	Joomla\DI\ServiceProviderInterface@anonymous/Users/ceford/Sites/joomla-cms5/plugins/system/sef/services/provider.php:22$97->{closure}() 	JROOT/libraries/vendor/joomla/di/src/ContainerResource.php:172
3 	Joomla\DI\ContainerResource->getInstance() 	JROOT/libraries/vendor/joomla/di/src/Container.php:95
4 	Joomla\DI\Container->get() 	JROOT/libraries/src/Extension/ExtensionManagerTrait.php:177
5 	Joomla\CMS\Application\CMSApplication->loadExtension() 	JROOT/libraries/src/Extension/ExtensionManagerTrait.php:99
6 	Joomla\CMS\Application\CMSApplication->bootPlugin() 	JROOT/libraries/src/Plugin/PluginHelper.php:232
7 	Joomla\CMS\Plugin\PluginHelper::import() 	JROOT/libraries/src/Plugin/PluginHelper.php:192
8 	Joomla\CMS\Plugin\PluginHelper::importPlugin() 	JROOT/libraries/src/Application/CMSApplication.php:765 

So I have to disable the plugin so I can revert the patch. It may be my installation that is the problem but I don't know what to do about it.

I have tested this item ✅ successfully on ef8201e

I have tested this item ✅ successfully on ef8201e

I have tested this item ✅ successfully on ef8201e

I tested this by just patching the changed files into my 5.1 instance.

I confirmed that with the global config set then the html prefix is restored after you remove it manually.

I also confirmed that an xml feed document was returned correctly whenever a prefix of .feed or a query parameter of format=feed was set in the URL.

@ceford could you please check if the problem still exists?

Thanks @Hackwar !