[#36171] - [4.0.5 rc1][PHP 8.1.0]Website unusable when error reporting set to 'Maximum'
- Closed
- 12 Dec 2021
- Urgent
- Build: 4.0.5 rc1
- # 36171
Steps to reproduce the issue
Set PHP 8.1.0 to ignore Deprecated messages: error_reporting = E_ALL & ~E_DEPRECATED
Install Joomla 4.0.5 rc1.
Change error reporting to 'Maximum' in Global Configuration.
Expected result
No errors displayed.
Actual result
Numerous Deprecated errors make both the back end and front end unusable.
If 4.0.5 does not support PHP 8.1, it should be highlighted or at least mentioned in the release document and installation instructions.
It should not be necessary to tweak the PHP default level of error reporting by having to filter E_DEPRECATED messages, which setting is overridden by the selection of 'Maximum'. As an alternative, could the behaviour of the selection 'Maximum' be changed so that the filtering of E_DEPRECATED messages is left unchanged: E_ALL & ~E_DEPRECATED will then make the website function normally.
System information (as much as possible)
Windows 10, Wampserver 3.2.6, Apache 2.4.51, MySQL 8.0.27, PHP 8.1.0
Additional comments
Examples of Deprecated messages:
Deprecated: Return type of Joomla\Event\ListenersPriorityQueue::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\event\src\ListenersPriorityQueue.php on line 137
Deprecated: Return type of Joomla\Event\ListenersPriorityQueue::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\event\src\ListenersPriorityQueue.php on line 149
Deprecated: Return type of Joomla\Registry\Registry::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\registry\src\Registry.php on line 117
Deprecated: Return type of Joomla\Registry\Registry::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\registry\src\Registry.php on line 394
Deprecated: Return type of Joomla\Event\ListenersPriorityQueue::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\event\src\ListenersPriorityQueue.php on line 149
Deprecated: Return type of Joomla\Registry\Registry::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in C:\www\joomla4test\libraries\vendor\joomla\registry\src\Registry.php on line 117
RuntimeException
Failed to start the session because headers have already been sent by "C:\www\joomla4test\libraries\vendor\joomla\event\src\ListenersPriorityQueue.php" at line 17.
Votes
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
The explanation makes sense but does not fix the usability issue. Our standard advice to forum members asking for support is to change the level of error reporting 'Maximum' and turn on the Debug option. The browser is then flooded with Deprecated messages, which defeats the purpose. We should not have to ask Joomla webmasters to tweak the php.ini settings, which they may not be able to access, or ask their host for changes, which may not be possible in shared servers.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36171.
The browser is then flooded with Deprecated messages, which defeats the purpose.
That's the least problem.
When the user selects maximum and hit the save button, the site crashes, and the only way to get it running is to change the PHP version on the server or manually edit configuration.php
@frostmakk You can access your webserver e.g. with ftp or ssh access and change the setting $error_reporting back to 'default', then the site will work again.
Update: Ah, just when I had typed I saw you already mentioned the manual edit.
Yes, for the people frequenting this repository it's a no brainer, but for a lot of the regular users this could be a nasty trap.
Security experts recommend that production sites have the level of error reporting set to 'none' to stop critical information from leaking. Regular users do not normally have access to configure the directive error_reporting in php.ini. Therefore they are dependent on the value of the variable $error_reporting in the file configuration.php, which can filter all those Deprecated messages if the setting is 'none' or 'simple'.
In a scenario where we try to advice a regular user remotely to debug the website, the option 'simple' in $error_reporting filters Deprecated messages but also Notices and Strict messages, reporting only E_ERROR, E_WARNING and E_PARSE messages. In fact, the setting 'simple' may be sufficient in many cases to regular users. If that is not sufficient, we can always recommend the website to be backed up and restored to a localhost site for further debugging and detailed analysis of error messages and configure the error_reporting option in php.ini as E_ALL & ~E_DEPRECATED.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36171.
It's a problem for developement purpose because in this case you need to set $error_reporting to maximum
Definitely the remedy is worse than the disease. I have tried version 4.05rc3 and Php 8.1 and the first big problem is being without even access to the backend by having the error report configuration in Maximum
The fix which was done is just to be able to use J!4.0.x in production on Php 8.1, there is this fix in PR : #36248
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-12-12 12:23:12 |
| Closed_By | ⇒ | alikon |
see the explanation #36041 (comment)