When running Drupal with PHP 8.4, several methods in Panels trigger deprecation warnings due to parameters being implicitly nullable.
PHP 8.4 deprecates signatures where a parameter has a type declaration but is given a NULL default without being explicitly marked nullable.
Example pattern triggering the deprecation:
Request $request = NULL
PHP now requires this to be written as:
?Request $request = NULL
When caches are rebuilt (for example via the UI), the following deprecation notices appear:
Deprecated function: Drupal\panels\Form\PanelsAddBlockForm::buildForm():
Implicitly marking parameter $request as nullable is deprecated.
Deprecated function: Drupal\panels\Storage\PanelsStorageManager::access():
Implicitly marking parameter $account as nullable is deprecated.
Deprecated function: Drupal\panels\Storage\PanelsStorageManagerInterface::access():
Implicitly marking parameter $account as nullable is deprecated.
Deprecated function: Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant::access():
Implicitly marking parameter $account as nullable is deprecated.Update the affected method signatures to explicitly mark nullable parameters.
Review patch.
None
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | panels-php8-4-deprecations-3577740-2.patch | 2.63 KB | smulvih2 |
Comments
Comment #2
smulvih2Patch fixes the issue for me on PHP8.4, panels 4.9.0.
Comment #3
vistree commentedThank you @smulvih2. Your path fixes the PHP 8.4 panels error - which also occured on running drush commands
Comment #4
joseph.olstad+1 thanks!
Comment #5
joseph.olstadDuplicate of
#3534531: php 8.4 compatibility issue
The solution is to use 4.x-dev or wait for 4.10
once 4.10 is tagged, this above patch won't apply anymore.
Comment #6
joseph.olstadleave this open until 8.x-4.10
Comment #7
torreytoomajanian commentedThe same error was getting thrown from another area so I went ahead and remade the patch to cover it as well.
Comment #8
joseph.olstad@torreytoomanjanian, patch 7 is identical to patch #2, all you've done is introduce fuzz
I suggest re-reading comment #5, the solution is to switch to 4.0.x-dev while awaiting 4.10
NO PATCH REQUIRED unless you stick to 4.9 instead of using 4.0.x-dev that has the fix
Comment #9
joseph.olstadComment #10
xem8vfdh commented> The solution is to use 4.x-dev or wait for 4.10
> once 4.10 is tagged, this above patch won't apply anymore.
I dont see 4.10 here: https://www.drupal.org/project/panels/releases
Am I missing something, if not, any idea when it's expected?
Comment #11
joseph.olstadComment #12
xem8vfdh commentedI hear you. It is of course humorous to call using the latest official release "stubborn"
I, like many, can wait on the official release, as this is a warning not a break, and its suppressed in properly configured prod.
Comment #13
joseph.olstadThis actually should be closed as a duplicate however the issue is that the maintainer(s) is/are intentionally neglecting this project.
Perhaps it's time for a replacement.
There's a replacement pattern that is basically like forking. Have a look at the explanation.
I've done this before for jquery_ui (jq_ui) and the book module (livre). Basically clone this project (panels) , push it into a new project such as panels_forever . I'm tempted to do this to try out an even easier flow, basically just leave the module code in place and add a panels_forever.info.yml file which is a dummy file that doesn't need to be installed. Otherwise a simple composer replace directive in the composer.json file.
I'm tempted to try out this in a simplified approach I just described. Previously I put the module into a folder inside the new project but I don't even think that's necessary. Would have to try and see.
Comment #14
xem8vfdh commentedI would wholeheartedly support you. The module has been neglected for years now, basically since D8 if I remember correctly, and core made the broad shift to Symfony.
Comment #15
liam morland