Bug #100341
closedFlush is not enough for changes in Services.yaml
0%
Description
When Services.yaml has been edited to include new services, a simple flush of all caches in Maintenance->Flush TYPO3 and PHP Cache is not enough to load the edited file. If you want these changes to load properly, it seems that you have to deactivate and reactivate your extension in the Extension Manager. This was observed on v12.3.0. I think there could be at least a mention in the docs, as i haven't found one yet.
Updated by Nikita Hovratov over 1 year ago
Hey, I couldn't reproduce this on the current main branch. This doesn't seem right, there was no such change. Deactivating/reactivating an extension doesn't do so much different than flushing the cache (+ db compare). Could you give an example on how to reproduce this step by step?
Updated by Sebastian Lempik over 1 year ago
Here is a simple Description and if needed i will post a step-by-step on the weekend.
First i would create a extension by making a new folder then adding ext_emconf.php and composer.json. Then i would create my Services.yaml with just the first standard part:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
Then i would setup a new Module by creating a controller and template and adding my definition to Configuration->Backend->Modules.php.
If i then try to load that Module, it won't find the controller as to be expected.
After that i would extend my Services.yaml to the following:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
Example\Example\:
resource: '../Classes/*'
This should then load my controller into the correct namespace. But instead flushing caches goes wrong(shows error) and when i try to access any page, it says that my controller class wasn't found in the file that it obviously is in. To fix this issue i needed to reactivate my extension an then the controller is found correctly.
This was tested on TYPO3 v12.3.0 legacy install.
Updated by Nikita Hovratov over 1 year ago
Did you define PSR-4 autoloading? This seems to be an autoloading error and not a DI cache one. I think on legacy mode extensions are scanned for classes when installed. With PSR-4 autoloading new classes should be found automatically.
Updated by Sebastian Lempik over 1 year ago
Yes autoload was configured in ext_emconf.php like:
'autoload' => [
'psr-4' => [
'Example\\Example\\' => 'Classes',
],
],
Updated by Benni Mack over 1 year ago
FYI: stumbled over the same issue today in a v12.4-dev installation.
Updated by Stefan Froemken over 1 year ago
- Status changed from New to Closed
- Assignee set to Stefan Froemken
Hello everybody,
thank you for that information. I remember that issue. I had it multiple times the last 2 years.
I have started with a minimal composer.json/ext_emconf.php whith does not contain the PSR-4 part. I have setup templates, TypoScript, ext icon and a few hours later I started creating the first controller. Reloading my plugin instantly results in that error in frontend. And yes, flushing the DI cache does not help.
The problem is the AutoLoader.
I have added the few lines for PSR-4 into my composer.json and clear the cache again, but it also does not help. The problem is, that these 3 lines have to be moved into the composer.lock. So please, do following:
- Execute composer dumpautoload
- Visit installtool: There is a button to reload autoloader in standalone installations
- De- and Activate an extension
The AutoLoader is documented here: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Autoloading/Index.html
I will close the ticket now. If you feel this is the wrong decision, let me know, and I will re-open it.
Stefan