Contrib.social

Simplify architecture to solve issue around content moderation, translations and cron

Open on Drupal.org →
Created on 27 July 2022, over 2 years ago
Updated 25 January 2023, almost 2 years ago

Problem/Motivation

There are several issues reported regarding content moderation, translations and cron.
✨ Add support for "Maximum number allowed" revisions per content node translation Needs review
💬 Minimum number of revisions to keep and content moderation Active
#3262899: No awareness of translations D8/9 →
🐛 Revisions aren't deleted on cron run Needs work
✨ Add content moderation support, for preserving "published" state revisions Needs review
🐛 0 candidates when drafts are available Active
#3269165: Deleted 0 revisions for node with nid →
#3268323: Race condition on cron run →

Just found https://www.drupal.org/project/node_revision_limit → as well (mentioned in #3264977: Add similar project to the doc → ), which made me think a bit.

Proposed resolution

What if we could do the following, to greatly simplify the module architecture:

  1. Query nids of a specific type with more revisions than the configured minimum (per language).
  2. Query nids of a specific type with at least 1 revision older than the configured minimum.
  3. Add nids that appear in both queries to a queue for processing.

Within the queue worker we can have a more simple query that only needs to work for a single node, where we can do things like:

  • Skip revision IDs newer than the published revision (or not).
  • Skip the active revision ID.
  • Skip revision IDs newer than the configured minimum.
  • Figure out which revision IDs to keep respecting the configured minimum amount of revisions.

The biggest problem with this approach is the /admin/config/content/node_revision_delete overview. This currently tries to show the exact amount of revisions that might be considered for deletion, although I'm not sure how accurate this is at the moment.

We can probably not show specific amounts in that overview using this new approach. Personally, I would consider the candidate revisions count a "nice to have", if this helps to simplify the way the module works and makes it more robust and flexible (for example allow other modules to deny a revision to be deleted using a hook?).

Remaining tasks

Discuss if the simpler architecture is something to consider for this module, or maybe this should be done in a new / different module.
The changes should at least be a new major version since this will definitely break existing API.

User interface changes

We could keep most of the UI, but we can no longer show the amount of candidate revisions on /admin/config/content/node_revision_delete.

API changes

Not sure yet, but we could definitely reduce and simplify some of the API.

Data model changes

-

✨ Feature request
Status

Fixed

Version

1.0

Component

Code

Created by

🇳🇱Netherlands seanB Netherlands

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇳🇱Netherlands seanB Netherlands

    Just pushed the module rewrite to a new 2.0.x branch. https://git.drupalcode.org/project/node_revision_delete/-/tree/2.0.x

    Since it was basically a complete rewrite, I'm not sure if it makes sense to do this using small patches. For now, we squashed all our work into a single commit: https://git.drupalcode.org/project/node_revision_delete/-/commit/8c528e1...

    • The settings form has been changed to allow generic defaults for the plugin settings, with the option to override the defaults per node type.
    • An update hook has been created to migrate any existing settings to the new plugin settings.
    • We created 3 plugins to basically support the same functionality as the module already did:
      • Keep a minimum amount of revisions
      • Keep revisions for a minimum amount of time
      • Keep drafts for a minimum amount of time
    • We use a queue worker to call all plugins for a node and determine which revisions can be deleted. The revisions are split per language.
    • A drush command has been added to add all existing content to the queue and let the queue figure out which revisions can be deleted.
    • Content is also added to the queue when a new revision is added.
    • Tests are added for the plugins the module ships with.

    Attached is a complete diff as well. We removed a lot of code that no longer seemed to be necessary. If you see anything that you think needs to be added back, or seems to be missing, it might make sense to convert this issue to a new meta and create smaller issues from here.

  • Comment almost 2 years ago →
    🇨🇦Canada adriancid Montreal, Canada

    Hi @seanB, thanks for this, I just created the dev branch and the alpha release for the branch to allow users to test this new version, I will try to test and review too. I think we can close this issue and start creating new issues if we discover new things.

    Thanks for this,
    Adrian

  • Comment almost 2 years ago →
    🇨🇦Canada adriancid Montreal, Canada

    @seanB I think is a good idea if you can update the project page with the information about the new version, if you want you can create a new issue for this.

  • Comment almost 2 years ago →
    🇳🇱Netherlands seanB Netherlands

    Just updated the project page. Please feel free to make any changes you like.

  • Status changed to Fixed almost 2 years ago
  • Comment almost 2 years ago →
    🇨🇦Canada adriancid Montreal, Canada
  • Comment almost 2 years ago →
    System Message

    Automatically closed - issue fixed for 2 weeks with no activity.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024