Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
When using Revision Scheduler to schedule content the URLs don't currently get purged.
Proposed resolution
Use hook to purge URLs.
Patch below.
Remaining tasks
Maybe add more support for other entity types?
User interface changes
None.
API changes
None.
Comments
Comment #1
Elijah LynnComment #2
Elijah LynnComment #3
Dave ReidThis should definitely be checking if $operation->entity_type == 'node' otherwise this will fail hard if someone schedules a non-node revision.
Comment #4
Elijah LynnThanks Dave,
Here is the addition.
Comment #5
Elijah LynnHere is an updated patch. 1) It adds a check to see if the Purge Status is okay 2) Removes a redundant noad load, the $entity was already there.
Comment #6
breathingrock CreditAttribution: breathingrock commentedThis expands on Elijah Lynn's patch, saving a diagnostic check for entities that aren't nodes, and fixes a bug that prevented running revision scheduler operations via `drush cron`.
Comment #7
nielsvm CreditAttribution: nielsvm commentedI'm very sorry guys, but I have to reject this entirely.
Not because it ain't a good idea or because it wouldn't work (or code for that sake), but simply because it shouldn't be Acquia Purge fixing this. The problem of detecting what to purge and what not to purge is incredibly hard in D=<7 and
expire.module
already does an incredible job of fixing this for the broad 95% of content changes.Therefore the only place where this code should go into is the
expire
module - or perhapsrevision_scheduler
should talk toexpire
's hooks. Expire's my full upstream and keeping all the dirty plumbing within that module alone keeps the benefits up for all purging modules (purge, varnish, acquia_purge, etc) and the complexity of cache expiration contained within one module.As soon as
expire
detects nodes to be purged (and when not to), that'll benefit everyone in one go.Thanks for the understanding,
Niels
Comment #8
Elijah LynnOkay, thanks for explaining things out!
Comment #9
Elijah LynnI realize this won't get accepted but we are still maintaining this patch internally until we have to time to work on your suggestions. In the meantime I need to post this patch here that fixes a watchdog error.
Comment #10
Spleshka@Elijah Lynn, as far as I see your patch is for Acquia Purge module. I think you will want to change project back to Acquia Purge :)
Comment #11
Elijah LynnYes, that does make sense but it won't get into Acquia Purge and we need to work on a patch to provide Revision Scheduler support in Cache Expiration module itself. Is it okay to keep this issue here for now until we have time to work on that patch?
Comment #12
Spleshkayes, we can leave it here. I am just affraid that it will be lost :)
Comment #13
Dave ReidRevised patch for expire.module.
Comment #14
SpleshkaI completely don't mind to commit this, but right at this moment I have no time to test your patch. Can anyone do this carefully and then post here results? Patch itself looks good, it just needs a manual test.
Comment #15
Dave ReidActually I'm wondering if this would actually be needed. I would think most of the revision operations would trigger their own hook_node_update() or entity hooks as appropriate. I think this would be duplicating those calls.
Comment #16
SpleshkaInteresting point. So let's see if this integration is really needed :)
Comment #17
Dave ReidThis is definitely not needed.
Comment #18
nielsvm CreditAttribution: nielsvm as a volunteer and at Acquia commentedWondering, does that mean it moved or will move into revision_moderation then Dave?
Comment #19
Dave ReidIt's just not needed at all. All the revision scheduler operations use node_save() which invokes the normal hook_node_update() expiration.