[5.1] SEF: Implementing index.php behavior

[Hackwar]

Summary of Changes

Joomla has been improving its SEO performance constantly and one issue which is still open is the behavior of index.php in URLs. In some rare cases, the URL might end with index.php, even though that is not needed anymore, resulting in duplicate content, since the same URL without index.php gets the same result. A common case is the URL for the homepage, which often enough contains that reference. Another case is sites which switch from non-rewrite to rewrite the URLs.

This PR introduces one new setting in the SEF system plugin. This setting enforces removing the index.php from the URL with a redirect when the URL starts or ends with index.php. This setting only takes effect if URL rewriting is enabled.

This PR depends on #42692.

I'd like to thank ithelps Digital for sponsoring this feature.

Testing Instructions

1. Apply the PR
2. Enable the option in the SEF system plugin.
3. Open a URL with /index.php/ at the beginning and see that the site is redirected to the version without.
4. Open a URL with /index.php at the end and see that the site is redirected to the version without.

Link to documentations

Please select:

• [X] Documentation link for docs.joomla.org: https://docs.joomla.org/Search_Engine_Friendly_URLs

• [ ] No documentation changes for docs.joomla.org needed

• [ ] Pull Request link for manual.joomla.org:

• [ ] No documentation changes for manual.joomla.org needed

[brianteeman]

1. Instead of adding another option which a large % of users will never use why not simply do this in the htaccess.
2. the description is confusing "Remove unneeded index.php from URLs" because it sounds the same as the existing option which removes index.php
3. If accepted dont you need to update the installation and the configuration.php.dist
4. What happened to the requirement for all new "features" to be accompanied with documentation

[Hackwar]

To the other points: see other PR

To 2.: I will reword that.

[brianteeman]

I'm misunderstanding something

Why would you have the first option enabled but not have the second option enabled

[Hackwar]

The first option modifies how URLs are created. The second one modifies how URLs are parsed. Since people are doing awful things in routing, we can't be sure that their changes don't break this feature, this the 2 options can be enabled separately.

[brianteeman]

Honestly I cant see the value for core of adding 4 extra options (this PR and the other one) to address issues in other peoples code. Thats a maintainability nightmare and a usability issue for all those people that wonder what these options do etc. If, as you say, core does not create these urls then it should be for the extension dev to fix their own problem. And if they wont the site owner can easily create an htaccess rule.

[ot2sen]

Brian got quite a few valid points here. Why? The instruction for test even tells why not. "Unfortunately for testing, core Joomla does not produce such URLs anymore, so we need to do some trickery to trigger the problem." Then why is it a core issue?

Wouldn´t it better go into a checking feature for the official extension JED Checker, for it to teach third-party devs how not to do awful things in routing? IE, do this and you won´t get approved for fame and showcase. Fix it and get in. https://extensions.joomla.org/extension/jedchecker/

[Hackwar]

And at the same time, our users are complaining about sub-par behavior of Joomla. So, should we shift the blame and force users to be stuck in that situation or provide a solution for now to get around that?

I'm happy to add this to the JED checker as soon as you solved the Halting problem.

[brianteeman]

Adding more options is never a solution. Those same users will still complain as they dont know about the options (unless they ask). If its such a real problem (I have no idea) then make the changes without options

[brianteeman]

Confusing with the existing option

[Hackwar]

I changed the feature and description above.

[SniperSister]

I have tested this item :white_check_mark: successfully on 4e471b01f9f282ebd85afe86e69b44014a1e5112

Works as described!

---

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

[viocassel]

I have tested this item :white_check_mark: successfully on 4e471b01f9f282ebd85afe86e69b44014a1e5112

---

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

[richard67]

Setting RTC as it has 2 good tests, but setting also the RMDG (release manager decision queue) label because this PR is subject of discussion among maintainers.

---

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

[richard67]

Code style fixes and strict comparison should be done. After that, I think it just needs a review but not new human tests.

[Hackwar]

After some discussions, we decided to switch this to use 301 redirects instead of 303s.

[richard67]

Back to pending as there have been made changes. @SniperSister @viocassel Could you test again? Thanks in advance.

---

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

[SniperSister]

I have tested this item :white_check_mark: successfully on c35a3a0252205465fc9a14bd30a9b61c8d41e58e

---

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

[viocassel]

I have tested this item :white_check_mark: successfully on c35a3a0252205465fc9a14bd30a9b61c8d41e58e

---

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

[richard67]

RTC

---

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

[Hackwar]

Link to documentation has been added.

[bembelimen]

Thx