I maintain several Drupal sites. Some are changing frequently: sometimes because the page title changes, sometimes because the pathauto-settings did change (also because of updating from D4 to D5), sometimes by changing from an old website to Drupal, and so on.
Reason: I cannot control when my path redirect can be cleaned from old stuff. And I don't know what old redirects are still in use (by a link from other sites and so on).
Feature request:
- is it possible to add a date, being the creation date and after that, the last accessed date: which resulted in a redirect.
- an administrator option to set a period after which an old alias without being accessed / used can be removed.
The result: automatically old, not used redirects will being cleaned after say 2 years.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | path_redirect-5.x-1.x_hygiene_7.patch | 6.95 KB | HorsePunchKid |
| #4 | path_redirect-5.x-1.x_hygiene_4.patch | 4.98 KB | HorsePunchKid |
Comments
Comment #1
HorsePunchKid commentedThis is an important idea, especially now that pathauto makes it very easy to end up with lots of redirects. I'm a little bit concerned about having to do an
UPDATEevery time a redirect is hit, and a little bit worried about how that will work with caching turned on. But I think for many people, keeping the redirects relevant and manageable will be worth that overhead.This is about the third or fourth feature request now that would require a settings page for this module; maybe for 1.2 we can get that started. Just for the record:
Tangentially related: There was a brief discussion here about how to identify and remove redirects that point to nowhere useful (e.g. to a nonexistent path).
Comment #2
HorsePunchKid commentedSara Adams wrote a good description of the same functionality here. An easy solution would be:
last_usedin the{path_redirect}table would be updated every time a redirect was used. If disabled, it would simply be leftNULL.How does that sound? It's not as sophisticated as actually tracking frequency of use, but it may be good enough. In particular, it handles the case where pathauto creates several redirects when somebody is fiddling with a node title, and basically none of those redirects will ever be used.
Comment #3
Sara Adams commented+1 on this.
Sorry by the way for posting a duplicate issue. I had searched open issues, but apparently didn't look closely enough.
-- Sara
Comment #4
HorsePunchKid commentedThis needs some work, but it's basically functional. I'd really like to have a "reset usage data" button on the settings page; it would basically reset all redirects to having been used "today". There's something wrong with the menu definition, I think, and it's not quite working.
Comment #5
promesI saw your attachment today and I did look at the code for the update of the last_update date.
I presume it is not working because you didn't include a clue what records to update, so try something like:
WHERE last_update<%d.
or
WHERE last_update<99999999999. (since in all system tables a date = int(11), I used 11 nine's).
I hope this is the trick you are looking for.
Thanks for your time. If you need someone to test the result, please send me an email.
Comment #6
HorsePunchKid commentedHere's an updated patch that seems to be working fairly well.
promes, I think we were talking about different issues, but they should both be fixed now. The challenge is to set this up so that it's not too easy to accidentally select options that cause redirects to get purged quickly or unexpectedly. So right now,
last_useddefaults to zero. Redirects that are older than the deletion threshold and have non-zerolast_usedget purged in the cron job. When you add or edit a redirect, itslast_usedgets set to the current date.The negative of this is that if you enable purging on an existing set of redirects and never touch anything else, they won't get purged unless you hit the "reset usage data" link. The positive is that you have a somewhat hidden ability to have redirects that won't get purged even if they're old.
We could undo that behavior entirely by restoring the line in the cron hook from the previous patch that set the
last_usedto the current date for null (or in this case, zero) values before running the purge logic. This would make it simpler and possibly less confusing, but also slightly more likely that you'd end up with redirects getting purged when you didn't expect it--though if you pay attention to the settings page, there shouldn't be any surprises.Thoughts? Now that I write all that out, I'm leaning toward the latter option...
Comment #7
HorsePunchKid commentedAnd your patch, sir.
Comment #8
promesI did some testing with the cleaning options based on the last devel version and patch #7. The time was to short to do a full cycle: I didn't wait till the first batch of redirects were purged by the cron-job (at least one week). Everything works as expected.
1. I think it is a good idea to start with a zero in last_used. So the functionality will not change for those, just making an upgrade without seeing the new options.
2. I don't think it is negative you have to use the "reset usage data" link to enable old redirects to be deleted in the future and wait till the full period ends. They are just entries in a table and you can manually delete these if you like.
3. I think you should add a test in function path_redirect_cron whether "Purge unused redirects" is enabled. Otherwise someone starting with enabling the cleaning and seeing his mistake will be "punished" after disabling the setting, thinking it also means: never delete any redirect.
I hope this version will be the official one in the near future. For me this will do the job.
Thanks for your time.
Comment #9
promesAny news ?
I am eager to start using this feature.
PROMES
Comment #10
jgoldfeder commentedsubscribe...this is a fantastic idea.
Comment #11
dave reidI just committed a simplified version of this feature to 6.x-1.x. I don't anticipate back-porting any more new features to 5.x-1.x, so if you're not using Drupal 6 yet, why not?! :)