Project

General

Profile

Actions

Bug #85548

closed

Core: Exception after Updating to TYPO3 v8.7.17

Added by Daniel Hasse over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Start date:
2018-07-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

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

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Task #85434: Streamline FAL pre emit signals for createFile and setContent commandsClosed2018-06-29

Actions
Actions #1

Updated by Andreas Kienast over 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?

Actions #2

Updated by Stephan Großberndt over 6 years ago

  • Related to Task #85434: Streamline FAL pre emit signals for createFile and setContent commands added
Actions #3

Updated by Daniel Hasse over 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.

Actions #4

Updated by Michael Schams over 6 years ago

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?

Actions #5

Updated by Denis Mir over 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.

Actions #6

Updated by Andreas Kienast over 6 years ago

How are the affected installations set up? Classic installation or composer-based?

Actions #7

Updated by Denis Mir over 6 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.

Actions #8

Updated by Michael Schams over 6 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.

Actions #9

Updated by Oliver Hader over 6 years ago

  • Target version set to 7.6.31 & 8.7.18 & 9.3.3
  • Is Regression set to Yes
Actions #10

Updated by Oliver Hader over 6 years ago

In order to analyze and identify the reason for that further, please extend your reports and mentions with the following information:
  • 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_src directory)
    • When using Composer, paste the require part for all typo3/cms and/or typo3/cms-* packages in your root composer.json file
  • Does the file in typo3/sysext/core/Classes/Resource/ResourceStorageInterface.php contain the according SIGNAL_PreFileCreate constant in the TYPO3 source directory (either in typo3_src-* or vendor/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

Please also report back, in case the error does not exist on your side anymore.

Thanks in advance for your support!

Actions #11

Updated by Michael Schams over 6 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.

Actions #12

Updated by Daniel Hasse over 6 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.

Actions #13

Updated by Oliver Hader over 6 years ago

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.


Actions #14

Updated by Oliver Hader over 6 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).

Actions

Also available in: Atom PDF