search

evoWeb / recaptcha

TYPO3 Extension to make use of googles nocaptcha
GNU General Public License v2.0
6 stars 18 forks source link

Used extension is not required in composer.json and therefore not installed #83

Closed torben-fr closed 3 months ago

torben-fr commented 3 months ago

In the file evoweb/recaptcha/Classes/Adapter/SfRegisterAdapter.php come classes of the SfRegister extension are used. The extension itself is not installed on my system because it is not needed. If the classes are used in this file the SfRegister extension should be required by the Recaptcha extension

garbast commented 3 months ago

Sorry, but i total disagree. It is an adapter to enable the usage of the captcha in sf_register. If you don't need it on your system, just ignore the adapter file. If you feel like you can't ignore it, just don't use this extension.

torben-fr commented 3 months ago

Okay let me explain the issue once again. TYPO3 is not working at all. This is not just a minor issue and you can't just ignore it.If you are using classes of the sf_register extension in the recaptcha extension TYPO3 can't load the classes cause they are nowhere to be found.

The issue is occurring in recaptcha v13, which in packagist is labeled as TYPO3 v12 compatible. It seems like in recaptcha v12 everything is working correctly. Nonetheless you should either update the information in packagist or fix the issue in the v13 version.

In my TYPO3 v12 instance with the recaptcha v13 I can't access the backend cause of the following error, nor can I run a cache flush due to impossible dependency injection with this class. I would appreciate if you can give me any feedback on what you are gonna do. Untitled

tim-baecker commented 3 months ago

Can confirm this - using TYPO3 12 and this Extension in version 13.0.1 I'm getting the error above.

torben-fr commented 3 months ago

@garbast As this is a problem just like @tim-baecker confirmed, please re-open the issue. Thank you.

garbast commented 3 months ago

So i found the reason about this problem. With version 13.x i tried some performance improvements by autowire false, autoconfigure false and define every service in the Services.yaml. This causes the DI to search for the AbstractAdapter. Why this is not a problem when autowire true and autoconfigure true is set, is irritating to say the least.

I will change the Services.yaml back to use autowire to prevent the provided error.

On that note. It would have been better to provide the problem in the first place. Only telling that some classes uses an other class doesn't make aware of why this is an issue.

torben-fr commented 3 months ago

Fair enough. :)

garbast commented 3 months ago

Release 13.0.2 should fix the problem. Please come back if you still experience this problem.