Back to Form Builder Support



We've run into a minor issue recently with the Formbuilder plug-in. When you install the plug-in on an october project, and then include this plug-in in your git repository and then try to run this project on another computer, the Formbuilder will interrupt any artisan command you try to run. It appears this is due to the ReCaptchaServiceProvider being registered in the boot() method of the plug-in. The construct of the ReCaptchaServiceProvider attempts to read a Settings value, but on a new computer the Settings table is not migrated yet. As a result, when you try to run "october:up", October will boot up the plug-in before even running the command. It will attempt to read from the non-existing Settings table, and fail.

We've built a workaround for ourselves that looks like this;

try {
    $key = Settings::get('secret_key');
} catch (\Exception $e) {
$this->reCaptcha = new ReCaptcha($key);

This would be inside the construct of the ReCaptchaServiceProvider. If reading the Settings fails, it will just return and not initialize the ReCaptcha.

Another option could be to use App::runningInConsole() to check if the plug-in is booted while running a console command. In that case the ReCaptcha can probably be skipped.

Last updated


Can confirm this issue is valid not just for new system installs. I am using redis and docker, so CACHE_DRIVER=redis and REDIS_HOST=web_redis. On composer update, the post-update-cmd 'php artisan october:version' fails because this package tries to retrieve the Settings model, and 'web_redis' is unavailable. Therefore all CI/CD pipelines are failing. The above workaround fixes the issue.

1-2 of 2