Fix phpstan issues reported by GitLab CI

This fixes all phpstan issues identified by phpstan. Those that don't really need to be fixed are ignored appropriately, either in-line or in the phpstan.neon file (newly added with this MR).

Most of these fixes are very minor (phpdoc types, for example), but there is one important one-- at present, the cache backend never gets set for EncryptionMethod (fixed in this MR).

This MR also requires phpstan to pass so that future MRs don't introduce new errors.

This is great. Thank you, @ptmkenny. I love to see all that green in the pipelines.

Well, it looks as though we'll have to wait to require PHPStan to pass until after we drop backward compatibility for earlier versions of Drupal. The code to ignore PHPStan errors related to setMethods() can either be in phpstan.neon or as @phpstan-ignore-next-line lines in EncryptionProfileTest.php. Either would be fine with me, though I suppose I have a slight preference for the latter, since removal of those ignore lines could then just be part of the removal of the backward-compatibility code to which it relates. Either way, once we have a new release that supports Drupal 11, it can be the last one compatible with D8 and D9, and we can begin the process of stripping out backward-compatibility.

Thanks for looking at this. As for where to put the ignore for setMethods, I don't have a strong preference; I put it in phpstan.neon originally because phpstan will throw an error if you have ignores anywhere that never "hit", so as soon as all the deprecated code is removed, phpstan will throw an error (ignoring an error that isn't present), and then that line can get removed from phpstan.neon. But it works the same way with @phpstan-ignore-next-line; if the error is "fixed" for the line, then phpstan will throw an error if the ignore remains in place. So I think this is ready to go.

I addressed the issue with PHPStan and backward compatibility, but now PHP CodeSniffer tests are failing on files that didn't change.

Very strange. I pulled your changes locally and ran phpcs-- everything seems fine.

Ok, I found the issue-- the coding standards themselves got updated overnight (drupal/coder (8.3.24 => 8.3.25)).

I ran the auto-updates, but EncryptService's third argument is allowed to be null, which I'm guessing is a backwards-compatible addition for the 3.x branch. However, there is no formal deprecation for 4.x, so if it is supposed to be deprecated, perhaps we should create another issue and add a formal deprecation. Or, if it's not supposed to be deprecated, my comment should be revised.

The coding standards are also fixed in a separate issue 📌 phpcs september 2024 update Active , so either that issue should be committed first and then this one, or this one should be committed and that one closed.

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