- Issue created by @kaszarobert
It was pointed out that the current solution to save into revisions is not ideal:
- When there's many content with many transitions, it produces a huge load to the database. The query to get the latest revisions of content and searching for possible transitions does not scale well. We tried to tackle this problem here
🐛
Performance - Prevent redundant processing back to January 1st 1970 on every cron run
Needs review
by limiting the date range comparing to the last cron run but that breaks the functionality a little bit to achieve less load on the server.
- Also, further problems arise when we take multiple languages with multiple revisions into account. That is an untested situation and needs to be done from scratch:
✨
Make scheduled moderation states work with multilingual
Needs work
- Another problem with the current codebase is since the query takes too long and taxing the database server, we cannot run this efficiently if we move it to a separate drush command, like suggested in
#3060664: State transitions drush command →
.
- There's no limitation on the amount of processable entities during cron run. If you create 100 transitions that should be processed at the current date, then the cron job will be running until it processes everything. Again, considering the not ideal queries, this could timeout (and block other cron jobs from running) and also produce a huge load on your site.
The ideal solution would be something like a simple list where the cron job could query quickly the next item to process without digging into latest revisions and the available translations there. I'd suggest moving these scheduled transitions away from the entity fields to a separate entity or database table.
But considering this solution, this is exactly how https://www.drupal.org/project/scheduled_transitions → was written. I'd think about that if it's worth rewriting this module, or just provide a migrate path to scheduled_transitions instead.
Active
1.0
Code