v10-compatibility: UnknownClassException for frontend plugin

[marble]

From Slack https://typo3.slack.com/archives/C0CEB3BMY/p1612365935024400

1. Create a fresh TYPO3 v10 with DDEV (as listed on get.typo3.org)
2. Add extension builder: ddev composer require friendsoftypo3/extension-builder:dev-v10-compatibility
3. Create a minimal extension dummy with model Hobby and frontend plugin crud
4. Find the extension attached as dummy.tar.gz
5. Add plugin to page
6. Observe the following error:
7. Attempt to debug: dummy.tar.gz

[DavidBruchmann]

How did you install TYPO3 and the extension inside ddev? If the whole installation is set up with composer, you've to install the extension with composer too and are able to regenerate autoloading with composer dumpautoload. I've the impression that you just enabled the new extension in the Extension Manager while having a composer setup for the instance.

[marble]

I checked once more:

1. that I have composer_version: "2" in .ddev/config.yaml
2. that I ran ddev composer dumpautoload
3. that I've added the TypoScript:

Still no success, but the following situation:

This works:

1. I can create the dummy extension with the extension-builder v10 branch in a DDEV v10 installation
2. I can create the dummy extension with the extension-builder v9.10.3 in a DDEV v9 installation, if I do a ddev composer require nikic/php-parser:4.3.0

This does not work:

1. The frontend plugin for the v10 does not work in the DDEV v10 - see screenshot above, UnknownClassException, weird class name
2. The frontend plugin for the v9 does not work in the DDEV v9 TYPO3 -> UnknownClassException, but correct class name

However, this does work:

1. the extension, generated in a DDEV v10 installation, DOES work normally in a Non-Docker, Non-DDEV v10 installation
2. the extension, generated in a DDEV v9 installation, DOES work normally in a Non-Docker, Non-DDEV v9 installation

Remark

Yes, initially I had forgotten to include the extension's TypoScript in the setup. However, with the Non-Docker installations I got this message which was immediately meaningful to me:

[DavidBruchmann]

the point is this: if you've an extension that has no public repository you've to put it in a folder like packages and tell composer to load it with version @dev. Till now this step is missing in your descriptions, so I doubt if you did it.

In composer.yaml it's looking like this then:

        "require": {
                "lumstuff/dummy": "@dev"
        },
    "repositories": {
        "sitepackage": {
            "type": "path",
            "url": "packages/*"
        }
    },

In the folder public/typo3conf/ext will be a symlink to the extension in packages/dummy

[liayn]

I think this has something to do with the fact that an extension generated in composer-based installation, is not cleanly installed, if it is not required via composer.

I'm actually not even convinced that this a thing we should actually support. Because in composer-installations the content of the typo3conf/ext folder should be completely managed by composer, hence extension_builder should not fiddle around there.

[liayn]

In the folder public/typo3conf/ext will be a symlink to the extension in packages/dummy

correct, only that extension_builder does not know about the packages folder and does/can not manipulate the root composer file.

[DavidBruchmann]

@liayn correct, if autoloading has to be involved, it's a source for many potential errors

[liayn]

@marble Thanks a lot for testing this so thoroughly.

Core v9 ... php-parser:4.3.0

This topic is solved and merged in master.

[DavidBruchmann]

@marble if the setup is like I described related to composer, the extension can be manipulated by extension_builder again to add or change things.
btw. I had a look at all code and never found faults in namespaces, so I think it's related to the autoloading process and composer-setup.

[marble]

How it does work

v10: I followed Davids advice, moved the extension to packages/dummy and added the composer lines suggested by David. With this it is working. Thank you very much.

What lead to the problem?

• I'm not experienced with Composer. I did look at the Composer docs but probably would not have found the solution alone.
• I did not know that, in a fully composer based installation, I should not touch typo3conf/ext/manually. But why then is that the default setting of the extension_builder? It saves the generated extensions there by default. This should not happen and violates the "composer ideas".

Ideas and questions

• Shouldn't the extension_builder generally save generated extensions to a neutral path instead of typo3conf/ext? Should that be a configuration value to be managed by "install tool extension settings"?
• The extension manager in the backend tells me that the installation is fully composer controlled. But why then does it allow to install extensions that are not known to composer?
• Is David's solution for including dev-extensions best practice?
• How can I write the above composer lines as command? That is: ddev composer require "lumstuff/dummy:…" (I'll probably be able to find that out myself, but still, … Is a tool existing that rewrites a composer.json file as list of commands?) → Answer is on this page.
• Is somebody aware of a tutorial-like documentation "How to include your own dev-extension with Composer"?
• In Setting up TYPO3 with DDEV it is stated that the .ddev/config.yaml file needs to be edited manually to set composer_version: "2". Can that be an issue here as well?
• Shouldn't there be an ALARM in the TYPO3 backend, if extensions are found that Composer doesn't know of? Maybe in Environment status?

[DavidBruchmann]

glad that it worked :)
As far as I know it is best practice but I'd be happy getting a confirmation about it - or a better way :)
The basic challenges are:

1. There are 2 ways Typo3 can handle extensions: a) with composer setup b) without composer setup Both options can be used in general, but mixing is not advised if the exceptions where this is working are not known (i.e. sitepackages without php-classes could be loaded just without composer only in extenion-manager).
2. like @liayn pointed out extension_builder never knows about the composer setup, so many possible setups of TYPO3 can't be considered - even the fact only how the folder for local repositories is called.

The command ddev composer require "lumstuff/dummy:…" is correct.

[marble]

2. like @liayn pointed out extension_builder never knows about the composer setup, so many possible setups of TYPO3 can't be considered - even the fact only how the folder for local repositories is called.

Therefore IMHO it shouldn't save to typo3conf/ext/ by default.

BUT, cool, I just noticed that once I have an extension in ./packages I can save the next one there too:

And then extension_builder is helpful:

[liayn]

To answer your points a bit @marble

I'm not experienced with Composer. I did look at the Composer docs but probably would not have found the solution alone.

We are aware of this and we are trying to make this more pleasing.

I did not know that, in a fully composer based installation, I should not touch typo3conf/ext/manually.

I am aware of this as well. The extension_builder can detect that it runs within a composer-based installation and must not write to typo3conf/ext of course. This is a bug!

The extension manager in the backend tells me that the installation is fully composer controlled. But why then does it allow to install extensions that are not known to composer?

Shouldn't there be an ALARM in the TYPO3 backend, if extensions are found that Composer doesn't know of?

The extension manager only enumerates the content of typo3conf/ext and allows for enable/disable an ext. But it does not know how the ext got there. Hence, when composer is stearing things, it can only assume that composer autoloading information is present.

Is David's solution for including dev-extensions best practice?

Yes, it is! There is no other way than "local repositories" besides maintaining an extension totally separated within its own git repository and its own packagist-registration.

it is stated that the .ddev/config.yaml file needs to be edited manually to set composer_version: "2". Can that be an issue here as well?

This probably isn't an issue, but is of course highly recommended to do. Composer 2 is simply way better/faster.

[nicodh]

I suggest to extend the documentation:

[nicodh]

And show a warning in composer mode if no local path repsoitory is configured:

[nicodh]

@ohader what do you think? You implemented the composer path detection and have some experience with people using the extension builder for the first time...

[marble]

I like this idea (extend documentation) very much. I didn't know extension_builder picked the path from composer.json!

[liayn]

Minor improvement: https://github.com/FriendsOfTYPO3/extension_builder/pull/346

[ohader]

Hi folks, what am I supposed to do - what is the specific question (I did read the previous comments, but don't see a clear/dedicated task, yet).

[liayn]

@ohader I think we already had a lot of improvements here, which are not explicitly mentioned here. Maybe we can even already close this one @marble?

[marble]

Yes, let's close this, at least for now. I'm not continuously using the extension builder, but I noticed that you had done something to this, as in a later use I got a warning about what do do in composer mode. Only thing was, afair, that I wasn't actually in composer mode. But it didn't crash, and having this extra warning didn't hurt. But I bookmarked "keep an eye on this" but haven't used it since then. And it would probably another ticket, so let's close this. The main thing is that I got it working. And others can too.