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.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

andybroomfield created an issue. See original summary.

andybroomfield’s picture

Title: [LocalGov Events remove expired] Add option » [LocalGov Events remove expired] Add option to not changed date of node when unpublishing

nickolaj made their first commit to this issue’s fork.

nickolaj’s picture

Status: Active » Needs review

Added 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.

tonypaulbarker’s picture

Thank 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?

andybroomfield’s picture

@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.

finn lewis made their first commit to this issue’s fork.