Problem on Ibexa 3.2 and this bundle

[YohannsMonnier]

Hello @adamwojs ,

We have some problem using this bundle on Ibexa 3.2

1. we have an error on updating solr indexes

php bin/console ezplatform:reindex --siteaccess=test_admin -v
Re-indexing started for search engine: eZ Platform Solr Search Engine

Purging index...
Re-creating index for 39 items across 1 iteration(s), using a single (current) process:
 0/1 [>---------------------------]   0% < 1 sec/< 1 sec22:17:41 ERROR     [console] Error thrown while running command "ezplatform:reindex --siteaccess=test_admin -v". Message: "Call to a member function getLocale() on null" ["exception" => Error { …},"command" => "ezplatform:reindex --siteaccess=test_admin -v","message" => "Call to a member function getLocale() on null"]

In LocaleResolver.php line 39:

  [Error]
  Call to a member function getLocale() on null


Exception trace:
  at /home/site/ezplatform/vendor/excelwebzone/recaptcha-bundle/src/Locale/LocaleResolver.php:39
 EWZ\Bundle\RecaptchaBundle\Locale\LocaleResolver->resolve() 
 at /home/site/ezplatform/vendor/excelwebzone/recaptcha-bundle/src/Form/Type/EWZRecaptchaType.php:47
 EWZ\Bundle\RecaptchaBundle\Form\Type\EWZRecaptchaType->configureOptions() at /home/site/ezplatform/vendor/symfony/form/ResolvedFormType.php:186

2. When we add this field to a form, we can never see the result (ending with a timeout)

Do you think there could be an update needed for Ibexa 3.2 ?

Yohann

[adamwojs]

Thank you for reporting @YohannsMonnier. I will take a closer look on this issue tomorrow and let you know 😉

[YohannsMonnier]

For the Solr Issue, I think it is due to the fact that the form is called in the solr indexer, and this field in the form generate an error because there is no user request , thus no way to get it from the requestStack

return $this->useLocaleFromRequest
            ? $this->requestStack->getCurrentRequest()->getLocale()
            : $this->defaultLocale;

This is generating the error message

[Error] Call to a member function getLocale() on null

[YohannsMonnier]

Dear @adamwojs the 2nd problem was due to proxy settings.

We still have the problem for indexing content that has a form with this Recaptcha Field.

Do you have an idea for a workaround for indexing ?

Yohann

[adamwojs]

Self-note: to reproduce the issue locale_from_request options needs to be enabled e.g.

ewz_recaptcha:
    // ...
    locale_from_request: true

[YohannsMonnier]

@adamwojs if we deactivate "locale_from_request: true" we do not have the reindex bug, but the display in front is not translated to the current langage (here we have french).

Yohann

[adamwojs]

I have some idea how to solve it but I will need some time. You can override ewz recaptcha.locale.resolver definition to

    # FIXME: workaround for https://github.com/adamwojs/ezplatform-form-builder-recaptcha-field/issues/1
    ewz_recaptcha.locale.resolver:
        class: EWZ\Bundle\RecaptchaBundle\Locale\LocaleResolver
        public: false
        arguments:
            - '%ewz_recaptcha.locale_key%'
            - '@=constant("PHP_SAPI") !== "cli" && parameter("ewz_recaptcha.locale_from_request")'
            - '@request_stack'

as very ugly workaround If you are in hurry. Expression passed as second argument will disable using locale from request if current execution env. is CLI

[YohannsMonnier]

@adamwojs

We were in a situation where we needed Recaptcha in production, but in the mean time -> solr indexation was frozen because of this bug

Thank you so much for this quick workaround !

[YohannsMonnier]

Dear Adam, beside from the proposed workaround, do you have any how we could fix this definitely ?

Thank you very much,
Yohann