Media_entity_file_replace does not work within the linkit field

Thanks for reporting this. This does seem to overlap somewhat with an issue that was fixed in the development branch and has not been released. Can you confirm that the fix in 🐛 Linkit for Link field: Files displayed in link widget form should show full path Fixed does not resolve this issue for you?

Here is a video of the issue.
If you add both modules.

• "drupal/media_entity_file_redirect": "^1.0@beta"
• "drupal/linkit": "dev-6.0.x",

On a vanilla Drupal 9.5 install. Once document is saved after clicking the edit feature it will go back to /media/ and try to save that instead.
I did it on a content type field but a similar issue is found inside of layout builder blocks.

I must add I was expecting the field to be able to save /document/1 as the the canonical url for that as that has a different behavior by skipping the media page and going straight to the pdf.

We came across this as well.

If the Media Entity File Redirect module (which I made) just modified the canonical path of media entities to be /download/[id], everything would just work. The reason the module doesn't do that is that the redirect route is optionally enabled per media type, and I don't think we can override the canonical link template per-bundle. It's the whole entity type. So instead, the module simply provides a route for the redirect path and provides LinkIt matcher and substitution plugins.

One possibility is to have LinkIt detect if Media Entity File Redirect is enabled, and if so, check if it's enabled on the entities type. This seems messy to me. I think it's best to avoid having one contrib module have feature detection of other contrib modules.

Another possibility is to fire an alter hook for the default value in the field widget? Media Entity File Redirect could then implement the hook and set the correct default value.

Without such a hook, the module would need to alter the field widget via media_entity_file_redirect_field_widget_single_element_linkit_form_alter, which may work. I'll investigate that.

Moving this issue to Media Entity File Redirect. I think that's the best place to solve this.