Drupal 10 compatibility fixes

I'm getting the following error when I enable the module:

PHP Fatal error: Trait 'Drupal\\Core\\Routing\\UrlGeneratorTrait' not found in /Users/foo/Sites/devdesktop/9.0/httpdocs/modules/contrib/scheduled_updates/src/Permissions.php on line 20, referer: https://drupal90.dd:8443/admin/modules

It looks to me as if both UrlGeneratorTrait and StringTranslationTrait are being pulled into Permissions.php without actually being used. Removing those lines seems to get me past that error, but then I start getting some errors regarding entity.manager, and trying to fix those gets me into a mess.

@wrd you are correct it appears that the `UrlGeneratorTrait` isn't in use in the `Permissions.php` file, however the `StringTranslationTrait` I believe is being used by the `t()` method. Attached is an updated patch modified similar to patch #4 with the unused trait removed. Please test and let me know if you're still experiencing errors on D9.

This got me past the UrlGeneratorTrait error, but produced a new error:

Uncaught PHP Exception Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: "You have requested a non-existent service "entity.manager"."

This patch includes the changes from #9, and changes references to entity.manager to entity_type.manager, and EntityManagerInterface to EntityTypeManagerInterface.

I can now enable the module without errors, but I haven't actually tested it beyond that yet.

And this just fixes a typo I found in the Config page link's descriptive text.

@wrd Good call with the additional entity manager references needing to be updated!

Attached is a patch adding to patches #10 and #11 updating the $entityManager variable name to $entityTypeManager in src/Plugin/Derivative/AddUpdateFieldLocalAction.php, and using snake case for the entity_type_manager parameter in the src/ScheduledUpdateTypeListBuilder.php constructor. For code consistency sake across module files.

I created issue (https://www.drupal.org/project/scheduled_updates/issues/3175938) to add the missing `core_version_requirement` line that is required for D9 support, but it was closed and noted that it should be addressed in this issue.

So, given that, this patch needs a re-roll to add the `core_version_requirement` line to the module's info.yml file:
https://www.drupal.org/node/3070687

...to make it fully D9 ready (in addition to the already addressed deprecation issues fixed in the current patch).

Without both the deprecations fixed and the `core_version_requirement` line, the module cannot be 100% D9 ready.

Patch addresses additional deprecations revealed with upgrade_status module scan. See attached.

Additional class namespace path error.

Mistakenly uploaded incorrect module version for patch #17 (it had contained two different patches in one). Corrected here.

Hmm looking at the #18 patch, I see it is now requiring Drupal console. That seems worriesome to me because there is currently no D9 support for Drupal console. There is an issue for it
https://www.drupal.org/project/drupal/issues/3146509
https://github.com/hechoendrupal/drupal-console/issues/4250

It's unclear if Drupal console is fully D9 supported yet or not. But just raising that in case.

@joshua.boltz drupal/console has been added as a requirement as the module extends the `ContainerAwareCommand` class from the plugin and therefor modules using scheduled_updates would throw a warning that the class isn't found if the plugin isn't installed.

As of v1.9.5 drupal/console is compatible with D9. See https://github.com/hechoendrupal/drupal-console/releases/tag/1.9.5.

Great thanks! I did not see that update, but glad it now has support.

Re #20 you do not need to add console as a requirement of this module just because there's a Command in there. Plenty of other modules have these commands but do not require the drupal/console package e.g Devel. Here's an updated patch with that change removed.

I tested patch #22 in Drupal 9.1.4 and as a result I created an updated patch:

• Added config_export key to the annotation of Scheduled Update Type config entity. Otherwise you will get exceptions when trying to add new Scheduled Update Types.
• Updated vendor name in composer.json to drupal.
• Fixed two notices/warnings I got in PHP 7.4 on the way.

Re-roll against latest dev on 1.x-dev (package naming on composer.json already fixed by maintainer)

My bad wrong patch file.

I got the error Trait 'Drupal\Core\Routing\LinkGeneratorTrait' not found in modules/contrib/scheduled_updates.
Is there any fix for this ?

There was still some deprecated code, so I updated the patch.

Re-rolled #28 so it applies correctly against alpha7

Fixed the info.yml change on composer installed releases.

Re-rolled again to work with the latest 8.x-1.x dev commit (as of 04 March, 2021).

Hi and thanks for all the work done here!

This module was blocking us from upgrading to Drupal 9. So I forked the module and tested the patches available here extensivly with Drupal 9.

I created a merge request for the maintainer. I added some small additions I found but basically it's just a reroll of all contributions in this issue.

Hopefully we soon have a Drupal 9 compatible version ready!

Hi there, I just applied the patch and it solved the errors noted here for me. At least I am able to continue my D8 to D9 upgrade, I've not tested the functionality though. Just wanted to share my experience and offer my appreciation!

In the pull request #33 the test module info file should also have its constraints updated at /tests/modules/scheduled_updates_tests/scheduled_updates_tests.info.yml. I wouldn't consider that a blocker though.

For people trying the D9 upgrade you can add the following to the top of "repositories" in your composer.json:

    {
      "type": "vcs",
      "url": "https://git.drupalcode.org/issue/scheduled_updates-3172330.git"
    }

and then use the version constraint "drupal/scheduled_updates": "dev-3172330-module-is-not"

Regarding @damondt's instructions for using the temp repository to bring in the d9 compatible version of scheduled_updates (which was a big help), I had to put the following in my composer.json to get it to work (particularly exclude drupal/scheduled_updates from the main drupal 8 repo):

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": ["drupal/scheduled_updates"]
        },
        {
          "type": "vcs",
          "url": "https://git.drupalcode.org/issue/scheduled_updates-3172330.git",
          "only": ["drupal/scheduled_updates"]
        }

    ],

Setting to needs work so tests will run.

Pushed two missing fixes for the tests, may need more work still.

Works for me. Thanks a lot!

Would be great to get a release now that D8 is EOL. How can I test this to help out?

Added some changes namely:

• composer.json: No need to duplicate the information already in the module's info.yml file.
• scheduled_updates.info.yml: not sure if the module is now incompatible with Drupal < 8.7.7, so let's restore that to not break someone's site needlessly.
• src/ClassUtilsTrait.php: Restore removed else condition
• src/Plugin/Derivative/AddUpdateFieldLocalAction.php: Restore removed routeProvider class attribute
• tests/modules/scheduled_updates_tests/scheduled_updates_tests.info.yml: no need to specify core requirement if package is Testing. This will allow module to be tested for Drupal 10.
• etc: misc coding style fixes

One final word about my removal of the test dependency on roave/security-advisories.. This would make sense if the module maintainer wanted to keep informed about possible security issues. In practical terms, since the module only depends on Drupal core and modules, this makes absolutely no sense to use. Also, the maintainer seems to be AWOL.

And just in case someone wants to patch this, this is the current progress in the MR.

Patches will not work because composer looks for compatibility before applying patches. These changes need to be pushed to the main repo before D8 EOL (upgraded to Major Priority as such).

It looks like the "test" areas of this module is what failed the checks. JCNVentura, are these failures what your latest push and patches fix? Are those patches part of the MR?

@jcnventura can you apply that patch to MR-2 or create your own MR so composer can be over-ridden with the instructions given in #37 please.

After attempting to patch in myself and rereading @jcnventura's comment, that patch provided in #46 is all the changes currently applied to the issue fork and issue branch.

As an alternative to #37 until this gets merged into the main branch, you can also set up your composer.json like such to point to the issue branch as the default place to pull the module from to get all the code with composer without having to deal with patch issues and D8 -> D9 versions.

{
    "repositories": {
        "drupal/scheduled_updates": {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/scheduled_updates-3172330.git"
        }
    },
    "require": {
        "drupal/scheduled_updates": "dev-3172330-module-is-not",
    }
}

Patch #46 has been working well for us for a while now.

Would be awesome to get this merged. More then happy to help with testing

Attached a static patch for consistent builds. The attached patch is MR 2 at the latest commit a37b9aff.

Applied a37b9aff however, having issue

PHP Fatal error:  Declaration of Drupal\scheduled_updates\Routing\RouteSubscriber::getSubscribedEvents() must be compatible with Drupal\Core\Routing\RouteSubscriberBase::getSubscribedEvents(): array in /app/web/modules/contrib/scheduled_updates/src/Routing/RouteSubscriber.php on line 86

in D10

@captain_haddock - That error is fixed in the latest MR and patch attached to this post.

static patch of MR2 attached with drush support for 11 and 12.

OT really but just a quick note for people upgrading to D10 that https://www.drupal.org/files/issues/2021-12-10/scheduled_updates-htmlspe... applies cleanly on top of the latest patch here and https://www.drupal.org/files/issues/2023-09-05/scheduled_updates-2872239... after that for the missing column error.

So, [latest patch here] then 2872239 then 3253884, on top of 1.x-dev

This is ready to be committed. Please create a new major dev release. Since there are some test failures that do not seem to be caused by the D10 update of the module we would need a new issue to tackle them. Also I closed as duplicate #3363800: Drupal 10 compatibility so please give credits to the people that worked on the issue over there.

Opened a new major branch 2.x where I will push this patch.

Committed to 2.x. Thank you all!