Bug #85548
closed
Core: Exception after Updating to TYPO3 v8.7.17
Added by Daniel Hasse almost 6 years ago. Updated over 5 years ago.
0%
Description
Hello everyone,
i got a TYPO3 v8.7.16 installation.
Due to this https://typo3.org/security/advisory/typo3-core-sa-2018-003/ report i updated to TYPO3 v8.7.17.
After updating i got this error:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Undefined class constant 'SIGNAL_PreFileCreate' | Error thrown in file ../typo3_src-8.7.17/typo3/sysext/form/ext_localconf.php in line 113. Requested URL: https://example.com/typo3/index.php?M=system_BelogLog&moduleToken=[TOKEN]
The error shows up an different spots in backend e.g. if i click in filelist->fileadmin on a file or over the page->pagetree if I want to edit/click sth.
I think it's kind of the same like here?
https://forge.typo3.org/issues/85434
Files
| screenshot0001.png (19 KB) screenshot0001.png | Michael Schams, 2018-07-15 03:23 | ||
| clear_opcache.png (223 KB) clear_opcache.png | Oliver Hader, 2018-07-27 13:54 |
Updated by Andreas Kienast almost 6 years ago
- Status changed from New to Needs Feedback
Hello, thanks for your report.
I just took a look into the code, the mentioned constant is properly defined. Did you clear the opcode caches of PHP after updating TYPO3?
Do you by chance have some kind of a mixed state, like a load-balancing cluster with nodes that are not synched?
Updated by Stephan Großberndt almost 6 years ago
- Related to Task #85434: Streamline FAL pre emit signals for createFile and setContent commands added
Updated by Daniel Hasse almost 6 years ago
Yes all caches were cleared, including opcode cache, even typo3temp-folder was cleared.
Do you by chance have some kind of a mixed state, like a load-balancing cluster with nodes that are not synched?
-> No there is no mixed state or sth. like this active.
I reproduced it in 4 installations.
Curious thing about the extension form:
By deactivating the extension "form" the bug is gone.
Even if i don't have any form created by the form extension on my site, the bug shows up.
The extension form just has to be installed and active.
After deactivating the form extension, it seems like that the bug is gone.
Updated by Michael Schams almost 6 years ago
- File screenshot0001.png screenshot0001.png added
I can confirm we are experiencing the issue, too.
Deactivating EXT:form makes the BE accessible again. Re-enabling the extension generates the error again.
It looks like, the problem does not occur straight away after re-enabling EXT:form. Maybe related to caching or so?
Updated by Denis Mir almost 6 years ago
- Priority changed from Should have to Must have
We can confirm the error as well on all our 8.7 LTS installations. The error did occur after the 8.7.17 update and we stopped rolling out the update to our customers.
Updated by Andreas Kienast over 5 years ago
How are the affected installations set up? Classic installation or composer-based?
Updated by Denis Mir over 5 years ago
All of our affected installations are composer based. After updating to 8.7.17 the frontend and backend show the error "Core: Exception handler (WEB): Uncaught TYPO3 Exception: Undefined class constant ‘SIGNAL_PreFileCreate’".
Entering the install tool is possible but trying to delete the cache also triggers "Core: Exception handler (WEB): Uncaught TYPO3 Exception: Undefined class constant ‘SIGNAL_PreFileCreate’".
When checking the extensions in the install tool the install tool does show "forms" as unsupported extension and offers to uninstall the extension. When trying to uninstall the extension the exception shows up again. After manually editing the PackageStates.php removing the "forms" extension, the error is gone. If you need more feedback you can also drop me a message on the slack channel.
Updated by Michael Schams over 5 years ago
We experienced this issue on two instances, both classic setup.
I did the same: EXT:form manually removed from PackageStates.php. Then opened Extension Manager, made sure EXT:form is disabled (in both instances, we don't use forms).
A few days later, I re-enabled EXT:form via the Extension Manager (just as a test) and this seem to work, too.
Updated by Oliver Hader over 5 years ago
- Target version set to 7.6.31 & 8.7.18 & 9.3.3
- Is Regression set to Yes
Updated by Oliver Hader over 5 years ago
- PHP version being used
- Is PHP opcache enabled or disabled?
- Is the installation based on Composer or using a classic tar.gz/zip package (
typo3_srcdirectory)- When using Composer, paste the
requirepart for alltypo3/cmsand/ortypo3/cms-*packages in your rootcomposer.jsonfile
- When using Composer, paste the
- Does the file in
typo3/sysext/core/Classes/Resource/ResourceStorageInterface.phpcontain the accordingSIGNAL_PreFileCreateconstant in the TYPO3 source directory (either intypo3_src-*orvendor/typo3/cms/)?
The current assumption is, that after having updated the source files (either by using tar.gz/zip packages or Composer packages) the PHP opcache is not up-to-date. In order to clear PHP opcache, it's is possible to
- either gracefully restart the webserver (for mod_php and fcgid/fpm)
- or use a tool like http://gordalina.github.io/cachetool/ to purge caches - e.g.
php cachetool.phar opcache:reset
Please also report back, in case the error does not exist on your side anymore.
Thanks in advance for your support!
Updated by Michael Schams over 5 years ago
PHP version used: PHP 7.0.30-0+deb9u1 (however, at the time of the TYPO3 update it could also be 7.0.27-0+deb9u1).
PHP opcache is enabled.
Installation uses classic setup.
# grep -n "PreFileCreate" typo3/sysext/core/Classes/Resource/ResourceStorageInterface.php 25: const SIGNAL_PreFileCreate = 'preFileCreate';
I can't be 100% sure, but I doubt that the web server has been restarted (or the PHP opcache cleared forcibly) as part of our TYPO3 update process.
Updated by Daniel Hasse over 5 years ago
PHP Version: PHP 7.1.14
PHP opcache: enabled
Installation: classic setup
Does the file in typo3/sysext/core/Classes/Resource/ResourceStorageInterface.php contain the according SIGNAL_PreFileCreate constant?
Yes it does at line 25: const SIGNAL_PreFileCreate = 'preFileCreate';
We didn't restart our webserver or used a tool for purging caches.
Updated by Oliver Hader over 5 years ago
- File clear_opcache.png clear_opcache.png added
Thanks for your response. Depending on the PHP configuration, it is suggested to manually clearing OPcache using the install tool - see the following screenshot further down.
Besides that it probably might make sense to check/adjust those PHP runtime settings:
- opcache.validate_timestamps
- opcache.revalidate_freq
In case revalidation is disabled, it's obvious that server admin has to take care of invalidation manually.
Updated by Oliver Hader over 5 years ago
- Status changed from Needs Feedback to Closed
I've verified that packages and source are correct (same as reporters did, the constant that could not be determined actually was present in the source files). Thus, there is no misbehavior caused by the application layer (TYPO3) but some that orginated from optimizing PHP code interpretation (OPcache).
I'm closing this issue since it can be solved by manually clearing the "OPcache" in the install tool or adjusting PHP opcache.* settings (or restarting the webserver as last resort).