Bug #20056
closed
Error messages block TYPO3 4.2
0%
Description
When error messages are printed, e.g. in the Extension Manager, TYPO3 4.2 overwrites the menu such that no other methods can be invoked. In 4.1 the error messages were on top without overwriting the menu. So 4.2 may not be used when a warning occurs.
As an example, you can check the backend of http://nctest.netcos.de/typo3 with admin user "bug" and password "typo3".
(issue imported from #M10495)
Updated by Bernd Warken almost 16 years ago
This is a very dangerous event. PHP warnings can occur at many situations. Then the Extension Manager in the backend cannot be used any more. So it is better to keep 4.1 installed until the overwriting bug of warnings and error messages is fixed again.
Updated by Christian Kuhn over 15 years ago
Updated by Bernd Warken over 15 years ago
Thank you for your information of related issues.
But they are about about debug output, which can be resolved with extension cc_debug.
My issue is on PHP error messages and warnings that overwrite the backend menus in TYPO3 4.2, but not in 4.1. This has not been fixed in the other bug reports.
The trouble can be provided by rearranging the error output into a log file - I used /var/log/phperr.log, you are free to choose another place. This can be done with php.ini:
display_errors = Off
log_errors = On
error_log = /var/log/phperr.log
But this disables the direct display of errors in all PHP programs, including all TYPO3 sites. That might be bad in some situations.
So TYPO3 4.2 has to be fixed in order to remove this overwriting bug. You could just reimplement the situation in 4.1. So this should not be too hard. Moreover all errors could be redirected into a popup-window like cc_debug.does for debugging output.
So I think that this bug report is not yet finished.
Updated by Christian Kuhn over 15 years ago
Hey Bernd,
I think #18220 is exactly the same issue you described: The docheader is below any (php) error and thus the icons can not be clicked. Do you agree? This makes the backend partly unusable if php error reporting is not disabled, which might not be a solution in all cases.
I agree that this issue is awful and that it should be fixed. Both #18220 and #18220 already have different patches applied, and both issues are pending in core list (thats why I do not close one of them as a duplicate), but they have not been accepted there because there are still problems with the patches. You could help by testing and improving them.
The thing is: If you agree that your issue is the same as in #18220, I would like to close this here again, to not clutter the bugtracker with open duplicates and to concentrate any discussions in as little places as possible.
Updated by