Problem/Motivation

lightning_scheduler has severe performance problems unless patched (it reprocesses all historical transitions since the beginning of unix time on every cron run unless patched progressively gets slower over time) and even if patched cannot properly handle planning/scheduling of two translations of the same entity at the same time. I've tried to patch lightning_scheduler but it's a monstrous effort and not worthwhile since there's already an excellent alternative available I've abandonned lightning_scheduler in favour of another project/module mentioned here.

scheduled_transitions is a far better solution for scheduling transitions and does handle this (without any patch) case where we may want to change the same entity multiple translations at one time.

I have tested scheduled_transitions to work as follows:

  • make sure that the default language code for new content is the same as the site language, then translations are always the 'other' language.
  • for two translations/languages of one entity when scheduling choose a specific revision instead of latest revision and uncheck the checkbox option for pending revision that comes up in the user interface when publishing

screenshot of scheduled_transitions in action:
Click for larger version

Steps to reproduce

Proposed resolution

Add scheduled_transitions to wxt, replacing lightning_scheduler
configure permissions for scheduled_transitions
update configuration yml for default install.
test make sure changes work.

Remaining tasks

composer require 'drupal/scheduled_transitions:^2.2'
plus the proposed solution instructions;
- make it so.

User interface changes

see screenshot above, a tab added to the navigation of an entity rather than a field widget

API changes

see explanations

Data model changes

schema changes, custom table(s) for lightning_scheduler will no longer be needed, other solution comes in

Comments

joseph.olstad created an issue. See original summary.

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
smulvih2’s picture

We are using drupal/scheduler_field on a few projects. Might be worth comparing. We have a few outstanding patches on this project to make it work correctly.

joseph.olstad’s picture

oh wow so there's yet another option? BTW: scheduled_transitions requires "no patches" to work correctly as I discribed in the issue summary of this issue.

in any case, lightning_scheduler is severely flawed without patches and hasn't gotten much attention lately other than myself knocking myself out until I eventually gave up on lightning_scheduler because of time and resource constraints.

joseph.olstad’s picture

scheduler_field looks interesting, however requires patches, only has 32 installs, compared to https://www.drupal.org/project/scheduled_transitions which has over 1100 installs and requires zero patching.

joseph.olstad’s picture

I'm open to other options but found one that works well.

smulvih2’s picture

Yep makes sense, just adding my two cents since I have looked at this in the recent past. Will have to look at drupal/scheduled_transitions in more detail at some point. If you are able to create a patch to test this that would be great!!!

joseph.olstad’s picture

Status: Needs review » Needs work

needs patch for vanilla wxt

smulvih2’s picture

@joseph.olstad now that lightning_scheduler is removed from the distro, it would be nice to have a replacement for this functionality. Scheduling publication is a pretty common requirement, so would be nice to have this OOTB.

I'm in the process of evaluating alternatives, I'll try the scheduled_transitions module and let you know my thoughts. Thanks for the info!

joseph.olstad’s picture

@smulvih2

recommend scheduled_transitions with the following two patches:

    "drupal/scheduled_transitions": {
      "3277761 - Multiple languages at once, default this option to 'no'.": "https://www.drupal.org/files/issues/2022-04-28/scheduled_transitions-3277761-02.patch",
      "3299836 - Prevent entity delete processing for invalid host entities": "https://www.drupal.org/files/issues/2022-07-26/scheduled_transitions_invalid_entity_processed_by_hook_delete-3299836-11.patch"
    },

otherwise you might have trouble evaluating

joseph.olstad’s picture

composer require 'drupal/scheduled_transitions:2.2.1'

(to lock to 2.2.1)

or

composer require 'drupal/scheduled_transitions:^2.2'

smulvih2’s picture

@joseph I have this running on one of my projects and so far it works great! I also like that it doesn't add scheduling metadata on the entities like other scheduler modules. Going to do some more thorough testing but looks promising so far.

joseph.olstad’s picture

@smulvih2 , yes that module was a god-send, I had an absolute nightmare trying to fix lightning_scheduler and was very relieved to find an existing solution.

joseph.olstad’s picture

with that said, the simple patch I wrote #3277761: Default multiple languages at once to no could be improved by testing to see if the entity is translation enabled/available , if it is, the checkbox should be unchecked AND disabled as it should never be checked in that situation.

smulvih2’s picture

Status: Needs work » Active
StatusFileSize
new129.27 KB

I tested the scheduled_transitions module on one of my sites and it works great!

I also tested it in combination with the moderation_state_sync module (also testing this for client site) and it works well in combination. This allows us to keep the English and French translations in sync so changing the moderation state of one will automatically change the state of the other.

My only concern at this point is that scheduled_transitions provides too many options, see image below.

Scheduled transitions UI

By giving so much freedom it means there are a lot of use-cases to test, and maybe easier for users to make mistakes and ruin content. The nice part about lightning_scheduler or scheduler_field is the simple UI. For the most part, users probably just want to schedule publication. I have not come across a requirement before to schedule a new draft, or from draft to in review, etc... I think for scheduled_transitions to be a viable option we would need to pair back the options or make them configurable. It's confusing enough for developers to make sense of revisioning and moderation, let alone a content editor. It would probably simplify things significantly if we could configure this to only allow users to schedule the latest revision, but open to hear feedback from others.

joseph.olstad’s picture

@smulvih2 , yes, I agree that it could be simplified with less options but it works.
This is pretty advanced functionality but the main use case is pretty simple which is to schedule the latest revision at time of transition.

mostly they'll use this for a friday draft for both languages, schedule it for monday morning 9AM publishing kind of use case.

Those using it are super super happy about this.

smulvih2’s picture

I agree, it's a really well done module and it works, super simple to setup. I also like that it doesn't add any metadata to nodes and that it uses a queue to process transitions. I think with a bit of work (patch to module) the UI could be simplified and make it a lot cleaner from a UX standpoint. Maybe a config option to hide the list of revisions and just automatically select the latest revision for projects where you just want basic functionality/options. I'm looking to use this in two projects now, so will look at creating the patch mentioned above. Thanks for your work on this @joseph!!!

joseph.olstad’s picture

@smulvih2
just discovered that those options have permissions

so you can explicitly allow for say:

"Editorial workflow: Schedule Publish transition.
Move content from Awaiting translation, Awaiting content validation, Published states to Published state."

per role settings, each transition has a permission.

So those with restricted perms get a vastly simplified UI.

with that said, the default creator/reviewer role should probably have at minimum this permission:

"Editorial workflow: Schedule Publish transition.
Move content from Awaiting translation, Awaiting content validation, Published states to Published state."

Highly recommend we move forward and put it in with the two previously mentioned patches. (or improved ones)

smulvih2’s picture

Added a patch to the scheduled_transitions module to allow a simplified UI. Now end-users creating the transitions don't have to understand anything about revisions, they just know that they are changing the current state to X. This patch hides the revision table but keeps latest revision selected. It also hides the "Recreate pending revision" option and keeps it's value at the default (as per @joseph's patch in related ticket).

Current UI:
Scheduled transitions current UI

Simplified UI:
Simplified UI

joseph.olstad’s picture

Nice @smulvih2 , I really like the new UI thanks !!! It's optional too, perfect!

Also, can you confirm if you're using my patch with it or your patch alone?

#3277761-2: Default multiple languages at once to no

smulvih2’s picture

@joseph yes I'm using your patch in #3277761, seems to be working as expected. Will put this setup through QA and get back with a patch to implement in WxT. Thanks!

joseph.olstad’s picture

So basically this:

composer require 'drupal/scheduled_transitions:^2.2'

with these patches:

    "drupal/scheduled_transitions": {
      "3277761 - Multiple languages at once, default this option to 'no'.": "https://www.drupal.org/files/issues/2022-04-28/scheduled_transitions-3277761-02.patch",
      "3299836 - Prevent entity delete processing for invalid host entities": "https://www.drupal.org/files/issues/2022-07-26/scheduled_transitions_invalid_entity_processed_by_hook_delete-3299836-11.patch",
      "3309520 - Simplify the ui": "https://www.drupal.org/files/issues/2022-09-13/scheduled-transitions-simplify-ui-3309520-2.patch"
    },
sylus’s picture

Title: drop lightning_scheduler in favour of scheduled_transitions » Evaluate the scheduled_transitions workflow
sylus’s picture

Just changing the title to reflect that lightning_scheduler has been removed a few releases ago.

joseph.olstad’s picture

Version: 4.2.x-dev » 4.4.x-dev
joseph.olstad’s picture

As an optional module, see patch

smulvih2’s picture

Status: Active » Needs review
Related issues: +#3299836: Error with hook_entity_delete when using incorrect DER version
StatusFileSize
new2.25 KB

@joseph I have the following feedback on your patch:

  • The 3299836 patch can probably be removed. The d.org ticket for this patch was closed as won't fix. If needed, this can be added as project specific.
  • Instead of installing the scheduled_transitions module in wxt_core.install, install via wxt_core.info.yml
  • Before installing in hook_update(), check if the module is currently installed. This will be needed for some of my projects since I have already installed the module.

Please see patch attached for my suggested changes. This is what I am currently using on three projects, and looking to add to a fourth. I'm in favor of getting this into the next release as a replacement for lightning scheduler.

joseph.olstad’s picture

@smulvih2 , your patch changes look good however if it were 100% up to me I'd keep the patch 3299836 because otherwise scheduled transitions was causing hook deletes from a core module (the migrate module rollback) to crash because scheduled transitions has some sort of child behavior of the parent entity classes that offends the core migrate module rollbacks.

I haven't noticed other regressions caused by scheduled_transitions however the patch you removed does resolve a specific issue we observed.

smulvih2’s picture

Status: Needs review » Needs work
StatusFileSize
new3.96 KB

Forgot that once we enable the module we need to configure it to allow node bundles. New patch adds blog_post and webform content types by default, and if wxt_ext_page is enabled it will add page to the list as well.

@joseph, setting this back to needs review in order to review the patch in question.

joseph.olstad’s picture

looks good, although I haven't tested this patch yet.

keeping in mind, a migrate rollback will crash when it deletes nodes unless the mentioned patch is included in the build.

smulvih2’s picture

Status: Needs work » Closed (won't fix)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.