Problem/Motivation
When bulk archiving old events using the sub module, this has the effect of setting the changed date to the date it was unpublished. This is normally desirable Drupal behaviour, however when there are lots of events to delete (1800+) then the /admin/content page gets filled with unpublished events.
Steps to reproduce
Have lots of events that are expired, and set up LocalGov Events remove expired to unpublished events.
Run cron several times and see the /admin/content filled with unpublished events.
Proposed resolution
Add an option to not update the changed date when unpublishing events.
Comments
Comment #2
andybroomfieldComment #5
nickolajAdded a "Preserve the changed date when unpublishing events" checkbox to the expired events settings form. When enabled, uses `$entity->setSyncing(TRUE)` before save to prevent Drupal from updating the node's changed timestamp during unpublish/archive operations.
Comment #6
tonypaulbarkerThank you for working on this case @nickolaj
As the behaviour is normally desired and I think that seeing the updated date is probably useful even if there are large numbers of events. Do we think the nodes will only update in large volumes on the first run and after that it’s not a problem? If so, perhaps we could do something to help with the first run or bulk runs… a button?
I think the labelling around the checkbox could be clearer so that I understand the reason for suppressing the updated date.
What do you think @andybroomfield @finn lewis?
Comment #7
andybroomfield@tonypaulbarker This happens when you run for the first time and you have 500+ events that get unpublished, that fills up the /admin/content dashboard. I suspect we would only use it first run then once done we'd probably switch it back so we get a sense of things being updated. That said, it might be desirable behaviour for people to set and forget as events assumed they fall off and wouldn't want to see them on the /admin/content page.