Automated Drupal 10 compatibility fixes

Is this task under consideration by the maintainers? This module shows up on Upgrade Status under "Collaborate with maintainers" as a module that needs support.

I don't see any other ticket tracking active progress towards Drupal 10 support. Is it planned? Is this module still actively maintained?

LGTM! Module works on Drupal 10.1.2 via DrupalPod, and changes in the MR seem simple enough to me.

Also tested in 9.5.9 with Upgrade Status, and it shows up green!

I'm still a bit new to contributing on d.o so I don't know if I need to mark this as RTBC or someone else can do that? Either way, I think this is great!

Setting status per @nessthehero's review.

What is the status of this release?

With the MR changes, although Upgrade Status says it is compatible, there's some major problem that needs to be dealt with under Drupal 10 during module install:

Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "cache.backend.database", path: "http_kernel -> http_middleware.ajax_page_state -> http_middleware.negotiation -> http_middleware.reverse_proxy -> http_middleware.page_cache -> cache.page -> cache.backend.database -> Drupal\Component\Datetime\TimeInterface -> state -> cache.bootstrap". in Drupal\Component\DependencyInjection\Container->get() (line 149 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->get('cache.backend.database') (Line: 98)
Drupal\Core\Cache\ChainedFastBackendFactory->get('bootstrap') (Line: 110)
Drupal\Core\Cache\CacheFactory->get('bootstrap')
call_user_func_array(Array, Array) (Line: 257)
Drupal\Component\DependencyInjection\Container->createService(Array, 'cache.bootstrap') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('cache.bootstrap', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'state') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('state', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'Drupal\Component\Datetime\TimeInterface') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('Drupal\Component\Datetime\TimeInterface', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'cache.backend.database') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('cache.backend.database') (Line: 110)
Drupal\Core\Cache\CacheFactory->get('page')
call_user_func_array(Array, Array) (Line: 257)
Drupal\Component\DependencyInjection\Container->createService(Array, 'cache.page') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('cache.page', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'http_middleware.page_cache') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('http_middleware.page_cache', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'http_middleware.reverse_proxy') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('http_middleware.reverse_proxy', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'http_middleware.negotiation') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('http_middleware.negotiation', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'http_middleware.ajax_page_state') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('http_middleware.ajax_page_state', 1) (Line: 438)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 239)
Drupal\Component\DependencyInjection\Container->createService(Array, 'http_kernel') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('http_kernel') (Line: 1513)
Drupal\Core\DrupalKernel->getHttpKernel() (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

After this error the module is enabled but the scheduled transition state and date tables are not created resulting to a broken site. Since the tables were not created, you cannot even uninstall this module because of this error:

pc@ASUS-PC:~/lando-projects/drupal10.localhost/web/modules/custom/lightning_scheduler$ lando drush pmu lightning_scheduler

In ExceptionHandler.php line 56:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal10.block_content_r__48d0019ac1' doesn't exist: SELECT 1 AS "expression"
  FROM
  "block_content_r__48d0019ac1" "t"
  WHERE "scheduled_transition_date_value" IS NOT NULL
  LIMIT 1 OFFSET 0; Array
  (
  )


In StatementWrapperIterator.php line 113:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal10.block_content_r__48d0019ac1' doesn't exist

This problem does not appear on Drupal 9 clean install. It needs to be fixed here. Also, the mentioned tests if failing need to be fixed.

FYI there's a new error introduced in 10.3.0:

In Container.php line 149:

  Circular reference detected for service "cache.bootstrap", path: "module_handler -> cache.bootstrap -> cache.backend.apcu -> Drupal\Component\Datetime\TimeInterface -> state".

This is because lightning_scheduler.datetime.time decorates datetime.time and modifies the constructor arguments, which are not part of compatibility promises by core. It may be more reliable to instead inject that via setter injection.

+1

+1

I'll refactor a little bit those parts.

I created a new Drupal 10 compatible release. Thank you for everyone's help! The next stop is the Drupal 11 compatibility.

So how does this module relate to one by the same name that is a sub-module of the lightning workflow module?

We use the latter, but that doesn't seem to be getting updates to it's submodule that are being applied to this standalone module.

It seems like this should be used on it's own and removed from lightning workflow...

I'm a new maintainer here but the story I experienced with this is: once during Drupal 8 and early 9 times, there was a Lightning distribution by Acquia. All the modules here on Drupal.org that begin with lightning_* were made for that install profile to extend the basic Drupal code with enhancements. They stopped supporting the Lightning distribution but since a lot of sites used those modules they told us they will upgrade them so they will not block Drupal major version updates.

Now, originally Lightning Scheduler was written as a submodule in Lightning Workflow. That meant it had a dependency to the Lightning distribution. For people with standard Drupal sites without the Lightning distribution, it was added here as a separate module. So yeah, right now, this module is a basically a duplicate of the original Lightning Workflow's submodule but with removed dependencies to other Lightning modules so it could be used separately.

I think we should contact the original maintainers for Lightning Workflow and this module in a separate issue to discuss this further.

Hey folks, is it just me or does it seem silly that this module and the submodule of lightning wokrflow are maintained independently?

I didn't realise this standalone scheduler module existed until I ran into these issues when upgrading to D10.3. We had a patch for the workflow submodule and had to switch to a different temporary one to address this particular problem and we still have to uninstall it, then do composer updates and then re-enable it to work around the database errors. This module has the issues all resolved, but the workflow module seems to be getting updates more slowly.

Why not work together to just have this one as a dependency of the other?

I looked through the Lightning Workflow module and as I saw, people may not even need that anymore even for Lightning based sites.

This is what I found there (not counting that submodule):
- editorial workflow added on install which is I think in Drupal core already
- a Moderation History view is added on install which you can build it yourself anytime
- overrides for moderation dashboard panels which according to https://www.drupal.org/project/moderation_dashboard only applies to 8.x-1.x branch (which used the Panels module because Layout Builder did not exist back then) and not for newer 2.x or 3.x versions,
- alters Panel routes with adding extra parameters to its Route object
- disables https://www.drupal.org/project/autosave saving on Layout Builder forms
- a quickedit (which is not in Drupal core anymore) field preprocessing for fixing this issue without patching https://www.drupal.org/project/quickedit/issues/2815221
- adds data-block-plugin-id HTML attribute to all blocks - again can be done in your theme
- extends the node_bulk_form field plugin to disallow node_publish_action
- hides moderation pseudo-fields if https://www.drupal.org/project/moderation_sidebar is enabled.

Yes. You're right, it should be definitely sorted out where this module should continue live on and what to do with folks who built Lightning-based sites and want to have the new features and enhancements that will be applied here.

Alright, this not really affects the Drupal 10 compatibility, so hopefully we can continue these plans in that specific issue: https://www.drupal.org/project/lightning_workflow/issues/3458640

Thanks for the release!

From the bot's description:

> If this issue is left open (status of Active, Needs review, Needs work or Reviewed and tested by the community) and the "ProjectUpdateBotD10" tag is left on this issue, new patches will be posted periodically if new deprecation fixes are needed.

I think D10 is not likely to get more deprecation fixes at this point. :shrug:

But maybe something to watch for ... for like D11. Maintainers might end up merging in MRs multiple times, and keeping the bot update issue open.

The issue is already Fixed and soon will be Closed (fixed), so the bot won't touch it.

That's not the case with the D11 compatibility which is already being worked on #3458394: Drupal 11 compatibility

I found that if I Remove this patch from Composer.json

"drupal/calendar": {
"#3396700: Creation of dynamic properties is deprecated": "https://www.drupal.org/files/issues/2023-10-26/calendar-dynamic-properti..."
}

The error goes away.