Problem/Motivation

Once we start the batch process to perform some action on contents. On batch progress bar page, it doesn't use current active theme for end user.
As a final result, the page design is break for users excluding admin.

Steps to reproduce

  1. Create a content listing view and integrate a view bulk operation.
  2. Set the view bulk operation configuration as shown in screenshot [Screenshot from 2021-06-29 11-04-14].
  3. Select any bulk operation.
  4. Save the View.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DimpleL created an issue. See original summary.

Graber’s picture

Status: Active » Closed (works as designed)

It's not dependant on VBO, it's the Drupal core batch processing page that has its own URL.

See this core issue: #539022: Batch API should use the current theme to run the batches

n.ghunaim’s picture

Status: Closed (works as designed) » Needs work

I'm still facing this issue even when upgrading the core module to 9.5.9

n.ghunaim’s picture

I have applied a change to make views_bulk_operations.execute_batch routing use the _admin_route, this fixes the theming issue for the bulk operations module.

n.ghunaim’s picture

Status: Needs work » Needs review
Qusai Taha’s picture

Status: Needs review » Reviewed & tested by the community

Patch #4 working with me
Thank you!

Graber’s picture

Version: 4.0.0-rc1 » 4.2.x-dev
Status: Reviewed & tested by the community » Needs work

And what if the view having a VBO field is not on admin pages and uses the default theme instead of the admin theme?
Also, what about other controllers like the confirmation and configuration form for actions that require those?

Rajab Natshah’s picture

I agree with Marcin on #7
I was sat to add the patch to our product.
But had the same questions.

Solution #1: Maybe VBO Edit, VBO Export, or other extending VBO solutions could have switcher for that. ( big work and hard coded fix - I'm not with that )

Solution #2: A plugin switch checkbox in the advanced view settings, or custom cloned views could manage to change and pass the ( Default theme, or Admin theme ) to the Batch Theme Negotiator

        if (batch_theme_view_settings == 'admin') {
          return $this->configFactory->get('system.theme')->get('admin');
        }
        else {
          return $this->configFactory->get('system.theme')->get('default');
        }

Maybe views already can do this with a bit of hook alters.

I feel that this could be in Drupal core, or a contrib module to select the theme for the batch job under Advanced view settings next to Use AJAX for example.

ericgsmith’s picture

Status: Needs work » Needs review
Related issues: +#2911751: VBO pages should use admin theme

Adding related issue.

Reading the issue #2911751 _admin_route: TRUE was added to views_bulk_operations.confirm and views_bulk_operations.execute_configurable on the assumption that if the user has access to the admin theme then it was fine then to use that for the configuration form.

I think that is the same concern here expressed in #7 - but at this point its a fairly established assumption. Because _admin_route: TRUE was not applied to the batch route - if you are not using a configurable plugin or a confirmation screen then you do not get the admin theme and you receive an inconsistent experience.

So to answer:

And what if the view having a VBO field is not on admin pages and uses the default theme instead of the admin theme?

#4 would result in the same current behavior for the confirm and configuration forms - these would render as the admin theme if the user has permissions to see it.

Also, what about other controllers like the confirmation and configuration form for actions that require those?

When using confirmation option - The processor is executed in the submit handler for the ConfirmAction form so when batch_process is called the current route is views_bulk_operations.confirm which has _admin_route: TRUE so the batch uses the admin theme if you have permissions to use it.

When using action with configuration - The processor is executed in the submit handler for the ConfigureAction form so when batch_process is called by the plugin the current route is views_bulk_operations.execute_configurable which has _admin_route: TRUE so the batch uses the admin theme if you have permissions to use it.

When using action with no configuration or confirmation - ViewsBulkOperationsBulkForm does not execute the plugin, but redirects to views_bulk_operations.execute_batch so when batch_process is called by the plugin the current route is views_bulk_operations.execute_batch which does not have _admin_route: TRUE so the batch uses the default theme.

Based on that - I would say the patch from #4 does the minimum to keep it consistent - but could introduce edge case regressions where a user with access to the admin theme may expect the batch to run in the front end. In this case, they would already be seeing the admin theme if the action had a configuration or confirmation form.

Alternatively, in ViewsBulkOperationsBulkForm - could this be refactored so that it keeps the existing redirect behavior for configuration and confirm options - but calls execute directly on the plugin and redirects to the batch here rather than delegating this behavior to the views_bulk_operations.execute_batch route? I haven't really taken a close look at this route / controller to see if there is anything prohibiting this. That also might not be relevant as while it could solve an edge case, it would still be inconsistent since those 2 routes current using admin wouldn't take the current view into account anyway.

That all said - I think #4 keeps things consistent, doesn't over complicate things and works for my use case so would be RTBC for me - but setting to needs review to clarify if its still needs work based on #7. Thanks @n.ghunaim !

balazswmann’s picture

Thanks for the patch in #4, it works.