Automated Drupal 11 compatibility fixes for diff

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore these changes did not update the info.yml file for Drupal 11 compatibility.

Leaving this issue open, even after committing the current patch, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug info

This patch was created using these packages:

1. drupal/upgrade_status: 4.1.0
2. mglaman/phpstan-drupal: 1.2.7
3. palantirnet/drupal-rector: 0.20.1

The last submitted patch, 2: diff.8.x-1.1.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

This comment was forced and has ignored the check if a change was already posted. This is only done when we want to update the issue without waiting for changes to happen.

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.1.0
2. mglaman/phpstan-drupal: 1.2.10
3. palantirnet/drupal-rector: 0.20.1

The last submitted patch, 6: diff.1.x-dev.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

silvi.addweb → made their first commit to this issue’s fork.

I have check drupal 11 compability using upgrade status, I have seen the deprecated method loadRevision() error Which is solved in https://www.drupal.org/project/diff/issues/3407021 📌 Use type-hinting on deprecation warnings for loadRevision() Closed: duplicate But this not merge yet, So I have added only core_version_requirement fixes in #9 and created MR

silvi.addweb → closed merge request !56

Rebased with 8.x-1.x branch and pushed changes with D11 support.
Gitlab CI is passing now ~~ this issue is ready for review.

The following PHPUnit tests are failing on Drupal 11 and this needs to be fixed:

Tests are passing in the merge request.

I updated the .gitlab-ci.yml so that next major testing is working, which essentially means running concurrent tests through run-tests.sh (which is much faster too) and the deprecation workaround until #3400979: Is SYMFONY_DEPRECATIONS_HELPER: weak correct for contrib deprecation testing needs? → is merged and available.

That resulted in some test fails, which I fixed (old config schema for sequences and a removed views key). With that, phpunit (next major) is now green.

Previous minor is failing, somehow there's a difference in core whether it shows closed or hidden, didn't investigate. I prefer keeping previous minor testing on so I can ensure that there are no regressions with still-supported minor versions, but seems a bit tedious to handle that. Could be re-enabled after 10.3 is out. Removed that for now, see https://git.drupalcode.org/issue/diff-3429862/-/jobs/1626487 for the test fail.

As for next minor/major testing, my approach for that is to remove that from the default config before committing the D11 merge requests and then setting up a weekly schedule with that on. The idea is that I test as much backward as possible as merge requests might break that. But it's quite unlikely that merge requests break forward compatibility. Instead, that happens due to core changes, so the weekly test informs me if that starts to fail (although next major is set to allow failure, that could be overridden I guess). The plan is a bit work in progress. But that's up to the maintainer to decide how to merge this.

Would be great to get this in so I can proceed with 📌 Add support for Drupal 11 Needs review without having to add workarounds (as it as a require-dev on diff module).

I had also fixed an incorrect merge for phpcs/phpstan allow failure override.

But now that is actually failing on both current and next minor/major versions. I removed the loadRevision() false positives from the baseline, but next minor/major have deprecations too. It would probably be possible to add deprecation helper calls to remain compatible back at least to 10.1, with corresponding phpstan ignore comments if necessary, or it might be possible to override next major/minor phpstan jobs to allow failures again, but personally I think that's not really worth the effort.

As discussed in slack, I'd like to keep enforcing phpstan passing. As a maintainer, I'd rather the MR pipeline fail outright than having to check every time if any regressions have been introduced there. The problem is now of course that the next major runs are failing because, well, code is deprecated there that isn't in our current major. It makes no sense to me to fail phpstan on next major.

The current MR also introduces new failures on the current major with the baseline changes so back to NW.

> The current MR also introduces new failures on the current major with the baseline changes so back to NW.

The baseline changes are to fix failures that also happened on the current branch, not just next. Those changes apparently happen due to phpstan and related dependency updates.

Hi @acbramley,
I've updated MR!63 please review.

The baseline changes are to fix failures that also happened on the current branch, not just next

Yes but then it started failing phpstan. HEAD was updated and fixed to include this with the PHP 8.1 requirements.

The CI for previous major is failing. Can we get that fixed ? Looks like adding following variable would fix the issues:

variables:
  CORE_PREVIOUS_PHP_MIN: 8.1

> CORE_PREVIOUS_PHP_MIN: 8.1

That's a neat idea, but there are tons of test fails on previous major and some on previous minor too. Can't commit like this. Either we need to remove previous minor/major testing or we could also set them to allow failure, then we could at least manually verify if there are *new* changes if we want to, but also seems like a waste of resources. Decision for @acbramley to make.

> Could we consider enabling PHPStan checks on the next major version? While it's understandable that we might encounter some failures, setting it to 'allow failure' could still be beneficial. This way, we can ensure it runs and provides us with valuable insights.

I believe it is not useful. The insights are for the pretty far future, nothing we need to fix now. That said, my proposal is to not commit with next minor/major testing anyway and only do that on a weekly schedule, so it won't run in on merge requests either way. Again. decision for @acbramley.

With these changes https://www.drupal.org/project/diff/issues/3406873 📌 Adopt GitlabCi Fixed Previous minor and major version of phpunit will fail.
It would be good if maintainer decide what could be the next steps:

• Whether to include OPT_IN_TEST_PREVIOUS_MINOR and OPT_IN_TEST_PREVIOUS_MAJOR in the gitlab and revert the changes made in the tests files which is pushed in a issue#3406873 📌 Adopt GitlabCi Fixed
• Or include D11 and issue#3406873 📌 Adopt GitlabCi Fixed in the 2.x branch 📌 Cut a 2.x branch Active

@ankitv18 those changes were for Drupal 8, we don't support Drupal 8 anymore.

I'm find this hard to follow as questions are being asked and then more changes are being pushed.

I do not feel like we need to run tests on previous minor/major. This is just busywork maintenance to keep the tests working. For a module that's already undermaintained for how widely it is used, I would prefer to not have this overhead.

CORE_PREVIOUS_PHP_MIN: 8.1

I've bumped the minimum PHP already on 8.x-1.x to 8.1, is this still needed?

Basically, I agree with #31

acbramley → changed the visibility of the branch project-update-bot-only to hidden.

Thanks for all the work here, we've got green tests for next major and minor and only a small number of phpstan failures on next major which we're ignoring for now (these can be fixed in a follow up but is not a priority).

Here's what I settled on:

1. Fail phpcs/phpstan on current version
2. Allow failures on next major/minor for phpstan
3. Run tests on next major/minor
4. Turn off SYMFONY_DEPRECATIONS_HELPER on next major

acbramley → changed the visibility of the branch 2.x to hidden.

acbramley → changed the visibility of the branch 3429862-d11-compatibility-fixes to hidden.

Automatically closed - issue fixed for 2 weeks with no activity.

Do you want to leave this open in case there are more automated fixes coming?