Provide alter hook for automatic redirect creation

Created on 31 July 2024, 5 months ago
Updated 12 August 2024, 4 months ago

Problem/Motivation

Sometimes it is not required to create automatic redirects when entity alias changes. But yet module provides only "all or nothing" option.
In my case for dynamically imported content type it causes `Redirect loop identified` exception, but I even don't need any redirect for that content type at all.

Proposed resolution

Provide alter hook.

API changes

New alter hook added, no changes to existing API.
odel changes

✨ Feature request
Status

Needs review

Version

1.9

Component

Code

Created by

πŸ‡ΊπŸ‡¦Ukraine mykola dolynskyi Poltava

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mykola dolynskyi
  • πŸ‡ΊπŸ‡¦Ukraine mykola dolynskyi Poltava

    adding patch

  • Pipeline finished with Success
    5 months ago
    Total: 280s
    #239449
  • Status changed to Fixed 5 months ago
  • πŸ‡ΊπŸ‡¦Ukraine mykola dolynskyi Poltava
  • Status changed to Needs review 5 months ago
  • πŸ‡ΊπŸ‡¦Ukraine mykola dolynskyi Poltava
  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    Unsure about adding more rather arcane extension points. What if we'd convert the logic into a service, then you can decorate the service and have it not call the parent?

    Alterantively, you could use a module implements alter hook and manually either call or don't cal redirect hooks from your own hook.

  • πŸ‡ΊπŸ‡¦Ukraine mykola dolynskyi Poltava

    @berdir, service is a good way, but you can`t "just provide hook with service", you will need to review all the code and move all logic into it exposing API, only after that refactor it to make small overridable function as a hook alternative. This is not the scope of task I described and much more work.

    Service decoration is still not a callback accumulation if 2 separate modules do provide content type not required for for aliasing, then I need module #3 just to override service and properly collect entity types from 2 modules.

    P.S. Imagine me doing that service as described above and then you come saying "Not sure we need such a big change" (which typical in drupal.org) and then it meaned I wasted 5h and still must create small-code patch, because unlike big refactor patch it can be long term living, and I have to support clients.

    So hook is the best on my opinion at this moment.
    If there is a wish to shift module logic to service - that is a different task and new version of the module.

Production build 0.71.5 2024