Make Redirects fieldable

+1 for this feature but for Drupal 8/9. I have over 6100 redirects from migrating an old static site into Drupal, and being able to filter by a taxonomy field would be awesome.

I have a use case for this on a D8 project, going to try and take a first pass at what would need to happen to make them fieldable.

Here is a patch from the proposed solution.

I applied patch from comment #6 but had no luck. When editing a redirection, an error message appeared stating :

Notice : Undefined index: #value dans locale_form_redirect_edit_form_alter() (/app/web/modules/contrib/redirect/redirect.module ligne 261)

Exception: Object of type Drupal\Core\Language\Language cannot be printed. in Drupal\Core\Template\TwigExtension->escapeFilter() (line 454 of /app/web/core/lib/Drupal/Core/Template/TwigExtension.php)

Environnment = drupal 9.4.10 + PHP 7.4

After having applied the patch, probably due to the entity structure modification, the id of the redirect edit form becomes "redirect_edit_form". Before the patch the id was "redirect_redirect_edit_form".

So after the patched module activates locale_form_redirect_edit_form_alter() which is targetting "redirect_edit_form" and was not triggered before the patch... This function was already present in older core versions (I could see it in d7 version)

I see two points there :
1) May be locale_form_redirect_edit_form_alter() isn't useful anymore ?
2) Can the modification of redirect edit form id have an impact outside of the redirect module ?

In my case, in a fresh drupal 9.4.10 installation, removing the locale_form_redirect_edit_form_alter() function is solving the issue I had.
Also working on 9.5.4 with php 8.0

That must not be removed but fixed if it changed, maybe you configured the field to be hidden or so?

I have performed a fresh installation and added a text field through the UI on the redirection module. Nothing more.

I decided to remove the 'locale_form_redirect_edit_form_alter()' hook because it seems to not be used at all, at least in recent drupal core versions. But you're right Berdir it's possible that doing so could affect compatibility with older versions of Drupal 9.

It has nothing to do with the drupal core version and yes it is definitely used or you would not have received an error.

If you have a single-language site then you likely don't see it, but it's there and used.

I have received an error related to the code added in comment #5, which has not been commited yet if I am not wrong...

The code added disables the bundle support for redirect entity and had as a consequence to change the redirect entity edit form id and also trigger locale_form_redirect_edit_form_alter()... (which was not triggered before , if I understand well)
Before that, the form alter was never triggered because it was targeting an old form id (redirect_edit_form and not redirect_redirect_edit_form).
But may be I am missing something...

The language field related code seems to be implemented there, at least in Drupal 9.2+ :
https://git.drupalcode.org/project/redirect/-/blob/8.x-1.x/src/Entity/Re...
https://git.drupalcode.org/project/redirect/-/blob/8.x-1.x/src/Form/Redi...

And here is the core part that handles entity form id generation (checked in D9 and D10) :
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/lib/Drupal/...

This last portion of code makes understandable that when removing the bundle support the form id changes (and makes unused old form_alter available)

You're right, the logic of that hook was moved to \Drupal\redirect\Form\RedirectForm::form(), it can indeed be removed.

I expected that this also needs an update function, but it's currently not reporting anything on the status page, possibly because the key was bogus and never actually used.

So to sum up :
- it seems that locale_form_redirect_edit_form_alter() is deprecated code, which removal does not have any impact at all.
- as a consequence of disabling bundle support for the redirect entity and to avoid collision with updated/patched redirect edit form id, it seems also that we could remove this deprecated code

Then the remaining question that I see for a generic implementation is : can the modification of the redirect edit form id have an impact outside of the redirect module ? If a custom module (named my_custom_module) implemented my_custom_module_form_redirect_redirect_edit_form_alter() that custom hook would stop working, is that correct ?

Looks like locale_form_redirect_edit_form_alter() was already removed during some other ticket and patch from #8 not applied anymore. So here is updated patch.

Hi all, what's the current status on this? What would it take to get it over the finish line?

I'd love it if this were a real, stable feature. The site I currently manage has lots of redirects, because our marketing team likes to make shortened "Vanity URLs" for use in printed campaign materials. It would be helpful to have a comment field about why redirects were added, which campaigns they were for, etc.

Adding a few thoughts here. If I understand this issue correctly you want to be able to add bundle fields via the UI.

What you should ideally be doing is adding base fields to the entity programmatically. Adding new fields as "bundle fields" i.e. field and storage definitions in configuration files would harm performance since they are always created as separate tables in the database forcing extra joins in the database queries - and redirects (potentially multiple in redirect chains) may be loaded in every request.

Adding new base fields is really straightforward, including displaying them in forms. Contrib modules can do that for common use cases e.g. a redirect_comment module could provide a comment field for redirects and a redirect_category module could provide a field referencing a taxonomy term for classification.

That said, if a UI and the ability to add bundle fields were to be added, and since entity type definitions are cached, I do not think there will be too much of a performance hit for applications that do not use bundle fields - just a little bit. I would be more concerned about promoting the non-optimal way, and also adding more code to maintain to the main module. It might be best that such ability goes to a separate module or submodule that could alter the entity type and make it fieldable, and provide some notes that this should be used by site builders while developers should prefer base fields where possible.

Had a client with a need for this so created: Redirect Field UI