Theme issue during Batch Process

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

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

Patch #4 working with me
Thank you!

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

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

Solution #1: 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.

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 - but 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 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 !

Thanks for the patch in #4, it works.

Setting to RTBC - note I have previously tried to answer the comment #7 in comment #9.

Ok, let's have it. We'll see if we don't have other issues reported.

Automatically closed - issue fixed for 2 weeks with no activity.