Just tested it: great addition!

Only one thing: when set in manually set redirect, the modal works ok, but after save, and the modal close, the alert message "set a redirect" is not auto-hidden.

Great idea

What happens in this scenario and will it cause too many redirects issues.

Set redirects to automatic
Create article in category a
Change to category b
Change back to category a

I have tested this item ✅ successfully

Environment: Windows/XAMPP, Joomla 6.1-dev

Tests:

Enabled System - Redirect plugin with "Create redirect on save" set to Yes
Changed article alias and saved
✅ Redirect automatically created in System → Redirects (old URL → new URL)
Tested Manually mode - message with "Create redirect" button appeared correctly

Result: Works as expected. Redirects created successfully for articles, categories, and menus when aliases change.

I have tested this item ✅ successfully on 9afea6f

I have tested this item ✅ successfully on 9afea6f

Redirects are automatically created when URLs change. Both automatic and manual modes work as expected.

What happens in this scenario and will it cause too many redirects issues.

Set redirects to automatic Create article in category a Change to category b Change back to category a

Not sure, if I understand correctly, but redirects are only executed, when the link is a 404, so if you change the category and back, the redirects are created but ignored (at least the one for the valid link)

yes you understand correctly. My "worry" is that if someone reorganise a site a few times they can end up with a lot of redirects.

If you change my scenario to
Create article in category a
Change to category b
Change to category c

then if someone visits the article link in category a they get a 404 and redirected to category b and get a 404 and redirected to category c

If you change my scenario to Create article in category a Change to category b Change to category c

then if someone visits the article link in category a they get a 404 and redirected to category b and get a 404 and redirected to category c

Yes that happens, it could be an issue, but that's more an architectural issue I would say, if you add a redirect link to your htaccess, you will also have this chain, if you not update every "former link" manually. Not sure if this can be fixed by code (I mean we could somehow....not sure if we should...)

Isnt it confusing to enable it in plugin - especially as its only for supported components which the user can't determine

I would have thought that this is something that should be enabled/configured per component in the integrations tab and that way you can easily see if a component supports this feature and set it per component. And finally you are styling this completely different to every other option in the core joomla ui. So I would be looking at something like this in the articles options (and any other component that supports this awesome feature)

I love the idea of this functionality but better to get it right than have to fix it later

will test some more scenarios tomorrow which I think might cause problems (or at least require documenting for the end user) such as content with its own menu item

I like the idea of having the option in the different component options, so I rebuilt the plugin and moved the options to the config of each component.

Doesnt create redirects when you use batch move to change the category

Doesnt create redirects when you use batch move to change the category

Yes, that was not part of this PR. The batch would have to be slightly rewritten (onbeforesave-events etc.) which I not want to do here, too. Probably in a later PR when this is merged.

experience tells me that will never happen and PLEASE restyle the xml so that it is consistent with the rest of the UI

experience tells me that will never happen

if it will never happen, then so be it :-)

@bembelimen I am running into an issue on one of my test sites...

I followed the testing instructions (from a site built with nightly build, sample data, added French, multilingual sample data, added Joomla Patch Tester, RegularLabs Cache Cleaner, then applied download package for this PR 46807)

I change article-fr-fr alias to article-fr-fr-new-location went to frontend and it wrote in the Redirects plugin/area:

is that because my site is in a sub-folder? I was a bit surprised by the non-SEF title under New URL
and then I check https://www.domain.com/_j61a4/fr/article-fr-fr, I get a 404 Page Not Found...

Also, shouldn't it be 404 Hits of 1?

@exlemor thanks for the test, added some multilingual routing things :-) Probably you could test again.

I have tested this item ✅ successfully on 6d38648

I have tested this again and it seems that it is successful :) Thank you @bembelimen!

I have tested this item ✅ successfully on 6d38648

I have tested this plugin:

##Set to manualy create redirect in options of the component

• Changed alias of an article and saved
• Message was shown with link to create redirect
• link opened popup with old and new url preset (correct)
• Save created the correct redirect
  The same for menu-item and category alias changes

##Set to automatically create redirect in options of the component

• Changed alias of an article and saved
• No message was shown
• The redirect was successfully created
  The same for menu-item and category alias changes

##Set to not create redirect in options of the component

• Changed alias of an article and saved
• No message was shown
• No redirect was successfully created
  The same for menu-item and category alias changes

  ---

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

Does it also work with unpublishing / trashing items and menu items?

@bembelimen I have an idea if this plugin's action were expanded to include the "remove article IDs" setting when a new SEF router is enabled.

If this plugin could create redirects for all articles on the website that previously had an ID to the version of the article without an ID.

I like the idea of having the option in the different component options, so I rebuilt the plugin and moved the options to the config of each component.

@bembelimen Hmm, but the PR shows the option only in the redirect plugin's config.xml. Do I understand something wrong in your comment? Or have you only forgotten to push some change? Silly me, haven't seen it's injected into the options in PHP code.

@richard67 it is injected into the component option and that works correctly. Its the second part of my comment that is ignored about the non standard UI in this PR

It should look like this

				<field
					name="redirect_on_save_admin"
					type="list"
					label="PLG_SYSTEM_REDIRECT_FIELD_REDIRECT_ON_SAVE_ADMIN_LABEL"
					description="PLG_SYSTEM_REDIRECT_FIELD_REDIRECT_ON_SAVE_ADMIN_DESC"
					default="1"
					validate="options"
					>
					<option value="0">JNO</option>
					<option value="2">PLG_SYSTEM_REDIRECT_FIELD_REDIRECT_ON_SAVE_ADMIN_MANUALLY</option>
					<option value="1">JYES</option>
				</field>

				<field
					name="redirect_on_save_site"
					type="radio"
					label="PLG_SYSTEM_REDIRECT_FIELD_REDIRECT_ON_SAVE_SITE_LABEL"
					description="PLG_SYSTEM_REDIRECT_FIELD_REDIRECT_ON_SAVE_SITE_DESC"
					default="1"
					layout="joomla.form.field.radio.switcher"
					>
					<option value="0">JNO</option>
					<option value="1">JYES</option>
				</field>

Thanks @brianteeman I was just busy the last days :-)

@bembelimen is this PR ready for testing? I just want to make sure.

Silly me, haven't seen it's injected into the options in PHP code.

so this plugin will also redirect pages like site.com/1-news-article to site.com/news-article?
if this option is enabled:

Silly me, haven't seen it's injected into the options in PHP code.

so this plugin will also redirect pages like site.com/1-news-article to site.com/news-article? if this option is enabled:

Easiest way is to test the PR and find it out :-)

Thanks to @HLeithner for some very nice ideas how the events are better handled. So it can be tested again.

This pull request has been automatically rebased to 6.2-dev.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Hi @bembelimen, looks like a neat feature - when you have the chance, could you resolve the conflicts, that way we can test it during the Friday PR Testing session (or earlier depending)? thanks. :)

Hi @bembelimen, looks like a neat feature - when you have the chance, could you resolve the conflicts, that way we can test it during the Friday PR Testing session (or earlier depending)? thanks. :)

@bembelimen I've allowed myself to fix the conflict. It was the use statements added by this PR here and another one in 6.2-dev in the meantime, both changes at the same place in file administrator/components/com_content/src/Extension/ContentComponent.php, and the resolution was to accept both changes (yours and theirs).

I have tested this item ✅ successfully on 74fdfd9

I have tested this by changing the category of articles to other categories. This worked fine with the manual and with the automatic option. Also a user with no permissions to create redirects was able to create the redirect in automatic mode. Changing the category of the articles back to the previous setting created a new set of redirects.

But there is another way to change the category of articles: By using batch processing. In this case, the redirects are not created. I'm not sure whether we should merge this PR without an additional PR for the identical functionality in batch.

I have tested this item ✅ successfully on 74fdfd9

I have tested this by changing the category of articles to other categories. This worked fine with the manual and with the automatic option. Also a user with no permissions to create redirects was able to create the redirect in automatic mode. Changing the category of the articles back to the previous setting created a new set of redirects.

But there is another way to change the category of articles: By using batch processing. In this case, the redirects are not created. I'm not sure whether we should merge this PR without an additional PR for the identical functionality in batch.

I'm very interested in this feature, because I have a use case for it: I routinely create some articles in one category (which gets some special handling on my site) and later change their categories to different ones, where they will remain. Without that feature (or manual creation of redirects), I get in trouble with the Google Serach Console.

I'm very interested in this feature, because I have a use case for it: I routinely create some articles in one category (which gets some special handling on my site) and later change their categories to different ones, where they will remain. Without that feature (or manual creation of redirects), I get in trouble with the Google Search Console.

I have tested this item 🔴 unsuccessfully on 74fdfd9

I could verify created redirect after applying PR
On manual redirect the link leads to a page without header

I have tested this item 🔴 unsuccessfully on 74fdfd9

I could verify created redirect after applying PR
On manual redirect the link leads to a page without header

On manual redirect the link leads to a page without header

Hint for further testing the redirect flags in com_content (articles) -> options -> integration appear when the PR is applied

On manual redirect the link leads to a page without header

This comment was created with the [J!Tracker Application](https://github.com/joomla/jissues) at [issues.joomla.org/tracker/joomla-cms/46807](https://issues.joomla.org/tracker/joomla-cms/46807).

Is this an issue?

@bembelimen is there a PR in preparation for the batch processing? - i'm a little bit uncomfortable having the batch processing not solved at the same time e.g. same release.

@bembelimen - thanks for the PR! Is there a PR in preparation for the batch processing? - i'm a little bit uncomfortable having the batch processing not solved at the same time e.g. same release.

@bembelimen tried to test with patchtester and get the error: The file marked for modification does not exist: phpstan-baseline.neon Download package is not available.

Fantastic idea! Thank you Benjamin @bembelimen 🙏
Waiting the new pre-built packages to test it 😀

@bembelimen Thank you for this great PR, actually this is on my wishlist since a decade :-)

My observations:

the automatic and manual creation in the menu does nothing, I do not understand the redirect on save on site for menus as there is no menu editor on the frontend, or did I miss a new feature?

the automatic creation for articles works until there is a menu item (I think thats correct) but it created new redirects for every change. It maybe should update the outdated ones before creating a new one so there is not a redirection chain.

instead of test-1 -> to test-2 and test-2 to test-3 and test-3 to test-4 it should be after all changes:
test-1 -> to test-4 and test-2 to test-4 and test-3 to test-4

instead of test-1 -> to test-2 and test-2 to test-3 and test-3 to test-4 it should be after all changes: test-1 -> to test-4 and test-2 to test-4 and test-3 to test-4

I would say that redirects should be attached to the article, category, and menu item, and not just as "link 1" and "new link 2," i.e., for example, there is "article 1" and in the article settings, all redirects created for the article would be shown, the same for categories and menu items.

@bembelimen - thanks for the PR! Is there a PR in preparation for the batch processing? - i'm a little bit uncomfortable having the batch processing not solved at the same time e.g. same release.

Batch process has the problem that there are many links to create (especially in manual mode). Not sure about that?

@bembelimen Thank you for this great PR, actually this is on my wishlist since a decade :-)

My observations:

the automatic and manual creation in the menu does nothing, I do not understand the redirect on save on site for menus as there is no menu editor on the frontend, or did I miss a new feature?

the automatic creation for articles works until there is a menu item (I think thats correct) but it created new redirects for every change. It maybe should update the outdated ones before creating a new one so there is not a redirection chain.

instead of test-1 -> to test-2 and test-2 to test-3 and test-3 to test-4 it should be after all changes: test-1 -> to test-4 and test-2 to test-4 and test-3 to test-4

The whole thing does not check if the theoretical article URL/alias has changed but really if the frontend URL changed. So when having a menu item assigned to an article, the menu item has priority in terms of URL and changing article alias has no effect.

So it really does only change if the physical URL changes.

Resolving the chain is a hard thing, because the URL can be stored in different ways in the redirect component. I see your point there, but if you have test 1 => test 2 and now add "test 3" you would need to have test 1 + test 2 still redirect to test 3. So you don't save entries you just save chains. Beside that is calculating back not that easy and I didn't want to add more magic to this PR.

Thanks for testing :-)

Installing Multilingual Sample Data and at step 3/8, got the following error:

There is an error in a sample data plugin. Response is invalid.

Installing Multilingual Sample Data and at step 3/8, got the following error:

There is an error in a sample data plugin. Response is invalid.

Resolving the chain is a hard thing, because the URL can be stored in different ways in the redirect component. I see your point there, but if you have test 1 => test 2 and now add "test 3" you would need to have test 1 + test 2 still redirect to test 3. So you don't save entries you just save chains. Beside that is calculating back not that easy and I didn't want to add more magic to this PR.

We’re not talking about a bug fix here, but a new feature. Wouldn’t this be exactly the right time to consider improvements to the redirect component, given that we’ve just realised it can’t meet the new requirements, rather than just working around the issue?

Resolving the chain is a hard thing, because the URL can be stored in different ways in the redirect component. I see your point there, but if you have test 1 => test 2 and now add "test 3" you would need to have test 1 + test 2 still redirect to test 3. So you don't save entries you just save chains. Beside that is calculating back not that easy and I didn't want to add more magic to this PR.

I'm a bit confused. We’re not talking about a bug fix here, but a new feature. Wouldn’t this be exactly the right time to consider improvements to the redirect component, given that we’ve just realised it can’t meet the new requirements, rather than just working around the issue?

I completely agree with you that it’s probably not possible to cut down on entries, as we can’t know whether they’ll be needed, and modifying them probably isn’t a good solution (at most, we could consider setting a time limit).
But preventing endless chains doesn’t sound like an unreasonable request to me.

Batch process has the problem that there are many links to create (especially in manual mode). Not sure about that?

Good point. I must admit, I hadn't thought of that. However, I think it’s perfectly possible in Automatic mode, and I think it would make perfectly sense there.