Bug #69619

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

Added by Daniel Wagner over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Extension Manager
Target version:
-
Start date:
2015-09-08
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Problem

After Upgrading to 6.2.15 it is not possible to use important Modules:

  • Extension Manager
  • Languages

Related issues

Related to TYPO3 Core - Feature #70125: Clear code caches automatically if core version changes Rejected 2015-09-26
Related to TYPO3 Core - Bug #55877: Property ListUtility::$objectManager does not exist Closed 2014-02-11
Duplicated by TYPO3 Core - Bug #72705: Exception in Extension Manager about missing property Closed 2016-01-14

History

#1 Updated by Markus Klein over 4 years ago

  • Status changed from New to Needs Feedback

Did you flush all caches in the Install Tool?

#2 Updated by Daniel Wagner over 4 years ago

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")

#3 Updated by Wouter Wolters over 4 years ago

Did you try to restart your webserver?

#4 Updated by Markus Klein over 4 years ago

"all caches" did also involve the opcode cache?

#5 Updated by Daniel Wagner over 4 years ago

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...

#6 Updated by Wouter Wolters over 4 years ago

  • Status changed from Needs Feedback to Closed

your welcome.

#7 Updated by Wouter Wolters over 4 years ago

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

#8 Updated by Nicole Cordes over 4 years ago

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.

#9 Updated by Xavier Perseguers about 4 years ago

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

#10 Updated by Markus Klein about 4 years ago

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

#11 Updated by Daniel Neugebauer about 4 years ago

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?

#12 Updated by Christian Hillebrand about 4 years ago

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.

#13 Updated by Hans-Peter Jacobs about 4 years ago

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

#14 Updated by Markus Klein about 4 years ago

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.

#15 Updated by Daniel Neugebauer about 4 years ago

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...

#16 Updated by Markus Klein about 4 years ago

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

#17 Updated by Deividas Simas about 4 years ago

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

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

#18 Updated by Christian Hillebrand about 4 years ago

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?

#19 Updated by Markus Klein about 4 years ago

@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.

#20 Updated by Markus Klein about 4 years ago

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

#21 Updated by Daniel Neugebauer about 4 years ago

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

#22 Updated by Hans-Peter Jacobs about 4 years ago

@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!

#23 Updated by Markus Klein about 4 years ago

  • Target version deleted (next-patchlevel)

Obviously there must be some issue with the Install Tool not being able to flush your APC cache.

#24 Updated by Christian Hillebrand about 4 years ago

@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?

#25 Updated by Markus Klein about 4 years ago

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.

#26 Updated by Jimit Shah about 4 years ago

Thanks a lot !

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

#27 Updated by Daniel Bachmann over 3 years ago

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.

Also available in: Atom PDF