Problem/Motivation
When using the batch export method in combination with a path that starts with admin/ it is expected that the admin theme would be active and used for the batch export.
Currently the batch will use the default theme instead of the admin theme, as neither Drupal\views_data_export\Plugin\views\display\DataExport::collectRoutes (via parent Drupal\rest\Plugin\views\display\RestExport::collectRoutes) nor Drupal\system\EventSubscriber\AdminRouteSubscriber::alterRoutes set the route option _admin_route - which is used to determine the active theme.
Steps to reproduce
I have only tested this with 9.5
- Install Drupal using core profile
- Enable views_data_export
- Add a Data Export display to the content view, use Method: Batch under export settings and use admin/content/export (or any path beginning with admin) as the path.
- Visit /admin/content/export
- Observe the batch process is using the site theme, not the admin theme
From debugging we can see
When the routes are built:
Drupal\rest\Plugin\views\display\RestExport::collectRoutesreturns the route object with_formatset to the export format selected in "Accepted request formats" in the view (e.gcsv)- AdminRouteSubscriber::isHtmlRoute returns FALSE and so does not mark this as an admin route - it does this by checking the
_formatrequirement of the route to see if it has thehtmlformat. In this case, the format is csv as so it does not get marked as an admin route
When the request is handled:
\Drupal\user\Theme\AdminNegotiatordoes not apply as theDrupal\Core\Routing\AdminContext::isAdminRoutereturns FALSE for the routeDataExport::buildBatchcallsbatch_processwhich calls\Drupal::theme()->getActiveTheme()->getName()to set the theme for the batch - which is not the admin theme due to the above conditions.
Proposed resolution
I believe if batch it in use, it is expected behaviour that using an admin path /admin should use the admin theme.
This would involve the DataExport plugin overriding the collectRoutes method to mark the route as an admin route if the batch export method is used and the path starts with admin.
Remaining tasks
- Agree on approach
- Patch
- Review
User interface changes
TBC
API changes
TBC
Data model changes
TBC
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | views-data-export-3368855-23-mark-as-admin-route.patch | 5.5 KB | goodmood |
| #7 | views-data-export-3368855-7-mark-as-admin-route.patch | 5.44 KB | ericgsmith |
Issue fork views_data_export-3368855
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
ericgsmith commentedUploading example
views.view.content.ymlfile with a json export attached to the default content view which can be used for testing.Comment #3
ericgsmith commentedAnother option would be to add an additional option such as in https://www.drupal.org/project/drupal/issues/2719797 / https://git.drupalcode.org/project/drupal/-/commit/4dbf3f46c19766a38c3e4... to be able to mark the path as an admin route directly in views UI.
In that plugin, if the path start with /admin it is showing "Yes (admin path)" - so perhaps instead of changing the formats on the route, the plugin can just mark the route as admin directly if the path starts with admin?
Comment #4
ericgsmith commentedComment #5
ericgsmith commentedComment #6
ericgsmith commentedPatch going with the option of marking the route as an admin route.
Setting as needs review to get feedback on the approach - we should be able to add a unit test to test the route collection.
Comment #7
ericgsmith commentedWent for a kernel test so that the test can still be valid if the implementation differs from the proposed approach.
Interdiff is the test only patch.
Comment #9
rosk0Thanks Eric!
Looks good to me - approach is sensible, and fixes our unexpected behaviour with front theme on admin path.
Comment #10
tanmaykThanks for the patch. It fixes the problem.
Comment #11
lexsoft commented+1 to get this committed
Comment #12
mibfire commentedActually the "batch" path should always use the admin theme regardless of views path starts with "/admin" or not, because this is also the case in the core:
So here the batch uses always the admin theme and this should be the case with the patch for this issue. I removed the
part from the patch.
Comment #14
ericgsmith commentedThis is not true and is not the case in core.
The batch negotiator (
theme.negotiator.system.batch) runs at a higher priority that the admin theme negotiator (theme.negotiator.admin_theme)See https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/syste...
Comment #15
mibfire commented@ericgsmith
Indeed, you are right. Thanks! I hid my patch.
Comment #16
erom commentedthis patch works for me.Comment #17
erom commentedComment #18
ericgsmith commentedCan you please explain your patch @erom?
If you are making changes to a patch you should supply interdiff and comment on the changes or its confusing to follow.
I've only glanced at it but it looks like the patch in 7 but without the test?
Comment #19
erom commented@ericgsmith, my patch will just automatically use the admin theme when it's using the batch. it is not logically correct since some use cases should allow batch to appear within a theme, i will hide my patch..
Comment #20
besek commentedI've tested patch #17 on Drupal 10.2.6 with Views Data Export 8.x-1.4 and it works really nice, thanks @erom.
Comment #22
ericgsmith commentedMoved patch #7 to MR
This was previously RTBC'd in #9 and #10 and #11 but subsequent patches were added which moved it back to needs work / review.
I'm incline to argue the subsequent changes to the patch have not been needed and the tests were lost - I'm leaving this as needs review.
Comment #23
goodmood commentedAfter module update to 1.5 patch #7 can't be applied anymore. Adding re-rolled patch while MR is in review
Comment #24
dennisdk#23 works as expected for us on 1.5.0
Comment #25
c_archer commentedPatch #23 works well with no issues.
Comment #26
steven jones commentedLooking at this now, we already provide the route and change some options on it, so we don't need to alter our own route I don't think.
Comment #27
steven jones commentedComment #28
steven jones commented@ericgsmith thanks so much for the issue, code and the tests, super helpful.
I've basically committed what you had, but in our method that generates the original route, rather than altering the collection of them. Seems to work fine, and your tests still pass :)
Comment #31
steven jones commentedThanks everyone!
Comment #33
recrit commentedIf anyone got to this issue and wondered why your views data export display is still showing in the front end theme instead of the admin theme, it is most likely because your view path does not start with "/admin". This is because the change for this issue only targeted those paths - see https://git.drupalcode.org/project/views_data_export/-/commit/fcafcfeac3....
This can be fixed in your build by implementing a route subscriber. See https://www.drupal.org/docs/drupal-apis/routing-system/altering-existing... for details on how to create one.
Example: The following will set all "data_export" views displays to use the admin theme.