Fatal error when executing simple actions on custom administrative subthemes (such as Adminimal)

As always: please provide steps to reproduce, best on a clean install, there are 1000s of possible config options and other modules or themes you may have installed and we have no idea about, that can cause such an issue.

Possible, but it may still be something that should be fixed in VBO, you never know until the actual cause is found.

I am getting the same error. It seems to only happen when I add an exposed filter that is a taxonomy term.

Reopening until we know what's the cause of the issue and how to address it, external or not.

I can confirm the same issue using adminimal as admin theme.

I tried to put vbo operations in core view /admin/content and with adminimal, the batch fails, with bartik works ok.

For those who are confirming having this exact problem. Is it the same file? "twig_init('css/core/dialog/off-canvas.layout.css')" in the error output?

adminimal_theme extends from seven and most every theme in core and contrib extends from classy.

This is the error I get

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to twig_init() must be an instance of Drupal\Core\Extension\Extension, array given in twig_init() (line 34 of core/themes/engines/twig/twig.engine).

twig_init(Array)
call_user_func('twig_init', Array) (Line: 144)
Drupal\Core\Theme\ThemeInitialization->loadActiveTheme(Object) (Line: 74)
Drupal\Core\Theme\ThemeInitialization->initTheme('adminimal_theme') (Line: 406)
Drupal\Core\Theme\ThemeManager->initTheme(Object) (Line: 96)
Drupal\Core\Theme\ThemeManager->getActiveTheme() (Line: 74)
Drupal\Core\Render\ElementInfoManager->getInfo('form') (Line: 806)
Drupal\Core\Form\FormBuilder->prepareForm('views_exposed_form', Array, Object) (Line: 272)
Drupal\Core\Form\FormBuilder->buildForm('views_exposed_form', Object) (Line: 135)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1235)
Drupal\views\ViewExecutable->build('page_3') (Line: 1388)
Drupal\views\ViewExecutable->execute('page_3') (Line: 2537)
Drupal\views\ViewExecutable->__wakeup()

Getting the same error here, removing the exposed filter seems to fix it (also makes my view useless).

Just tried to execute a VBO operation using adminimal and still can't reproduce the problem.

I've been encountering this issue in our D8 sites, and I've been able to reproduce on a clean install. To reproduce:

1. Install Drupal 8.5.3.
2. Install views_bulk_operations and adminimal_theme.
3. Create a handful of content nodes, such as with devel_generate.
4. Update the Content view to use the Views Bulk Operations field with the Publish selected content, Save content, and Unpublish selected content actions.
5. Go to /admin/content, select several nodes, and attempt to unpublish them with Views Bulk Operations.

Log message for the whitescreen that triggers for me. In my case, my vagrant box has the Drupal install in /var/www/docroot. It's also worth noting that I'm running this on Scotchbox 2.5 (which still uses PHP 5.6), but my composer config has accounted for that with a php version config setting.

Location: http://drupal.test/batch?id=3&op=start

Referrer: http://drupal.test/admin/content

Message:

Recoverable fatal error: Argument 1 passed to twig_init() must be an instance of Drupal\Core\Extension\Extension, array given in twig_init() (line 34 of /var/www/docroot/core/themes/engines/twig/twig.engine) #0 /var/www/docroot/core/includes/bootstrap.inc(582): _drupal_error_handler_real(4096, 'Argument 1 pass...', '/var/www/docroo...', 34, Array) #1 /var/www/docroot/core/themes/engines/twig/twig.engine(34): _drupal_error_handler(4096, 'Argument 1 pass...', '/var/www/docroo...', 34, Array) #2 [internal function]: twig_init(Array) #3 /var/www/docroot/core/lib/Drupal/Core/Theme/ThemeInitialization.php(144): call_user_func('twig_init', Array) #4 /var/www/docroot/core/lib/Drupal/Core/Theme/ThemeInitialization.php(74): Drupal\Core\Theme\ThemeInitialization->loadActiveTheme(Object(Drupal\Core\Theme\ActiveTheme)) #5 /var/www/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(406): Drupal\Core\Theme\ThemeInitialization->initTheme('adminimal_theme') #6 /var/www/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(96): Drupal\Core\Theme\ThemeManager->initTheme(NULL) #7 /var/www/docroot/core/lib/Drupal/Core/Render/ElementInfoManager.php(74): Drupal\Core\Theme\ThemeManager->getActiveTheme() #8 /var/www/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(806): Drupal\Core\Render\ElementInfoManager->getInfo('form') #9 /var/www/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(272): Drupal\Core\Form\FormBuilder->prepareForm('views_exposed_f...', Array, Object(Drupal\Core\Form\FormState)) #10 /var/www/docroot/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php(135): Drupal\Core\Form\FormBuilder->buildForm('\\Drupal\\views\\F...', Object(Drupal\Core\Form\FormState)) #11 /var/www/docroot/core/modules/views/src/ViewExecutable.php(1235): Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() #12 /var/www/docroot/core/modules/views/src/ViewExecutable.php(1388): Drupal\views\ViewExecutable->build('page_1') #13 /var/www/docroot/core/modules/views/src/ViewExecutable.php(2537): Drupal\views\ViewExecutable->execute('page_1') #14 [internal function]: Drupal\views\ViewExecutable->__wakeup() #15 /var/www/docroot/core/lib/Drupal/Core/Batch/BatchStorage.php(71): unserialize('a:12:{s:4:"sets...') #16 /var/www/docroot/core/lib/Drupal/Core/ProxyClass/Batch/BatchStorage.php(75): Drupal\Core\Batch\BatchStorage->load('3') #17 /var/www/docroot/core/includes/batch.inc(43): Drupal\Core\ProxyClass\Batch\BatchStorage->load('3') #18 /var/www/docroot/core/modules/system/src/Controller/BatchController.php(55): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #19 [internal function]: Drupal\system\Controller\BatchController->batchPage(Object(Symfony\Component\HttpFoundation\Request)) #20 /var/www/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #21 /var/www/docroot/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #22 /var/www/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #23 /var/www/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #24 [internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #25 /var/www/vendor/symfony/http-kernel/HttpKernel.php(151): call_user_func_array(Object(Closure), Array) #26 /var/www/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #27 /var/www/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28 /var/www/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #29 /var/www/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #30 /var/www/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #31 /var/www/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #32 /var/www/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #33 /var/www/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #34 /var/www/docroot/core/lib/Drupal/Core/DrupalKernel.php(664): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #35 /var/www/docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #36 {main}.

Ok, reproduced. Worth adding that the problem only occurs with actions that have no confirm and/or config step implemented.

The passed extension is exactly:

$variable array(1)
  →'css' => array(1)
    →'theme' => array(1)
      'css/block.admin.css' => string(25) "css/block/block.admin.css"

.. and that in turn is defined in:

/core/themes/stable/stable.info.yml

libraries-override:
  block/drupal.block.admin:
    css:
      theme:
        css/block.admin.css: css/block/block.admin.css

This forum post points to APC as the source of the problem. Could it be the same issue?

To reproduce the issue:

1. Create some nodes in the site
2. Download and enable the adminimal theme
3. Create a nodes view page
4. Add Global: Views bulk operations with Save content action
5. Add an exposed filter (eg. Content: ID (exposed) )

I am running php 7.0.24.

Visit the view page in the frontend and try to execute the action.

The following error is displayed:

[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: PHP message: TypeError: Argument 1 passed to twig_init() must be an instance of Drupal\\Core\\Extension\\Extension, array given in /var/www/web/core/themes/engines/twig/twig.engine on line 34 #0 [internal function]: twig_init(Array), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #1 /var/www/web/core/lib/Drupal/Core/Theme/ThemeInitialization.php(144): call_user_func('twig_init', Array), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #2 /var/www/web/core/lib/Drupal/Core/Theme/ThemeInitialization.php(74): Drupal\\Core\\Theme\\ThemeInitialization->loadActiveTheme(Object(Drupal\\Core\\Theme\\ActiveTheme)), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #3 /var/www/web/core/lib/Drupal/Core/Theme/ThemeManager.php(406): Drupal\\Core\\Theme\\ThemeInitialization->initTheme('adminimal_theme'), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #4 /var/www/web/core/lib/Drupal/Core/Theme/ThemeManager.php(96): Drupal\\Core\\Theme\\ThemeManager->initTheme(Object(Drupal\\Core\\Routing\\RouteMatch)), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #5 /var/www/web/core/lib/Drupal/Core/Render/ElementInfoManager.php(74): Drupal\\Core\\Theme\\ThemeManager->getActiveTheme(), referer: http://gsk-crm.test/en/test
[Tue Jun 12 13:41:09 2018] [error] [client 127.0.0.1] FastCGI: server "/php-fpm" stderr: #6 /var/ww..., referer: http://gsk-crm.test/en/test

Edited the comment with some extra info about theming

Is there a corresponding issue on Adminimal project?

Additional info to delimit the issue:

• I have found the issue using a custom subtheme of Seven (like Adminimal is).
• If Seven is selected as the admin theme, the issue cannot be reproduced, the batch operations works fine.
• A workaround to avoid the issue using a custom subtheme of Seven is to disable 'Process in a batch operation' option.

Hope it helps.

I have the exact same issue described above, but i don't use Views Bulk Operations. So the problem has to be somewhere else.

I use a views reference field inside a paragraph, and the view is displayed in the backend then inside the paragrah. When i try to save the node, the error in the issue description happens.

- I use Adminimal (as described above, the error does not happen when i switch to seven for example)
- The view has an exposed filter for a taxonomy term

During a quick debugging I noticed that the issue can be reproduced only for simple actions without configuration (confirmation) step. Just for testing purposes I added an empty `buildConfigurationForm` method to the few simple actions (like block/unblock users) and everything worked without errors.

So I created a patch with workaround that shows confirmation step for every action, which isn’t a bad idea in general, but I think it requires an additional discussion.

Patch works well in my case, but I didn’t test it for all possible cases, so use it on your own risk.
Hope it will help someone or can be used as an idea for more robust solution.

I think the workaround in #23 is good enough as a temp fix. Maybe this could be added to the module with a @todo to remove that again when we find a proper fix?

Yes, that is a good suggestion, but it'd be good if we had at least a blocking issue to address before this issue is fixed and the patch can be reverted, otherwise the "temporary" fix will stay there forever because we'll have no knowledge the bug was actually fixed by something.

In the meanwhile, patch review:

There's a route to execute an operation available, so there's no need to enforce a confirmation step if not configured: views_bulk_operations.execute_batch, it can be used in such a case.

Thanks!

Adding the related Drupal Core issue.

Quick patch, please test. Looks like we're back to always redirecting due to another core issue :/

Right, the controller needed an update for non-batch case.

I finally updated from VBO 8.x-1.0-beta4 to 8.x-2.4, and I ran into this issue while testing my (very simple) custom actions. Thanks to all for making my job easy!

The problem goes away after I apply the patch in #29. I consider this (not reviewed, but) tested by the community.

Pushed the last patch, setting this to postponed so we can watch the related issue and hopefully get rid of the workaround.

Hi! Thanks for a patch! It fixes error, but I've received another.
After submission of form the batch doesn't work and page is redirected to wrong path http://mysite.local/views-bulk-operations/confirm/test_view/page_1
I tried patch with 8.x-2.4 and tried to use last dev version. The result is the same.

I've tried default 'Publish selected content' and 'Unpublish selected content' actions and have the same behavior.

What I've missed to check in settings or in code of custom action?

I use relations with groups in custom view.

I've tried to create new simple view and default actions works. I'll check if relations with groups are source of problem.

I've found source of problem but I don't know hot to fix it yet.
I have settings "Access:Group permission | Access group node overview" in views and it breaks batch.
Any ideas how to fix it?

I've found that ViewsBulkOperationsAccess::access returns AccessResult::forbidden() and it's for user '1'.

$view->access($parameters['display_id'], $account) returns FALSE, because GroupPermission object doesn't receive group object from contexts.

Is there a way to provide context from current views for route 'views_bulk_operations.execute_batch'?

For now I've found only one solution to comment/remove line with '$redirect_route = 'views_bulk_operations.execute_batch';', but with exposed filter in view I receive again "Argument 1 passed to twig_init() must be an instance of " (((

Patch from https://www.drupal.org/project/drupal/issues/2701829#comment-12613145 helped me for VBO 8.x-2.4 without patch from current issue.

If using 'confirm = TRUE' in custom plugin's annotations and group persmission in view's settings, we have also access error on 'views_bulk_operations.confirm' route.

The patch in #29 resolved the issue for me on a custom administrative theme that was based off of Seven. I did not run into the issues described in #33. It looks like this hasn't made it to a stable release yet.

Bump, I see we are pending this on something. But it isn't clear what or when this can be unpostponed.

Well, the related core issue is solved so we can change the status. I'll set this to active so others that experience the problem can investigate if needed.

@ivnish:

Can you explain why you moved this issue to Fixed?

For example, if you tested and the problem is no longer reproducible, then please say so, and give some detail about how you tested. (In this case, it might be better to change the status to "Closer (outdated)" instead of Fixed.)

@benjifisher

1. There is commit #31
2. Core patch #38 was fixed. See comment #37

From Comment #32:

Pushed the last patch, setting this to postponed so we can watch the related issue and hopefully get rid of the workaround.

I think the point of keeping this issue open is to test whether the problem goes away after #2701829: Extension objects should not implement \Serializable was fixed. Drupal 8.6.8 was the first version to include the fix for that issue.

I tested this issue with various old versions:

• PHP 7.2
• Composer 1
• Drupal 8.6.7 and 8.6.8
• views_bulk_operations 8.x-2.4 and 8.x-2.5
• adminimal_theme 8.x-1.5
• Drush 9.7.3

I pretty much followed the steps to reproduce from Comment #13, with a few changes. I installed the Umami demo profile so that there were already some nodes for testing. Instead of changing the view for /admin/content/, I added a new Page display at /admin/content-vbo. To clarify: I removed the existing (core) bulk operations field and added the one from VBO.

• With Drupal 8.6.7 and VBO 8.x-2.4, I reproduced the problem.
• With Drupal 8.6.7 and VBO 8.x-2.5, I could not reproduce the
  problem. But the bulk action failed: Access denied.
• With Drupal 8.6.8 and VBO 8.x-2.4, I could not reproduce the
  problem. But the bulk action failed: Access denied.
• With Drupal 8.6.8 and VBO 8.x-2.5, I could not reproduce the
  problem. But the bulk action failed: Access denied.

I think the Access denied is because the Umami demo uses content moderation, so even admin is not allowed to unpublish a node without also changing the moderation state.

Based on that, I am setting the issue status to NW. We should try reverting the fix and see whether the problem comes back.

I tried reverting the patch from Comment #29, using the default branch (4.2.x).

There are changes to two files: src/Controller/ViewsBulkOperationsController.php and src/Plugin/views/field/ViewsBulkOperationsBulkForm.php. There have been too many changes to the controller since 8.x-2.5, and I do not see how to revert that part. I tried deleting the line indicated by the comment in the plugin:

      // Set default redirection due to issue #2952498.
      // @todo remove the next line when core cause is eliminated.
      $redirect_route = 'views_bulk_operations.execute_batch';

but that led to a new error:

TypeError: Drupal\Core\Form\FormState::setRedirectUrl(): Argument #1 ($url) must be of type Drupal\Core\Url, string given, called in /var/www/html/modules/contrib/views_bulk_operations/src/Plugin/views/field/ViewsBulkOperationsBulkForm.php on line 974 in Drupal\Core\Form\FormState->setRedirectUrl() (line 1034 of core/lib/Drupal/Core/Form/FormState.php).

Instead, I decided to keep that line and remove the comments. Then I did some code cleanup:

1. Now that $redirect_route is defined in all cases, remove the if (...) line and the entire else clause.
2. Rearrange lines so that temp store goes together and redirect logic goes together.
3. Make the line that sets $redirect_route part of the if ... elseif ... else block.

I am attaching a patch for review.

The 4.1.x branch is closer to 8.x-2.5, and I made an almost-clean revert of the patch from #29. In my testing, this works fine.