Drupal 9 Deprecated Code Report for Scheduler

Hi Adrianm6254,
You have pasted a huge list of text in the issue summary without any explanation. Could you reference #3035104: [meta] Remove deprecated code flagged by @trigger_error messages for Drupal 9 compatibility and give details of how you created this report.
Thanks.

Tagging for DrupalCon Seattle Friday contribution sprint.

See https://github.com/mglaman/drupal-check/wiki/Drupal-9-Readiness

I'm interested to know why, when we run the tests on #3035104: [meta] Remove deprecated code flagged by @trigger_error messages for Drupal 9 compatibility which have deprecations not suppressed via the patch:

+++ b/drupalci.yml
@@ -25,3 +25,4 @@ build:
     testing:
       run_tests.standard:
         types: 'PHPUnit-Functional'
+        suppress-deprecations: false

we do not see any of the errors mentioned in the text report in the issue summary.

There are a number of deprecated methods and classes in core that do not yet trigger an error when used. Prior to 8.4 we didn't have the coherent deprecation policy that we do now. drupal-check performs a static analysis and detects deprecated code usage through the @deprecated tags and provides a more thorough report.

We are working hard in core to add @trigger_errors to the remaining deprecated code paths, but in the meantime, this tool helps bridge the reporting gap.

Hi mikelutz, thanks for the explanation. Yes I thought it might be something like that, but good to have it explained.

I've been active on #3024461: Adopt consistent deprecation format for core and contrib deprecation messages and am currently working on coder sniffs for #2908391: Add a rule for expected format of @deprecated and @trigger_error() text. So when more core code is properly deprecated at least now we have an agreed standard for how to do it.

How should we proceed with this? Should a patch be created for each file that is fix, or should there be one large patch for all the deprecations? I have created a number of patches but I'm not sure what is the maintainer's preference. Please let me know how I can help.

Hi bajah1701,
Thanks for asking the question. I suggest that we create a separate issue for each type of fix/replacement, and each patch only needs to address one problem but will cover all the files that need that fix.

Jonathan
(scheduler maintainer)

Thanks for the guide, I will proceed as described.

#3049638: Replace call to deprecated function format_date

Thanks for adding the child issue.

Did you know that you can refer to issues using the syntax [#issuenumber] and this will be rendered with the full title, and coloured according to status, making it easier to see which issue is being linked. So [ #3049638] becomes #3049638: Replace call to deprecated function format_date

[edit: I see you have edited your comment above to use this syntax. It is useful]

Thanks tatarbj for tagging.

For anyone wanting to participate, I suggest the process we follow is:

1. Select the specific deprecation that you want to work on
2. Create a separate issue and set this issue 3042677 as the parent
3. When that issue is fixed and committed, please re-run the report and update the issue summary here
4. Add a comment with the other issue showing that it is fixed, to let others following here know of the progress being made

Created new issue #3055644: Replace calls to assertFieldById() as an example child issue. Anyone is welcome to work on it, just assign it to yourself first, to avoid someone else duplicating your work.

Updated issue summary with the process.

Added more info to issue summary and expanded the procedure for fixing.

Added D9Readiness tag so that this issue can be picked up on the report created by the Upgrade Status module, which is a wrapper for the drupal-check processing.

The following messages no longer appear in the updated report, not because we have fixed them all, but because of #3031580: Undeprecate \Drupal\FunctionalTests\AssertLegacyTrait and \Drupal\KernelTests\AssertLegacyTrait in Drupal 8 - recording them here, and have updated the issue summary with latest report.

Call to deprecated method assert() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertFieldById() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertFieldByName() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertLink() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertLinkByHref() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertNoFieldById() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertNoFieldByName() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertNotEqual() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertNoText() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertResponse() of class Drupal\Tests\BrowserTestBase.
Call to deprecated method assertText() of class Drupal\Tests\BrowserTestBase.

Fixed #3085798: Replace deprecated drupal::l() with Link::fromTextAndUrl()

Per a Slack discussion with Gábor Hojtsy regarding usage of D9 tags (Drupal 9, Drupal 9 compatibility, Drupal 9 readiness, etc.), "Drupal 9 compatibility" should be used for contributed projects that need updating and "Drupal 9" was the old tag for D8 issues before the D9 branch was ready. Doing tag cleanup here based on that discussion.

The Call to deprecated function drush_get_option() warning seems to have disappeared in current runs.

Here is a patch to fix the last remaining deprecation and make the module D9 ready

Thanks chr.fritsch, however, as per the instructions in the issue summary, the changes need to be in separate child issues to allow them to be tested independetly and then fixed and closed.

We already have #3079913: Add new 'core_version_requirement' key to .info.yml so I have now created #3105354: Replace deprecated entity_delete_multiple() to deal with the other change in your patch.

Now that #3105354: Replace deprecated entity_delete_multiple() is fixed, according drupal-check we have no D9 deprecation warnings!

Patch cannot be installed as it is showing this error

$ git apply -v 3042677.patch
Checking patch scheduler.info.yml...
Checking patch scheduler_rules_integration/scheduler_rules_integration.info.yml...
Checking patch tests/modules/scheduler_access_test/scheduler_access_test.info.yml...
Checking patch tests/modules/scheduler_api_test/scheduler_api_test.info.yml...
Checking patch tests/modules/scheduler_api_test/scheduler_api_test.install...
error: while searching for:
->condition('n.type', ['scheduler_api_test'], 'IN')
->execute();
if ($nids = $nids_query->fetchCol()) {
entity_delete_multiple('node', $nids);
\Drupal::messenger()->addMessage(t('@number %type node(s) have been deleted.', [
'@number' => count($nids),
'%type' => 'scheduler_api_test',

error: patch failed: tests/modules/scheduler_api_test/scheduler_api_test.install:21
error: tests/modules/scheduler_api_test/scheduler_api_test.install: patch does not apply

Hi Abhijith S
You have mis-understood. That patch in #24 should not have been added here, please read my comment in #25 and look at those two other issues.
Jonathan

From deprecation-checking-and-correction-tools

The same PHPStan deprecation testing tool can run on your project (similar to drupal-check and Upgrade Status' backend). This will produce a build artifact but will not (yet) fail the testing of your project.

So here is a patch for drupalci.yml to try it.

I have committed the patch in #30 (but attached it to the wrong issue). Anyway, we will now get PHPstan output on every d.o. test run, so we can check easily if we are using any newly deprecated code not flagged with @trigger_error

Hide the patch that is no longer needed.

Trial patch to remove the interactive progress output on PHPSTAN. This has odd graphics characters which cause a minor iritation when downloading the jenkins dispatcher logs to compare test runs.

16:08:30   0/70 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]   0%
[2K 60/70 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░]  85%
[2K 70/70 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

The syntax to use is a bit of guess-work. Let's see ...

Still clean.

It has to be published, hopefully soon. 🙏 I set the issue status to RTBC.

@vuil I think you must have posted to the wrong issue, as there is nothing to commit here.

The current codebase appears to be fully compatible, maybe time to mark this "fixed"?

Yes, both scheduler 2.x and 8.x-1.x branches have no deprecations for Drupal 9 (and have been clean for a long time)