TYPO3 Core

all ! caches have been cleared manually and with install tool, but it only happens in 2 of 3 tested systems.

Uncaught TYPO3 Exception: Property TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService::$listUtility does not exist

ReflectionException thrown in file /typo3/sysext/extbase/Classes/Reflection/PropertyReflection.php in line 33.

22 ReflectionProperty::__construct(TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService, "listUtility")
21 TYPO3\CMS\Extbase\Reflection\PropertyReflection::__construct(TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService, "listUtility")
20 TYPO3\CMS\Core\Utility\GeneralUtility::instantiateClass("TYPO3\CMS\Extbase\Reflection\PropertyReflection", array)
19 TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance("TYPO3\CMS\Extbase\Reflection\PropertyReflection", TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService, "listUtility")
18 TYPO3\CMS\Extbase\Object\Container\Container::injectDependencies(TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService, TYPO3\CMS\Extbase\Object\Container\ClassInfo)
17 TYPO3\CMS\Extbase\Object\Container\Container::getInstanceInternal("TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService")
16 TYPO3\CMS\Extbase\Object\Container\Container::injectDependencies(TYPO3\CMS\Extensionmanager\Utility\DependencyUtility, TYPO3\CMS\Extbase\Object\Container\ClassInfo)
15 TYPO3\CMS\Extbase\Object\Container\Container::getInstanceInternal("TYPO3\CMS\Extensionmanager\Utility\DependencyUtility")
14 TYPO3\CMS\Extbase\Object\Container\Container::injectDependencies(TYPO3\CMS\Extensionmanager\Utility\InstallUtility, TYPO3\CMS\Extbase\Object\Container\ClassInfo)
13 TYPO3\CMS\Extbase\Object\Container\Container::getInstanceInternal("TYPO3\CMS\Extensionmanager\Utility\InstallUtility")
12 TYPO3\CMS\Extbase\Object\Container\Container::injectDependencies(TYPO3\CMS\Extensionmanager\Utility\ListUtility, TYPO3\CMS\Extbase\Object\Container\ClassInfo)
11 TYPO3\CMS\Extbase\Object\Container\Container::getInstanceInternal("TYPO3\CMS\Extensionmanager\Utility\ListUtility")
10 TYPO3\CMS\Extbase\Object\Container\Container::injectDependencies(TYPO3\CMS\Extensionmanager\Controller\ListController, TYPO3\CMS\Extbase\Object\Container\ClassInfo)
9 TYPO3\CMS\Extbase\Object\Container\Container::getInstanceInternal("TYPO3\CMS\Extensionmanager\Controller\ListController", array)
8 TYPO3\CMS\Extbase\Object\Container\Container::getInstance("TYPO3\CMS\Extensionmanager\Controller\ListController", array)
7 TYPO3\CMS\Extbase\Object\ObjectManager::get("TYPO3\CMS\Extensionmanager\Controller\ListController")

Did you try to restart your webserver?

"all caches" did also involve the opcode cache?

Yes, restarting worked. (I always included opcode cleaning.)

Thank you very much!

Any explanation? Have followed until getClassInfoCache which gets stored in the database. File must have been locked by apache somehow which recreated wrong cache...

Caches are always hard to track down.. no real exaplanation from my side :(

Maybe you are using a memcache?! The error occurs because there is a wrong reflection in the extbase reflection cache which can't be resolved anymore. So you need to flush the extbase cache tables. If there is any caching of the database, you have to make sure to flush those as well.

Getting exactly this problem this morning on a website where EM is usually completely empty (but answers with a HTTP 200). Nothing in the logs.

Oops, an error occurred!

Property TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService::$listUtility does not exist

Attempt 1¶

• Clear system cache (from menu)
• No more error, empty screen (everything else is running properly, including Languages which never gave a problem)

Attempt 2¶

• Install Tool > Important actions
• Clear all cache
• No error, but still empty screen
• Clear PHP opcode cache [OPcache (7.0.3FE)]
• Nothing changes

System¶

• PHP fpm v5.5.9-1ubuntu4.9
• OPcache v7.0.3
• Nginx v1.1.19

Did you clear all caches again after opcode cache has been cleared?

We just had the same issue on 6.2.15 and it doesn't seem to be directly related to PHP's opcache because we are not using it:

# cat /etc/php/apache2-php5.5/php.ini | grep opcache | grep -vE '^;'
[opcache]
opcache.enable=0
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.max_accelerated_files=4000
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=0
opcache.revalidate_path=1
opcache.save_comments=1
opcache.load_comments=1

Of course, restarting the webserver didn't solve the issue for us. Flushing caches via install tool however did.

We only noticed it on one TYPO3 instance so far, others don't seem to be affected.

In case it has anything to do with the way we update: The usual directories are symlinks to typo3_src, typo3_src then symlinks to a shared typo3_src-6.2 symlink. To perform an update we just extract the archive and change the shared typo3_src-6.2 symlink to point to the latest version. Maybe, if there is anything like automated cache clearing after updates (if not, that would be nice to have), it does not trigger if symlinks are chained together 3 times?

For me none of the delete cache methods work for any of my typo3 installations.

Tried deleting cache in backend (clear all caches) and in installtool (important actions => clear all cache). We use database cache so apache restart did not worked either.

I also tried to delete the content if typo3temp.

Nothing worked to get the extensionmanager working again.

The same issue appeared on my typo3-installation when updating to 6.2.15 :(

Sidenote: Switching back to 6.2.14 kept showing the error until the opcode cache was cleared via InstallTool. So the clearing of that cache (and all others) seems to work .... but not for that particular error after updating to 6.2.15?!

OPcache 7.0.4-devFE

We can only recommend those steps to solve the issue:

1. Flush the opcode cache via Install Tool or restart the webserver (or PHP FPM)
2. Clear All Caches via Install Tool

This process should really make sure that there is no cache content left anywhere.

Sorry, but I have to ask: Since working with symlinks is the officially preferred way to update TYPO3 and centralized updates don't seem that uncommon, why doesn't TYPO3 simply detect that it has been updated and automatically clears all required code caches? It should be easy enough to store the current version number in index.php by distribution and the last used one in LocalConfiguration. If there's a mismatch (no need to check for up-/downgrades or specific versions, having a mismatch is enough), TYPO3 should flush all code & config caches and update the number in LocalConfiguration. Such a simple comparison wouldn't impact performance at all as those files are loaded and processed anyway.

As this issue shows, if there is no such mechanism yet, it would be great to have one. Please confirm that there really is none and I will gladly open a feature request myself.

Sorry if that sounded a bit harsh but when using TYPO3 4.x we never had such issues. The aggressive code caching in TYPO3 6.x can drive you slightly mad, however, and introducing automatic cache clearing on core updates would at least ease updating across TYPO3 bugfix releases which shouldn't usually trigger such issues. Still doesn't solve having to clear each and every more or less hidden cache in TYPO3 when installing extensions, writing extensions or just plain templates but it's a start...

Hi Daniel!

There is no such feature yet, you're right. There is even a better way to achieve this, by simply adding the version number to the cache identifiers. This way you don't even need to store the current version number.

The opcode cache is a different story though, which causes issues that can't be solved from within the application. Mostly this involves issues, where the opcode cache does not realize that there is new PHP source to parse, hence it keeps delivering the old code. No matter what you do in your PHP app, you'll never get a hint that a new source is actually already present. That's the reason why you have to manually flush the opcode cache, either by server/fpm restart or via Install Tool (sourced from the old source), to eventually get the new source running, which you can finally use to flush the TYPO3 caches.

Feel free to open any feature request, but it would be even better if you could contribute the feature. ;-)

Cheers, Markus

Definetly cache related, happened after updating typo3 (with composer).

Deleted all caches, including typo3temp folder without success.
Truncating `tx_extensionmanager_domain_model_extension` helped.

I still did not found any working solution to activate the extensionmanager in all my projects.

On some projects it worked direclty with the first try but on others i can try to delete any caches as often as i want but nothing changes on the extensionmanager.

Do you have any other ideas to get it back working?

@Deividas: That's exactly the reason why we do NOT recommend to flush caches manually.
Either use the Install Tool "clear all cache" button (which takes care of all Cache-Backends, whereever those are stored), or install the typo3_console extension, which allows to flush the cache from commandline in a reliable way.

@Christian: Do you use APC as cache backend? (Install Tool -> Configuration Preset -> Extbase object cache)

Added a feature request for this, #70125: "Clear code caches automatically if core version changes"

@Markus Klein: APC was a great hint!

I just switched (using the install tool) from APC to "Database cache backend", cleaned all the caches (incl. opcode) and toggled APC back on. Now the installation runs fine, no more problems with the extension-manager.

Not sure what happened and whether those steps were truly the fix, but now it works again :)

Thank you!

@Markus, Nope, as i wrote in an earlier post, we use the database cache.

Should i try to truncate tx_extensionmanager_domain_model_extension too?

tx_extensionmanager_domain_model_extension just holds the list of extensions, so this is totally unrelated.

If you use the DB-Cache, please try one thing: Clear all cache with the button in Install Tool and look into the DB then if the cf_..._reflection table is empty.

Thanks a lot !

with clear the install tool cache , i resolved this error.

I had the same problem some minutes ago. I cleared all caches but that changed nothing...

I resolved this error by truncating all cf_ tables in the database.