install Joomla 4 as normal
At command line run
php /administrator/index.php
(Believe it or not, People do this. They use it for things like cron jobs in custom extensions etc)
Nothing returned from the request (like Joomla 3)
Notice: Undefined index: HTTP_HOST in /home/joomla4beta1/public_html/libraries/src/Uri/Uri.php on line 103
Warning: session_name(): Cannot change session name when headers already sent in /home/joomla4beta1/public_html/libraries/vendor/joomla/session/src/Storage/NativeStorage.php on line 405
RuntimeException {#184
#message: "Failed to start the session because headers have already been sent by "/home/joomla4beta1/public_html/libraries/src/Uri/Uri.php" at line 103."
#code: 0
#file: "./libraries/vendor/joomla/session/src/Storage/NativeStorage.php"
#line: 473
-previous: RuntimeException {#170
#message: "Failed to start the session because headers have already been sent by "/home/joomla4beta1/public_html/libraries/src/Uri/Uri.php" at line 103."
#code: 0
#file: "./libraries/vendor/joomla/session/src/Storage/NativeStorage.php"
#line: 473
trace: {
./libraries/vendor/joomla/session/src/Storage/NativeStorage.php:473 { …}
./libraries/src/Session/Storage/JoomlaStorage.php:305 {
Joomla\CMS\Session\Storage\JoomlaStorage->start(): void^
›
› parent::start();
›
}
./libraries/vendor/joomla/session/src/Session.php:405 { …}
./libraries/vendor/joomla/session/src/Session.php:332 { …}
./libraries/src/Session/Session.php:201 { …}
./libraries/src/Application/CMSApplication.php:627 { …}
./libraries/src/Application/AdministratorApplication.php:161 { …}
./libraries/src/Application/CMSApplication.php:266 { …}
./administrator/includes/app.php:63 { …}
./administrator/index.php:36 { …}
}
}
trace: {
./libraries/vendor/joomla/session/src/Storage/NativeStorage.php:473 { …}
./libraries/src/Session/Storage/JoomlaStorage.php:305 {
Joomla\CMS\Session\Storage\JoomlaStorage->start(): void^
›
› parent::start();
›
}
./libraries/vendor/joomla/session/src/Session.php:405 { …}
./libraries/vendor/joomla/session/src/Session.php:332 { …}
./libraries/src/Session/Session.php:201 { …}
./libraries/src/Factory.php:339 { …}
./libraries/src/Application/AdministratorApplication.php:228 { …}
./libraries/src/Error/Renderer/HtmlRenderer.php:47 { …}
./libraries/src/Exception/ExceptionHandler.php:128 { …}
./libraries/src/Exception/ExceptionHandler.php:71 { …}
./libraries/src/Application/CMSApplication.php:299 { …}
./administrator/includes/app.php:63 { …}
./administrator/index.php:36 { …}
}
}
PHP 7.4.13 (cli) (built: Dec 23 2020 11:21:05) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.13, Copyright (c), by Zend Technologies
Labels |
Added:
?
|
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-01-08 18:00:29 |
Closed_By | ⇒ | wilsonge |
This is a bug. Joomla should die gracefully at all times and never be outputting notices. I can't find the link but this is literally written as in the development strategy of Joomla !
I am not sure wether to call this a bug, but it certainly has negative consequences...
For example: the "Global configuration" setting "Error reporting" is useful in development. The setting "Maximum" allows you to immediatly see PHP notices and the like, without having to scan through your errorlogs.
But: if set to "Maximum" on a Joomla 4.2.6 site using PHP 8.2, the site immediatly crashes, due to the "Deprecated: Function utf8_decode() is deprecated in .../libraries/vendor/joomla/uri/src/UriHelper.php on line 36" notice (this issue itself has already been discussed), which causes the header to be outputted BEFORE the session is created.
This combination (Joomla 4.2.6 site using PHP 8.2) renders the "error reporting" configuration setting "Maximum" completely useless - as soon as any PHP notice is triggered by the Joomla core or maybe a system plugin...
I ran into this problem, and now have to reset the setting manually in the configuration.php file. Crashing the whole site simply by increasing the "error reporting" to maximum is certainly not a "graceful dead".
I am not sure about the correct path forward (the "utf8_decode()" deprecation notice has to be dealt with anyway soon, as more and more sites will use PHP 8.2).
Hi Ruediger @schultz-it-solutions There is underway ground work to support PHP 8.2.
For instance #39583 has been merged a few days ago. If you want, you can search GitHub for 8.2 and you'll see all PRs that have been created, most of them merged and closed to allow full PHP 8.2 support and prevent the issues you encounter. Thank you for your comments!
For your information, please avoid commenting on closed issues - they are not monitored as actively as open ones. Thank you!
I dont' consider this a bug as per the other 2 issues.