Redirect expire submodule

Any reason this shouldn't live in Redirect module itself? I don't usually think it's proper for a module that provides an API to provide integrations for other contrib modules, just core modules.

@Dave Reid There are two reason I could think,
1. Its handling Voting API which is not part of the core
2. This module is not providing hook to handle it in the redirect module like how we are doing it for node/menu etc.. , the only way is we can call - expire_execute_expiration from redirect module by checking expire module exists. But It could better if this module provide a hooks to handle it.

As the maintainer of redirect, I feel pretty strongly about a redirect_expire sub-module in Redirect. This is also missing support for what happens if you update a node, you'll also need to expire all the redirects that point to that node (code I have currently written for redirect_expire). Plus this will need to add UIs for configuring redirect expire settings/toggles.

@Dave Reid Sounds good, Thanks for that.

Is there code that can be tested for this?

This is a critical feature for us, which we have been solving with custom code that just stopped working... I'll see what I can come up with for this submodule.

Here's my attempt at that submodule.

Why do you also need to expire all redirects to an entity [when the entity changes]? The HTTP response for the redirects themselves doesn’t change only the content of the page that is shown on the path that redirects points to changes.

Ok, I see: If redirecting to an entity with an alias the alias might change when changing the entity. So we’d end up with /redirect → /old-alias → /new-alias for as long as the response for /redirect is cached. Once the cache expires we’d have /redirect → /new-alias. Is it worth adding the additional complexity to avoid this? Well, maybe.

@torotil: Yes I believe that was the thinking. I'm not sure if we can assume there will be a redirect from /old-alias -> /new-alias. Some sites may be configured to do so automatically (I think the Pathauto module offers this) but some sites may not. Rather I think the cached response for /redirect might lead to a 404, in the case above.

@brockfanning kicked off the redirect_expire sub-module 2 years ago and the last comment was 10 months ago. Should the status of this issue still be 'Needs review'?

Closing this as Outdated as Drupal 7 is EOL.

This feature was requested by one of our clients, so I’ve reopened the issue for the latest version and added the submodule. Please review.

#17's implementation relies on cron job to deactivate the redirection.

- Cron job is not always reliable (on every site) for numerous reasons, I'd like to see this submodule alter the main redirect when performing the action, to take the date as a new parameter. This will eliminate the confusion for admin when cron job is not update to date.

- Not every site wants to delete expired redirects. Some site may want the redirect to be reusable by manually updating the date. Can we have a config in the setting to allow cron job delete expired redirects by default, but allow admin to uncheck the box to not delete anything?

Updated the MR.

1. Replaced Cron with Real-Time Handling

- Removed: hook_cron() implementation that deleted expired redirects during cron runs
- Added: hook_redirect_response_alter() that intercepts redirects when they're executed
- Benefit: Expired redirects are handled immediately when accessed, not waiting for the next cron run

2. Created Event Subscriber Architecture

- New File: src/EventSubscriber/RedirectExpirationSubscriber.php
- Purpose: Handles expiration logic when a redirect is about to execute
- Functionality:
- Checks if a redirect has an expiration date
- Compares expiration date with current time
- Optionally deletes the redirect based on configuration
- Redirects to the site's configured 404 page
- Logs all actions for audit purposes

3. Added Configuration Management

- New File: src/Form/RedirectExpirationSettingsForm.php
- New File: redirect_expiration.routing.yml
- New File: redirect_expiration.links.menu.yml
- New File: redirect_expiration.services.yml
- Single Configuration Option: "Delete expired redirects on access"
- Enabled (default): Expired redirects are deleted from the database
- Disabled: Expired redirects return 404 but remain in database (for auditing)

4. Integrated with Site's 404 Page

- When an expired redirect is accessed, users are redirected to the site's configured 404 page
- Reads from Drupal's system.site.page.404 configuration
- Falls back to a simple 404 response if no custom page is configured
- No manual configuration needed—uses whatever admin has set up in Site Settings

5. Enhanced Logging

- Logs when expired redirects are deleted
- Logs when expired redirects are accessed (if not deleting)
- Logs errors if deletion fails
- All logs go to the 'redirect_expiration' logger for easy tracking

Posted a review to the MR. I think it needs a bit of work. Also this feature needs test coverage.

After talking with @berdir the redirect maintainer - decided to create a new module to provide this functionality as it is quite edge-casy. The module is available - here https://www.drupal.org/project/redirect_expire

@safallia joseph I've added you as a project maintainer as you wrote so much of the code and did most of the work on this issue. Ping me on slack if you don't want to be.

I'll close this issue in a week.