PHP 8.1 introduces many deprecation notices that would not appear previously. In my experience, it seems that hitting one of these notices (when thrown by a contrib module) generally causes a critical error coming from Core -- Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).. In such cases, the deprecation message is included in the stack trace:
Update: this was a core PHP bug, that was fixed in the (very) recent PHP 8.1.6 release.
The website encountered an unexpected error. Please try again later.
Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).
_drupal_error_handler_real(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 346)
_drupal_error_handler(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 571)
include('/var/www/html/drupal/web/core/includes/bootstrap.inc') (Line: 571)
Composer\Autoload\includeFile('/var/www/html/drupal/vendor/composer/../../web/core/lib/Drupal/Core/Utility/Error.php') (Line: 428)
Composer\Autoload\ClassLoader->loadClass('Drupal\Core\Utility\Error') (Line: 44)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->on403(Object) (Line: 97)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->onException(Object, 'kernel.exception', Object)
call_user_func(Array, Object, 'kernel.exception', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.exception') (Line: 219)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable(Object, Object, 1) (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 49)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Fixing/patching the deprecation seems to get rid of the notice, as well as this error handler error itself. The error handler error is problematic because it turns what should be a simple notice into a critical failure. I think that what must be happening is that the deprecation is somehow short-circuiting the autoloader or something.
This is an intermittent bug that seems to appear at a frequency of every few days. So far it has only been reported due to PHP core deprecation notices (e.g. for new return types for classes like ArrayAccess). As such, the problem may be with recursive classloader calls, i.e.:
- Classloader loads class A that extends a PHP core class - PHP triggers a deprecation notices for a return type.
- Drupal error handler is invoked
- The error handler triggers autoloading of \Drupal\Core\Utility\Error
- autoloading of \Drupal\Core\Utility\Error fails (why?) -> fatal
There are no obvious steps to reproduce, you need a module installed which triggers a PHP deprecation notice, possibly php-fpm, and it may take several days for this error to appear.
Add a hook_requirements() to all supported branches of Drupal that checks for PHP >= 8.1.0 and < 8.1.6, and suggests updating to PHP 8.1.6 due to intermittent PHP autoloading issues.
PHP 8.1.6 is so recent that a hard requirement would potentially be a barrier to running Drupal for several months, and this only happens with deprecation warnings triggered via classloading, which isn't a problem for every install.
If we detect PHP 8.1.0 through 8.1.6, we should make sure the status report warns about it. How exactly we do that varies depending on Drupal version.
In Drupal 10, PHP 8.1.0 is the minimum bootable PHP version, and 8.1.6 is now the minimum recommended version. So, if we detect a broken PHP version is running, we should change the PHP section of the status report to a warning, with this (proposed) wording:
PHP $RUNNING_VERSION has an OPcache bug that can cause fatal errors with class autoloading. This can be fixed by upgrading to PHP 8.1.6 or later.
See #110, #111, and #112 for screenshots in 9.4.x, 9.5.x, and 10.0.x, respectively.
Needed.
| Comment | File | Size | Author |
|---|---|---|---|
| #112 | 3258987-10.0.x-8.1.1.png | 50.03 KB | phenaproxima |
| #112 | 3258987-10.0.x-8.1.9.png | 16.23 KB | phenaproxima |
| #111 | 3258987-9.5.x-7.3.1.png | 101.4 KB | phenaproxima |
| #111 | 3258987-9.5.x-7.4.2.png | 87.01 KB | phenaproxima |
| #111 | 3258987-9.5.x-8.0.3.png | 87.78 KB | phenaproxima |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
patrickmichael commentedI think my issue is related to this issue. I am running Drupal 9.3.2 with PHP 8.1.1. It is an upgrade from 8.9.20. I do not know what triggers this. I am not sure how to reproduce. The event causes the site to the state of 'The website encountered an unexpected error.....'
Any help to resolve this would be greatly appreciated.
Comment #3
cilefen commentedComment #4
john.glynn.davies commentedI upgraded to php 8.1.1 and encountered a similar issue, except in my case the missing class was:
Error: Class "Drupal\Core\Logger\RfcLogLevel" not found in /home/www/core/includes/errors.inc on line 26 #0 /webroots/www/studio/core/includes/errors.inc(60): drupal_error_levels()But I couldn't see what the actual error was inside _drupal_error_handler_real(8192, 'Return type of ...', '/home/www/c...', 107) because it was truncated (...).
I was going mad trying to figure out how to get at that but then restarted PHP and that seemed to resolve the issue.
Hope that helps someone!
Comment #5
mrweiner commentedI saw the same as #4 while trying to figure out repro for the initial description. If not the same issue, it may be a separate but related error. Steps to recreate that were:
1. Create a new drupal installation on 7.4 with DDEV
2. Run standard install
3. Load up the site url, site loads fine
4. Update image settings to use 8.1 instead of 7.4
5. Restart the container
6. Hit the RfcLogLevel error when loading up the site
7. Restart the container and the error disappears.
Comment #6
gnumatrix commentedThanks #4 !!
After mindlessly upgrading my Ubuntu system, PHP moved from 8.1.1 to PHP 8.1.2 and then I got this error:
Error: Call to undefined function _drupal_error_handler_real() in require_once()And indeed, a restart of PHP was all that was needed to correct it.
systemctl restart php8.1-fpm.serviceAnd all is well once again.
Comment #7
cilefen commentedThis looks like platform issues.
Comment #8
mrweiner commentedI'm tempted to reopen this, but I'll leave it be since I haven't found reliable reproduction. If anybody else lands here from google and #4 does not solve your issue, I'd encourage you to leave a comment with additional context in case there's some other underlying issue.
Comment #9
hansfn commentedIt might be a platform issue, but switching to 8.1 on my service provider causes the
Class "Drupal\Core\Logger\RfcLogLevel" not founderror and switching back to 8.0 fixes it again. (And 7.4 works.) It would be nice if Drupal was able to recover from the situation.Yes, that seems to be the issue on my side too.
Comment #10
cilefen commentedClass not found is not a deprecation notice.
Comment #11
mrweiner commented@cilefen you're right that "class not found" is not a deprecation notice, but it seems to be coming as a result of how Drupal internally is dealing with 8.1's deprecation notices or other things being fired by 8.1 in certain scenarios. Potentially an autoloader bug that's just tough to pin down. Just wanted to clarify.
@hansfn, it sounds like restarting PHP seems to get rid of the RfcLogError specifically, so it might be worth switching to 8.1 and restarting php to see if that fixes it for you.
Comment #12
didier misson commentedSame error as Patrick Michael :
Drupal 9.3.5
PHP 8.1.2
Anonymous users seem have NO problem.
Login users have :
Call to undefined function _drupal_error_handler_real() in /core/lib/Drupal/Core/DrupalKernel.php on line 568
If I reboot the server, or restart PHP FPM, it's ok...
but error come back some minutes... or hours later...
Thanks
Comment #13
gillesbailleuxThe error log mentioned by Didier Misson on #12:
Comment #14
cilefen commentedIf restarting PHP helps and the error appears after some time then I am curious about the opcache versions and configurations.
Comment #15
didier misson commentedphp8.1-opcache is installed
php info give me :
/etc/php/8.1/fpm/conf.d/10-opcache.ini
So opcache is enable.
; configuration for php opcache module
; priority=10
zend_extension=opcache.so
I think I simply install opcache, but not change the default option...
------------------------
Zend OPcache
Opcode Caching Up and Running
Optimization Enabled
SHM Cache Enabled
File Cache Disabled
JIT Disabled
Startup OK
Shared memory model mmap
Cache hits 39178
Cache misses 2668
Used memory 51458800
Free memory 82758928
Wasted memory 0
Interned Strings Used memory 4339752
Interned Strings Free memory 1951240
Cached scripts 2617
Cached keys 3961
Max keys 16229
OOM restarts 0
Hash keys restarts 0
Manual restarts 0
Directive Local Value Master Value
opcache.blacklist_filename no value no value
opcache.consistency_checks 0 0
opcache.dups_fix Off Off
opcache.enable On On
opcache.enable_cli Off Off
opcache.enable_file_override Off Off
opcache.error_log no value no value
opcache.file_cache no value no value
opcache.file_cache_consistency_checks On On
opcache.file_cache_only Off Off
opcache.file_update_protection 2 2
opcache.force_restart_timeout 180 180
opcache.huge_code_pages Off Off
opcache.interned_strings_buffer 8 8
opcache.jit tracing tracing
opcache.jit_bisect_limit 0 0
opcache.jit_blacklist_root_trace 16 16
opcache.jit_blacklist_side_trace 8 8
opcache.jit_buffer_size 0 0
opcache.jit_debug 0 0
opcache.jit_hot_func 127 127
opcache.jit_hot_loop 64 64
opcache.jit_hot_return 8 8
opcache.jit_hot_side_exit 8 8
opcache.jit_max_exit_counters 8192 8192
opcache.jit_max_loop_unrolls 8 8
opcache.jit_max_polymorphic_calls 2 2
opcache.jit_max_recursive_calls 2 2
opcache.jit_max_recursive_returns 2 2
opcache.jit_max_root_traces 1024 1024
opcache.jit_max_side_traces 128 128
opcache.jit_prof_threshold 0.005 0.005
opcache.lockfile_path /tmp /tmp
opcache.log_verbosity_level 1 1
opcache.max_accelerated_files 10000 10000
opcache.max_file_size 0 0
opcache.max_wasted_percentage 5 5
opcache.memory_consumption 128 128
opcache.opt_debug_level 0 0
opcache.optimization_level 0x7FFEBFFF 0x7FFEBFFF
opcache.preferred_memory_model no value no value
opcache.preload no value no value
opcache.preload_user no value no value
opcache.protect_memory Off Off
opcache.record_warnings Off Off
opcache.restrict_api no value no value
opcache.revalidate_freq 2 2
opcache.revalidate_path Off Off
opcache.save_comments On On
opcache.use_cwd On On
opcache.validate_permission Off Off
opcache.validate_root Off Off
opcache.validate_timestamps On On
Comment #16
patrickmichael commentedI can confirm behaviour similar to #12, the error returns after restarting PHP. In one case, the site was fine for quite a few days before the error returned. On other occasions, the error returned within a few hours.
Comment #17
Cynthia Ewer commentedSubscribing.
New Ubuntu server running PHP 8.1. Two out of about 15 D9 installations go offline after kernel or server updates.
Error log: AH01071: Got error 'PHP message: Error: Class "Drupal\\Component\\Utility\\Xss" not found
Solution in #6 works for me: systemctl restart php8.1-fpm.service
Comment #18
ConradFlashback commentedSame problem.
Restart PHP server works, but I think error will come back some hours or days later.
Does anyone know a definitive solution? I must change to an older PHP version?
Comment #19
nottaken commentedFollowing. Seeing the same issue with 9.3.5 and PHP 8.1.
Comment #20
cilefen commentedReading this carefully there are in fact two separate issues reported:
Although they may share a common cause, they are different. The first is a require failure and the second one is an autoload failure.
I just want to point that out.
Comment #21
ConradFlashback commentedMy #18 report is for second error: Error: Class "Drupal\Core\Utility\Error"
This is the ontopic error signaled by first reporter.
Comment #22
mrweiner commented@ConradFlashback a middleground solution instead of downgrading php might be to set up a cron job to restart PHP on some schedule, since it sounds like that temporarily addresses the issue for some people. We haven't really figured out what's going on yet.
Comment #23
szato commentedSame error:
Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() - line 63On Drupal 9.3.6 ; Php 8.1.2
Comment #24
dolst commentedHello everyone, just thought I'd weigh in here. I'll try to provide as many details as possible but if I didn't think of something, I'll try my best to update in a future post. Anyway, I have a multisite Drupal installation. It started as Drupal 8 and I recently upgraded to 9. I do everything on command line and don't use composer or drush or anything like that. I have one master site and two sites under that. Everything was fine until I tried to add a new site. Any attempts to do anything in the backend like logging in or anything like that cause the dreaded "Unknown error" page which then brings down all the sites. Restarting httpd does clear this error until the next time I try to log in.
The error I get in my logs is:
I am running Drupal 9.3.6 on PHP 8.1.3. I only get this error (repeatedly) after adding a new site. Restarting httpd will clear it until I go to log in to a site. After restoring my Drupal installation with only the 3 original sites (and restarting httpd), everything runs fine. Not sure how much this will help, but hopefully it's another piece of the puzzle.
Surf Wisely.
Comment #25
_gramur commentedI can confirm I've been experiencing the same issues with PHP 8.1 as well. Restarting PHP solves the problem but can be problematic if running multiple Drupal instances on the same server sharing the same PHP resources. For example restarting PHP can bring 1 site back up while bringing down another one. Multiple PHP restarts solves this problem.
Comment #26
borisbarowski commentedI have the same issue, a site that was working well on PHP7.3 is now broken (after a while, not immediately after apache restart) on PHP8.1.3 using Drupal 9.3.6. Maybe it's the system, but I don't see it. Opcache is enabled and Up and Running
issue is the same
The first error I get in the logs is related to a deprecated function
Deprecated function: Return type of Drupal\google_analytics\Component\Render\GoogleAnalyticsJavaScriptSnippet::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in include() (regel 10 van /srv/www/wu/web/modules/contrib/google_analytics/src/Component/Render/GoogleAnalyticsJavaScriptSnippet.php)Open to provide any information required to advance this issue.
Comment #27
szato commentedWe are using media image as a featured image for articles and if we uploaded a new image file with "Add media" on the node add page, we got an ajax error with empty message - related issue: Uncaught Drupal.AjaxError with empty response text.
Our backtrace error message (related to search_api):
We are on Drupal 9.3.6; Php 8.1.2 and nginx/1.18.0
For us this nginx settings solved the issue:
client_body_buffer_size 8m;Comment #28
cilefen commentedThat is quite interesting. Some respondents are using Apache, so there are probably more pathways. We may be looking at a newly undocumented web server requirement.
Comment #29
ConradFlashback commentedThere any update for this?
Today another crash solved restarding PHP. But it's impossible manage this.
My log is little different from first post. Error from line 26,
Comment #30
DropInTheOcean commentedIn case it helps anyone, in my case the error occurred after a scheduled server reboot.
The php8.1-fpm.service was not running - apparently it was started manually. I needed to enable (to run automatically on boot) with:
systemctl enable php8.1-fpm.serviceEdit: Day later the issue returned. systemctl restart apache2 && systemctl restart php8.1-fpm.service solves the issue short term. It looks like something is crashing php8.1-fpm?
Comment #31
ttnt commentedHello,
After updating to 9.3.3 I also got this error, I reported it in slack at the time.
[error] [pid 2894254] mod_proxy_fcgi.c(887): [client 157.193.192.109:0] AH01071: Got error 'PHP message: Error: Call to undefined function _drupal_error_handler_real() in /data/sites/web/core/lib/Drupal/Core/DrupalKernel.php on line 568 #0 /data/sites/web/core/lib/Drupal/Core/DrupalKernel.php(568): _drupal_error_handler()\n#1 /data/sites/web/core/lib/Drupal/Core/DrupalKernel.php(568): require_once()\n#2 /data/sites/web/core/lib/Drupal/Core/DrupalKernel.php(583): Drupal\\Core\\DrupalKernel->loadLegacyIncludes()\n#3 /data/sites/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(46): Drupal\\Core\\DrupalKernel->preHandle()\n#4 /data/sites/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle()\n#5 /data/sites/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\\page_cache\\StackMiddleware\\Pag...'The answer I got was the following:
Now I didn't apply patches and I just wanted to check if new composer updates worked fine, I didn't have any problems anymore and just forgot about it. Tried to bump the server to 8.1 again today and... well, here I am again :).
I hope there's a logical explanation for this, as I'll have to update to 8.1 sooner or later.
edit: it's worth noting that before my update to 9.3.3 I was running PHP8.1 just fine. I usually apply all core updates prior to every third Wednesday of the month ahead of the security window, so I'm not 100% sure if it's the patch release or the minor before that introduced it for me.
Comment #32
catchBumping this to critical and moving to a bug report, this looks like a PHP 8.1 regression in the composer autoloader, but it might be triggered by some weird things in our error handling.
The important part of the stack trace for me:
As with #3258987-30: Status report should warn about OPcache bug in PHP 8.1.0 to 8.1.5 restarting fpm cleared the error, so could be APC caching the wrong file location somehow? This happened to me just after updating core locally.
Comment #33
plessas commentedI also encountered the same issue in an Almalinux server, running php 8.1.4 and Drupal 9.3.8. The error appeared when the Anonymous user tried to visit a previously published page that is now unpublished. Restarting php-fpm solved the issue for now...
Comment #34
ConradFlashback commentedI confirm #33.
So I have two problems:
1) This is the error when I open a content (node/product variation) not published. But in my case my site did'nt crash completely, error goes only in log.
2) This is the error when site crashes and I must restart php-fpm to temporarily resolve.
Error: Class "Drupal\\Core\\Logger\\RfcLogLevel" not found in /data/www/*/htdocs/web/core/includes/errors.inc on line 26 #0 /data/www/*/htdocs/web/core/includes/errors.inc(60): drupal_error_levels()\n#1 /data/www/*/htdocs/web/core/includes/bootstrap.inc(346): _drupal_error_handler_real()\n#2 /data/www/*/htdocs/vendor/composer/ClassLoader.php(571): _drupal_error_handler()\n#3 /data/www/*/htdocs/vendor/composer/ClassLoader.php(571): include('...')\n#4 /data/www/*/htdocs/vendor/composer/ClassLoader.php(428): Composer\\Autoload\\includeFile()\n#5 /data/www/*/htdocs/web/core/lib/Drupal/Core/Logger/LoggerChannelFactory.php(34): Composer\\Autoload\\ClassLoader->loadClass()\n#6 /data/www/*/htdocs/web/modules/contrib/metatag/src/MetatagManager.php(88): Drupal\\Core\\Logger\\LoggerChannelFactory->get()\n#7 /data/www/*/htdocs/web/core/lib/Drupal/Component/DependencyInjection/Container.php(262): Drupal\\metatag\\MetatagManager->__construct()\n#8 /data/www/*/htdocs/web/core/lib/Drupal/Component/DependencyInjection/Container.php(176): Drupal\\Component\\DependencyInjection\\Container->createService()\n#9 /data/www/*/htdocs/web/core/lib/Drupal.php(198): Drupal\\Component\\DependencyInjection\\Container->get()\n#10 /data/www/*/htdocs/web/modules/contrib/metatag/metatag.module(492): Drupal::service()\n#11 /data/www/*/htdocs/web/modules/contrib/metatag/metatag.module(298): metatag_get_tags_from_route()\n#12 /data/www/*/htdocs/web/modules/contrib/metatag/metatag.module(244): _metatag_remove_duplicate_entity_tags()\n#13 /data/www/*/htdocs/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(539): metatag_entity_view_alter()\n#14 /data/www/*/htdocs/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(305): Drupal\\Core\\Extension\\ModuleHandler->alter()\n#15 /data/www/*/htdocs/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(239): Drupal\\Core\\Entity\\EntityViewBuilder->buildMultiple()\n#16 [internal function]: Drupal\\Core\\Entity\\EntityViewBuilder->build()\n#17 /data/www/*/htdocs/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array()\n#18 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/Renderer.php(772): Drupal\\Core\\Render\\Renderer->doTrustedCallback()\n#19 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/Renderer.php(363): Drupal\\Core\\Render\\Renderer->doCallback()\n#20 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/Renderer.php(201): Drupal\\Core\\Render\\Renderer->doRender()\n#21 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(241): Drupal\\Core\\Render\\Renderer->render()\n#22 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->Drupal\\Core\\Render\\MainContent\\{closure}()\n#23 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(242): Drupal\\Core\\Render\\Renderer->executeInRenderContext()\n#24 /data/www/*/htdocs/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(132): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->prepare()\n#25 /data/www/*/htdocs/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->renderResponse()\n#26 [internal function]: Drupal\\Core\\EventSubscriber\\MainContentViewSubscriber->onViewRenderArray()\n#27 /data/www/*/htdocs/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func()\n#28 /data/www/*/htdocs/vendor/symfony/http-kernel/HttpKernel.php(163): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch()\n#29 /data/www/*/htdocs/vendor/symfony/http-kernel/HttpKernel.php(80): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw()\n#30 /data/www/*/htdocs/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\\Component\\HttpKernel\\HttpKernel->handle()\n#31 /data/www/*/htdocs/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\\Core\\StackMiddleware\\Session->handle()\n#32 /data/www/*/htdocs/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle()\n#33 /data/www/*/htdocs/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\\page_cache\\StackMiddleware\\PageCache->fetch()\n#34 /data/www/*/htdocs/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\\page_cache\\StackMiddleware\\PageCache->lookup()\n#35 /data/www/*/htdocs/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\\page_cache\\StackMiddleware\\PageCache->handle()\n#36 /data/www/*/htdocs/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle()\n#37 /data/www/*/htdocs/web/modules/contrib/detect_mobile/src/Middleware/MobileDetectMiddleware.php(61): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle()\n#38 /data/www/*/htdocs/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\detect_mobile\\Middleware\\MobileDetectMiddleware->handle()\n#39 /data/www/*/htdocs/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\\StackedHttpKernel->handle()\n#40 /data/www/*/htdocs/web/index.php(19): Drupal\\Core\\DrupalKernel->handle()\n#41 {main}Comment #35
propercroc commentedRunning Ubuntu-Plesk with PHP 8.1 and got error from #4 .
In Plesk, I tried both "FPM Application served by Apache" and "dedicated FPM Application served by Apache". Both show this error, but only after some time. Sometimes hours, sometimes days. Restarting fixes the error, but re-appears after a while.
Only appears to logged-in-users, anonymous is not exposed to this error. All /admin/* pages are concerned.
I just downgraded eight Drupal9 instances to php7.4 because of this.
Good luck finding this one and thanks for everybodies help on this.
Comment #36
catchComment #37
mrweiner commented@ProperCroc, it sounds like you can probably run php8.0 instead of 7.4 without issue. The problem seems to have to do with 8.1 specifically.
Comment #38
ConradFlashback commentedMe too I downgraded php version for my project. So I can't test now.
But I will follow this issue.
Comment #39
plessas commentedIn my case the error reappeared after around 10 days, again when visiting pages without appropriate access permissions. Restarting php-fpm results in the normal 403 access denied page.
Comment #40
francoud commentedSame problem here. Website version: Drupal 9.3.9. Normally running with PHP 7.4 with no problem. Using PHP 8.1 I have this error:
both in watchdog and on server log (apache on debian). Note that the website was created from tarbal, not with composer.
Another website - same server - but created with composer, works perfectly with PHP 8.1.
Comment #41
parijke commentedSame problem here with Drupal 9.3.9. Reverted back to php 8.0.17
Comment #42
lingros commentedWe have same problem with Drupal 9.3.9 on PHP-FPM 8.1.4. After disabling OPcache the issue is gone, but I hope it's not final solution. Website previously ran on PHP-FPM 7.4 without problem.
Comment #43
rafageist commentedThe original error is another. For example, in PHP 8.1, by default, deprecated notice is a fatal error:
Return type of Drupal\google_analytics\Component\Render\GoogleAnalyticsJavaScriptSnippet::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice.
The problem is that when Drupal tries to call the error handler, it doesn't exist before the error occurs.
The solution?
1. The Drupal team needs to fix the error's handler loading sequence.
2. Module developers should check for compatibility with PHP 8.1
3. Fow now, change the code of this function on bootstrap.inc:
The line with include, no fix the problem, but show the real error: PHP 8.1 Incompatibility
Comment #44
mfbI haven't reproduced this issue myself yet, but I did notice that some potentially-related issues re: Opcache on PHP 8.1 have been reported, e.g. https://github.com/php/php-src/issues/8164 and https://github.com/php/php-src/issues/8063
Comment #45
rafageist commentedAdding temporarily opcache_reset() in the index.php and adding #[\ReturnTypeWillChange] to suppress compatibility errors solved my problem.
Comment #46
mfbre: #44 it looks like Opcache bug fix is in progress, could be verified by building PHP from source or trying 8.1.6 when it's released
Comment #47
john_b commentedI have seen this on php 8.1.4, which crashed the site for anonymous only. Upgrading the Debian package to 8.1.5 appears to have fixed it, at least in the short term.
Comment #48
catchFound an old issue which is similar #1948600: PHP Fatal error: Class 'Insert' not found in \SomeNamespace\SomeClass.php on $lastline and might point to the underlying issue - is it because an error is triggered in the process of loading the class itself? Should we require_once the error class somewhere?
Comment #49
szato commentedConfirmed: We got this error on 8.1.2, updating php to 8.1.5 fixed.
Comment #50
xjmIf PHP 8.1.5 does indeed resolve the issue, we might want to increase Drupal 10's minimum requirement to 8.1.5.
For Drupal 9. we could also add a platform-level constraint forbidding PHP 8.1.2-8.1.4 if that is confirmed to be the root of the problem.
Comment #51
mfbThat would be great although I'm not clear why 8.1.5 would resolve this, as the issue(s) I mentioned in #44 will be fixed in 8.1.6
Restarting PHP temporarily resolves the opcache problem so false negatives are possible..
Comment #52
catchHave tried to update the issue summary with a few more details.
I'm leaving the 'Needs steps to reproduce' tag on because it would be amazing to have clear steps to reproduce. However this is not the same as 'cannot reproduce' in this case. I've personally experienced the error developing locally, only on one install, at a frequency of about once every ten days, so it is both intermittent and extremely infrequent.
When I tried to debug, I couldn't find any obvious place where Drupal or Composer autoloader code was at fault (apart from the PHP 8.1 deprecation notice that triggers the bug in the first place). It seemed like it was getting to composer requiring Error.php successfully, but then PHP not actually getting the Error class into memory and fatalling since the autoloader thought it had autoloaded by that point, which to me points to a PHP bug.
It has been extremely rare for PHP to issue deprecation notices when classes are autoloaded prior to PHP 8.1, so it might be that there's a pre-existing (PHP or Drupal or Composer) bug when the autoloader triggers the error handler, in turn triggering the autoloader, #1948600: PHP Fatal error: Class 'Insert' not found in \SomeNamespace\SomeClass.php on $lastline suggests that something similar may have happened before, and there just hasn't been enough cases for us to run into it. Or it could be that there's a new bug in PHP 8.1 combined with the new deprecation errors.
Feels like there is a possible workaround where we could require Error.php from the error handler before the class is autoloaded and shortcut the autoloader, but it will be very hard to verify this solves the problem because you could potentially still have the bug and go weeks without running into it. And it will also be hard to verify when it's safe to remove, because it's such an infrequent intermittent error.
Also removing PHP versions from the issue summary because until we have a specific PHP commit to, not sure I want to assume it's fixed by PHP 8.1.5 - or at least not until people have gone a month or two without experiencing it again.
Comment #53
mfbPHP 8.1.6RC1 is available if anyone wants to work on verifying the potential fix in https://github.com/php/php-src/pull/8297 (which as @catch said could take a while)
Comment #54
xjmAt least two people say specitically say updating to PHP 8.1.5 resolved the issue. What additional proof would we like?
Comment #55
catch@xjm I think we need someone to go a full month or more, with the same PHP 8.1 deprecation error that triggered the bug left unfixed, and triggered on the environment often enough, without also running into the fatal error.
Just not having the error for a couple of days after upgrading could equally happen if it's still there, since it's so infrequent.
Comment #56
parijke commentedCan confirm 8.1.5 keeps stable untill now.
Comment #57
petr illek@catch I just got this error on 9.3.12 running on PHP 8.1.4. The steps to trigger it every time is creating new user with the Email notification checkbox checked.
Comment #58
berdirDid also run into this one in a project. Did suddenly happen ~10h after a deployment. Agreed looks like a very weird classloading problem.
Another slightly different stacktrace:
This is on an access denied page in this specific case. Unfortunately shortened strings. What's super weird to me is that autoloading the error class actually ends up loading an includes file and then it jumps into the drupal error handler with something that I think comes from a module? Also google_analytics I think.
But it also happened very early in bootstrap then suddenly:
Comment #59
berdirAnother indication that this is a bug in the opcache is that the problem didn't appear on CLI, cron jobs as well as a full drush cr worked just fine.
Possible PHP issue: https://github.com/php/php-src/issues/8164
=> This should be fixed with PHP 8.1.6.
Comment #60
catchhttps://github.com/php/php-src/issues/8164 looks extremely likely, reports are very similar to the ones here, that'd be enough for me to want to raise the 10.0.x minimum PHP version to 8.1.6, and we can document why somewhere.
We probably also need to do something for 9.4.x, like try to stop people running on 8.1.0-8.1.5, but that might need a special hook_requirements() rather than using the existing constants?
Comment #61
berdirOh, I think i misread that comment. Looks like 8.1.6 isn't actually released yet? Only 8.1.6RC is, per that comment in that issue.
FWIW, I checked in with platform.sh, their containers are currently on 8.1.4
and depend on https://tracker.debian.org/pkg/php8.1, which currently is only on 8.1.5( I have been informed that this is wrong, they do not depend on that), I guess quite a few docker/container based solutions depend on that in one way or another? ddev containers are on 8.1.3 for me.No idea about our DrupalCI images and how quickly they'll update to 8.1.6 once it is actually released.
Requiring 8.1.6 too early might be quite annoying for developing/testing d10. Maybe start with a requirements warning or so, that's also something that could be backported to D9?
Comment #62
catchYep we need this for 9.x/10.x anyway and can open a separate issue for making it a harder requirement in 10.x - definitely might want to wait a couple of months for 8.1.6 to be more widely available, or limit it to a recommendation even.
Comment #63
mfbPHP 8.1.6 is out, which resolves the upstream issues mentioned in #44 which 🤞 is the same as this issue
I don't think there needs to be a hard dependency on a particular PHP version since there seem to be workarounds for older versions of 8.1 (fix code that logs errors/deprecations or disable opcache) - but adding a recommendation/warning could be helpful.
Comment #64
cilefen commented@mfb I agree with you.
Comment #65
catchMaybe we can do this for 10.0.x, but I'm not sure if it's slightly mis-using the
RECOMMENDED_PHPconstant.Another option would be a hook_requirements() for all supported Drupal versions that adds a warning for PHP >= 8.1.0 && < 8.1.6.
Yet another option is to document this on Drupal.org under PHP requirements somewhere and not bother putting a warning in core at all.
Comment #66
cilefen commentedI am in favor of the hook_requirements way.
Comment #67
catchOK I've updated the issue summary a bit and add the hook_requirements() suggestion to the proposed resolution there.
Comment #68
catchAlso going to bump this down to major since it's not really a core bug. However it would be good to add the hook_requirements() since this is a very tricky one to diagnose.
Comment #69
catchAlso a task now. And removing the beta blocker tag.
Comment #70
ravi.shankar commentedAdded reroll of patch #65 on Drupal 9.3.x.
Comment #72
mrweiner commentedOpened an MR that adds a system_requirements(). Reading through the comments on https://www.php.net/manual/en/function.version-compare.php, there may be some edge cases we'll miss but I think it'll catch most scenarios.
Comment #73
mrweiner commentedI'm unsure whether we also need the RECOMMENDED_PHP bit from #65 and #70.
Comment #74
cilefen commentedThere is system_requirements implementation in system.install.
Comment #75
cilefen commentedComment #76
catch@mrweiner I think we're better off without RECOMMENDED_PHP if we go the system_requirements() route, at least for this issue.
Comment #77
mrweiner commentedComment #79
xjmHiding patch files so that it's clear where the current work is.
Comment #81
xjmWent to rebase the branch but it's un-rebaseable, so opening a new MR against 9.4.x is easier given the small scope.
A few issues:
ifdoesn't follow our coding standards.Comment #83
xjmMade some edits to help address #81.
I do think we should also increase
RECOMMENDED_PHPto 8.1.6. It's already 8.1 on all actively developed branches.Comment #84
catchI've opened #3294938: Increase RECOMMENDED_PHP to 8.1.6 which I think we should definitely do in 10.0.x and maybe in 9.5.x
For 9.4.x IMO the new system_requirements() is better for backporting to a patch release, since it may not be straightforward for everyone to get onto 8.1.6 given it's only been out for six weeks.
Comment #85
xjmComment #86
xjmI realized we should consolidate this message into the existing messaging logic about PHP versions, because it's bad UX for the user to have two different, possibly conflicting messages about their PHP version.
However, this also underscores why I think we should backport a change in
RECOMMENDED_PHPto 9.4.x. Either that, or we lower it back to 8.0 on 9.4. Because if the user sees a message telling them to upgrade to at least 8.1, then upgrades to 8.1.3 or whatever, then sees another message telling them to upgrade to 8.1.6... speaking for myself, I'd want to stab things at that point.Comment #87
catchPHP 8.0 is security supported for longer than 9.4 will be, so lowering it there doesn't seem too bad. We could still have the hook_requirements() for people on 8.1.0-8.1.5 in that case.
Comment #88
xjmCurrent logic displays:
Comment #89
catch#3294938: Increase RECOMMENDED_PHP to 8.1.6 is in for 10.1.x-9.5.x, and I opened #3295085: [9.4 ONLY] Lower RECOMMENDED_PHP to 8.0 for 9.4.x
Patch looks good to me here.
Comment #90
andypostThe message is helpful to identify bug
Comment #91
xjmFor #89, I think it's an "and". We should both lower the recommended PHP, and backport an amended version of this that recommends updating to either PHP 8.0.0+ or PHP 8.1.6+ for 9.4.x only. It's worth having messaging that is correct since the branch has another year of coverage remaining.
Comment #92
xjmSo I think we should do #3295085: [9.4 ONLY] Lower RECOMMENDED_PHP to 8.0, and then the 9.4.x backport of this should adjust the message you get on PHP 7.4 and lower to indicate PHP 8.0+ or 8.1.6+ are recommended. I wonder if we can also do that without breaking strings...
Comment #94
xjmI pushed a new MR for 9.4.x. It displays the warning by itself when PHP 8.1.0-8.1.5 is installed, and also adds a note about it when recommending the user update their PHP version. I wrote the text in such a way that it should make sense regardless of whether PHP 8.0 or 8.1 is being recommended.
It's a bit ugly, but it does avoid breaking existing translatable strings in a patch release, and the use of
FormattableMarkupwon't be there in 9.5 and above.Comment #95
xjmScreenshots of the 9.4.x MR:
On PHP 7.4, with HEAD
On PHP 8.0, with HEAD
On PHP 8.0, with #3295085: [9.4 ONLY] Lower RECOMMENDED_PHP to 8.0
On PHP 8.1
Setting back to NR for the 9.4.x MR and for the UX review of both that and the 9.5.x+ version in the IS.
Comment #96
benjifisherUsability review
We discussed this issue at #3296084: Drupal Usability Meeting 2022-07-15. That issue will have a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @rkoller, @shaal, @simohell, @worldlinemine, and me.
I see that #3295085: [9.4 ONLY] Lower RECOMMENDED_PHP to 8.0 has been fixed since the last comment on this issue, so I tested myself with 9.4.x, 9.5.x, and the feature branches for this issue.
I notice that the PHP version information is always in the "General System Information" at the top of the page and sometimes in the "Status Details" section. I am not sure exactly when the version information is shown in the latter section, but this issue does not change that, does it?
Here is what I see in the various cases, hacking
core/modules/system/system.installto change the PHP version:9.4.x
3258987-9.4.x
3258987-warning
9.5.x
I notice that the message in the 3258987-warning branch is a little shorter than the one in the 3258987-9.4.x branch: the latter starts with "Note that" and ends with "when using PHP 8.1". This is a case where "less is more". In fact, "Note that" is one of my pet peeves.
Comment #97
kraut commentedLate to the party but working with Canonical to land the fix in Ubuntu 22.04 LTS.
Inside the Ubuntu community this requires an StableReleaseUpdate to get fixed.
Means it's not as simple as merging current 8.1.7 from Debian unstable aka sid.
Hence we went down the road like with CVEs and backported the actual patch.
From the 8.1.6 release we pinned it down to this PR on the OPcache bug cited:
https://github.com/php/php-src/pull/8297
We could use some Drupal community help as we miss a direct bug reproducer :)
Got you a PPA for testing and packages that get superseded after the SRU passed:
https://launchpad.net/~kraut.hosting/+archive/ubuntu/php
Love to get feedback here and at best a bug reproducer or contributing factors :)
FYI https://bugs.launchpad.net/ubuntu/+source/php8.1/+bug/1983205
Comment #98
mfbThat upstream PR includes a test / minimal reproduce case. With opcache enabled, it loads a class that triggers a compile-time error, then checks that additional classes can still be correctly autoloaded during shutdown.
Comment #99
phenaproximaI wonder if we cannot simplify this a tad. My thoughts:
There are two conditions that need to be true for this bug to manifest: you have to be on PHP 8.1.0 through 8.1.5, and opcache has to be enabled. So let's only show this warning if those are both true.
Secondly, the error should be more consistent. What if we said something like:
A number of words are removed here, like "intermittent" and "runtime". (We don't have to mention the PHP version range which has the bug, IMHO; that merely adds cognitive load, when I think the only message we should be delivering is "you have a problem right now; do this thing to fix it".)
And again, we would only show this warning if those two conditions I mentioned before are true.
Comment #101
phenaproximaAssigning this to myself after discussion with @xjm.
Comment #102
xjmAlso, the above branch metadata change is both deliberate and temporary. More soon. :)
Comment #104
benjifisherCan we add a follow-up issue now and reference it in both code comments?
I do not see anything in the current MR that checks whether opcache is enabled, but I am not sure that such a check is a good idea. First, it is more complicated than just checking the PHP version. Second, enabling/disabling opcache is easier than upgrading PHP. Imagine the poor site owner who upgrades the system software, checks the status report ... oops, I forgot to enable opcache ... and then does not re-check the status report.
I like your wording, and I agree that it is not worth delaying this issue too much while debating it. On the other hand, I would like to see the current wording in the issue summary (Proposed resolution section and User interface changes section), so I am adding the tag for an IS update.
Comment #105
phenaproximaYeah, I thought about this. I'm not sure if the bug only manifests itself if the
opcacheextension is enabled, but if so, we should probably hide this check behind aextension_loaded('opcache')check or similar, since I agree that we should offer people the solution that is most closely within reach (disabling opcache).Comment #107
xjmPosted some feedback on the 10.0 MR that also will apply to the 9.5 MR.
Comment #108
phenaproximaUntagging for an issue summary update, 'cause I did it.
Comment #109
phenaproximaA suggestion for what to do in Drupal 9.4:
If Drupal is running on PHP lower than 8.1, then we should tell them (at REQUIREMENT_INFO severity) to upgrade to PHP 8.1.6 or later. Let's just hard-code that value. I'm not sure we need to append anything. If they ignore our advice and upgrade to 8.1.0 through 8.1.5, they'll get the same warning that we show people on Drupal 9.5 and 10.0.
Thoughts?
Comment #110
phenaproximaLet's get some screenshots up in here.
This is what happens when you use different PHP versions against the existing 9.4.x MR. (As @benjifisher did, I hacked
system.installto change the detected PHP version).PHP 8.1.9 doesn't have any complaints, as you'd expect:
PHP 8.0.3, 7.4.2, and 7.3.1 all passively warn that danger lies ahead:
And PHP 8.1.1 shows the stern warning we'd want:
Comment #111
phenaproximaHere are screenshots for the 9.5.x MR. This is straightforward.
On PHP 8.1.9, there are no complaints, as you'd expect:
On PHP 8.1.1, it complains:
And on all other versions, it doesn't complain, but recommends you go to 8.1.6 (a.k.a.,
\Drupal::RECOMMENDED_PHP):Comment #112
phenaproximaAnd finally, 10.0.x is even more straightforward, since it requires PHP 8.1.0 at a minimum to even boot up.
Here's what happens with PHP 8.1.9 (spoiler: nothing):
And it gets mad with PHP 8.1.1:
Comment #113
xjmLooks like the 10.0.x string has the docs links repeated twice in the last screenshot?
Other than that, this all makes sense. Once the above is fixed I think it's ready for UX review again.
Comment #114
phenaproximaThanks @xjm. Re-tagging for usability review.
Comment #115
phenaproximaComment #116
phenaproximaRe-titling for accuracy.
Comment #117
rkollerI've queued the issue for review at #3304790: Drupal Usability Meeting 2022-08-26 or a future meeting.
Comment #118
phenaproximaAssuming tests pass, I think this is ready for code review.
Comment #119
benjifisherThis observation is out of scope for this issue, but I want to write it down while I am thinking about it. In the "General System Information" section of the status report, there are two links with the text "more information": one under "Last Cron Run" and one under "PHP".
Thanks for adding #3305726: When Drupal::MINIMUM_PHP is 8.1.6 or greater, don't warn about OPcache bug in 8.1.0 through 8.1.5. Maybe we should add a code comment referring to that issue, similar to the comment I quoted in #104.
I see that PHP requirements already has a link to the change record for this issue. Maybe we should add a link on that page to the PHP docs.
My main usability feedback is that "less is more": do we need a link to PHP’s version support documentation? The message will be shorter if we remove that. I see that @xjm commented on the MR,
That makes sense if a site is running on PHP 7 and we want to alert the site owner that it will not be supported much longer. Currently, the link is not helpful for a site running on PHP 8.1.2, but I guess that will change: when 8.0 is close to EOL, the site owner should really upgrade to 8.1.6+ and not downgrade to 8.0.
I think the current text is unambiguous and actionable, and I am glad that we have removed "Note that". I am removing the tag for a usability review. But the current MR for 9.4.x (the only one I have tested today) needs some work. The latest update reverts accidental changes to
default.settings.php, but it makes new accidental changes tocomposer.*.Comment #120
phenaproximaI swear, if I look at the merge request, I am not seeing this. Would you (or someone) be able to revert those changes?
Comment #121
mfbHow is a scenario such as #97 dealt with, if ubuntu LTS were to backport the fix to its php package? The version would be reported as "8.1.2" but it would in fact have various patches applied (security fixes, and apparently bug fixes too).
Comment #122
xjmYep. It's also important because it explains what "recommended" means and caveats with it. The links should always be included if you're on less-than-recommended PHP.
Comment #123
benjifisher@phenaproxima: You are right. It was the previous branch that made those changes, not the current one. Back to NR.
@mfb: I think that is out of scope for this issue. If it actually happens, and we can extract the patch information or the Debian/Ubuntu package version from
phpinfo(), then we can have a follow-up issue to update the check. Even then, I am not sure that it will be worth the added complexity.Comment #124
mfbI couldn't see how to "extract the patch information or the Debian/Ubuntu package version" - it doesn't seem like their php package makes this available, although you would think that it should, e.g. via the "extra" version info. The PHP_VERSION is 8.1.2 and PHP_EXTRA_VERSION is empty string. Anyways, yes they haven't patched it yet so *shrug*
Comment #125
xjmWe can't really handle that case in core as there's no clean API to detect if the bug is fixed or not (plus I am not sure it'd be worth doing). We could add to the CR though if that happens, which is linked to the handbook page.
Comment #126
mullzk commented- @kraut in #97:
- We are on Ubuntu 22.04 and therefor on PHP 8.1.2.
- We experience the bug and can reproduce it on at least two of our Installations of Drupal 9.4.5.
On our site, the impact is quite heavy: Every time, Drupal wants to show an Error (e.g. Error 403
if an unauthorized user accesses the URL /admin), PHP crashes on its autoloader and Drupal produces
an ugly Error 500 instead of the correctly designed Error403-Page.
- Your fix works for us. We installed the PPA and the aformentioned bug does not occur anymore.
Unfortunately a complete Drupal Installation is probably not a very useful bug reproducer to share.
Comment #127
phenaproximaI think all feedback is addressed here. Unassigning from myself for code review.
Comment #128
gambryI reviewed the code, spending a good time to understand all the
elseifs weirdnesses. But all makes sense at the end.The only thing that got me was the nested string as placeholder in 9.4 MR, trying to understand if there were combinations where an empty paragraph could be created. Couldn't fine any, so I think this is good.
I know Bjorn was going to try and spend time tonight reviewing this. Feel free to wait for him.
Thanks all!
Comment #135
lauriiiTested all branches manually and confirmed that the messages made sense in context to the minimum and recommended PHP versions for those branches.
Committed #2649 to 0d091ad and pushed to 10.1.x and cherry-picked to 10.0.x. Committed #2656 to 5ab3f8b and pushed to 9.5.x. Committed #2495 to f20c0a2 and pushed to 9.4.x. Thanks!
Comment #137
kraut commented@mfb @benjifisher @mullzk Thanks for the feedback on Ubuntu. The backported patch is now on it's way to jammy-proposed and the SRU to Ubuntu 22.04 LTS will likely to happen with 8.1.2-1ubuntu2.5. For unreleased Ubuntu 22.10 aka kinetic it was squashed with 8.1.7-1ubuntu1 as import from Debian unstable.
@xjm @lauriii Cherrio :) Understand it's tricky in core and simple version_compare feels clean. But to be fair it's technical in-precise with enterprise distributions and LTS downstreams of PHP. Would be kind to honor PHP LTS efforts if community and vendors like Canonical, Freexian, RedHat and even Microsoft do the heavy lifting of backporting when upstream already said c'est la vie.
Once the bug fix is released via jammy-updates the Drupal warning will be incorrect. Once the next security update ships via jammy-security the bug fix will reach all professional managed Ubuntu 22.04 installs. While we argued to import >= 8.1.6 from Debian unstable it's against the stable release update policy and hence Canonical declined for LTS so the bug will get fixed like usual with a backport.
Comment #138
catch@kraut I've opened a new issue for handling Ubuntu PHP versions at #3307248: Special case Ubuntu PHP versions for some system_requirements() warnings, we've been running into that issue for years, for example in #2670966: Warn users of old PHP versions, but never been able to come up with a satisfactory solution.
Comment #139
benjifisher@kraut:
I do not install PHP with apt, because Homebrew and Docker give me more flexibility. But I do use other utilities:
Of course, Vim is a lot simpler than PHP, and it maintains a simple list of patches between versions. But the point is that it is easy to get the list of patches that have been applied. I do not know how hard it would be to get something like the "Included patches" line added to
php -v.I am not sure what you mean by "Would be kind to honor PHP LTS efforts ...". If what you mean is that there is a way Drupal could take advantage of those efforts to make this warning more accurate, then please explain further. Maybe #3307248: Special case Ubuntu PHP versions for some system_requirements() warnings is the right place to continue that discussion, since this issue is now fixed.
Comment #141
jppo commentedHello,
I am using PHP 8.1.11 and Drupal 8.4.8 and get many kind of error messages when opcache is used.
Yesterday I disable opcache and since 1 day I didn't get any new error messages.
The downside is that the site is significantly less responsive.
Comment #142
cilefen commented@jppo That is a bit mysterious. Would you like to share with the community the text of those error messages? Do so in a new issue with steps to reproduce.
Comment #143
rfmarcelino commentedIn case you landed here because you have this error (missing classes) after upgrading to Ubuntu 22 LTS, and
apt upgradekeeps php 8.1.2, just runsudo add-apt-repository ppa:ondrej/phpand run
apt update && apt upgradeagainComment #144
andypostRe #143 see #3307248: Special case Ubuntu PHP versions for some system_requirements() warnings
Comment #145
berdirI think #143 is not about the status message, it's about the actual error, which I've already mentioned in that other issue, which is just about removing the status message for ubuntu. I'm fairly certain that this problem is _not_ fixed in Ubuntu 22.04, something about that patch does not seem to be working as it should.
Comment #146
bogdog400 commentedI just wanted to make a note of the fact that I had this same problem with 8.1.2-1ubuntu2.13. It went away with rebooting. Now I'm going to try to upgrade to PHP 8.1.6.
Comment #147
bogdog400 commentedIt was fixed when I first rebooted, but it appeared soon after. So I went to trying to upgrade from 8.1.2 and Ubuntu made it difficult. I was able to upgrade, but only after adding this repository:
Apparently Ubuntu is stuck at 8.1.2.