Closed (fixed)
Project:
Monitoring
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 Apr 2022 at 09:44 UTC
Updated:
3 Sep 2022 at 09:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
primsi commentedThis patch gets around this problem, but I am not sure if we should try to approach this in a different way.
Comment #4
berdirFine with that. Instead of ??, we can also just use a (string) cast, possibly only on the placeholder array.
test fail is likely not related.
Comment #5
berdirI noticed in #3277425: PHP 8.1 compatiblity in metatag integration that PHP 8.1 deprecation messages are suppressed, at least in kernel tests.
Running kernel test with that enabled gives me this:
The patch fixes some of these but not all.
Comment #6
berdirThe test fails can be fixed by adding "$this->assertSession()->elementExists('css', '#result')->click();", it looks like the details element needs to be opened first as it only sees visible text, must have changed at some point.
fine to just add them in here IMHO.
Comment #7
primsi commentedFixed most of the deprecation notices, except those in
Drupal\Tests\monitoring\Kernel\MonitoringCoreKernelTest::testImageMissingStyleSensorPluginwhich we talked about in chat.Comment #8
primsi commentedChecking if the functional test passes.
Comment #10
berdirOpened #3279289: file_requirements() can trigger a PHP 8.1 deprecation notice when called without a SERVER_SOFTWARE server env variable for the file_requirements() issue.
Something I recently found is that you can define the deprecation configuration as a regular expression:
Then, for kernel tests, combine that with
protected $runTestInSeparateProcess = FALSEThis will immediately stop the test on a deprecation notice and print a full backtrace.
But nothing gave me anything useful in this specific case. Then I realized that we're inside a twig render process and the rendering captured output and put it inside the rendered content. And in the case above, it just eat it and then died.
So I printed out the rendered output, which gave me this:
This I tracked down to \Drupal\monitoring\Plugin\monitoring\SensorPlugin\WatchdogAggregatorSensorPlugin::verboseResultHistory
So the limit that it's trying to print is a config that's not imported in the test. Importing dblog config fixes it.
But there's also a real bug here and that's using :placeholder for something that''s not actually an attribute, should be @ for both. Fixed, also fixed the other case in the JS test that needs this and improved some sleeps().
Comment #11
cilefen commentedComment #14
berdirCommitted.