Add export links as local actions instead of feed icons

I have written a working prototype that adds local actions instead of feed buttons, but there's one issue: if the view has AJAX enabled and exposed filters are changed, the URL in the local action is not updated, which causes filters to not be passed to the export.

A couple possible solutions:

• force AJAX to be disabled if we want to add a local action (not ideal)
• make sure the local action region is rebuilt using AJAX when the view is rebuilt using AJAX (sounds complicated)
• write some custom JS updating the local action query params when the current page query params change (possible too hacky?)

More (possible) todo's:

• Make sure local actions are regenerated when export display handlers are added/edited/deleted
• Add a new setting to show the local action, since it's no longer part of the feed icons

I changed the local action name to use the display title, to fix the issue as described in 🐛 Multiple export download links should be distinguishable Active .

I fixed the issue where the local action title is not updated if the display title changes. Pretty sure the local action cache still needs to be invalidated when a new view is created, in order for the new local action to be generated, but I haven't tested this yet.

When removing the old feed icons I discovered we'll have to re-implement the auto download functionality - not sure what exactly it does though.

I added some JS that keeps the local action query params up to date with the current page's query params.

If I remember correctly, the auto-download works using a CSS selector in the message shown with the download link. JavaScript selects the link from the message and downloads the file.

It looks like the 'Include query string parameters on redirect' option currently only applies to batched exports. By updating the query params in JS, it will also work for direct exports.

Never mind, the redirect functionality is obviously not available for direct downloads.

There is a failing test.

I don't know why but this diff will not apply..

    https://www.drupal.org/files/issues/2023-02-20/views_data_export-3173296-25.patch (https://www.drupal.org/project/views_data_export/issues/3173296#comment-14930767)
    ./patch/31.patch ()
   Could not apply patch! Skipping. The error was: Cannot apply patch ./patch/31.patch

MR's are based on the latest dev commit, not the latest tagged release. You can use the dev release (composer require drupal/views_data_export:dev-1.x) or you can try to rebase the branch against the latest tagged release and create a patch from that.

I'm not able to get the local download action to show. I can't figure out how to add the block to my page layout.

I'm sorry, but that sounds like an issue with your website, not with this MR. This MR shows local tasks just like core and every other contrib module does.

I disagree. I have local tasks already showing, but your added tasks do not show.

I installed the dev version, applied the patch, cleared the cache, and yet I do not see any "Download CSV export" task link on the page where previously the Download CSV button showed.

Oh okay, so the issue is not about adding a block to your page layout. The local tasks of this issue should show in the same place as other local tasks do. Is the problem fixed after you clear caches? Did you change the 'Attach to' setting to include the display you want the local task to appear on?

Yes, the "attach to" option is correctly set. No, the download option doesn't show after clearing the cache.

Ah, I think the problem is that you added the link as an action, rather than as a task. I don't use the actions module.

I think this should be thought through. If you look at examples in Core/Contrib, most action links are "Add X"

• Comment: Add comment type
• Key: Add Key, Add Override
• Node: Add content type, Add content
• Path: Add alias
• System: Add format
• Update: Add new module or theme, Add new module, Add new theme
• User: Add user, Add role

All the other local-type links are tasks.

Right, good catch. I still believe it makes sense to keep it a local action since downloading is an action: it doesn't even link to a separate page, it just downloads something. Local tasks are shown as tabs, they are links to separate pages. It would be confusing if clicking a tab wouldn't navigate to another page, but instead would download a file. Here's some info about local actions → vs local tasks (tabs) → .

By the way, you don't need the actions module to be able to show local actions. Local actions are a core feature that can't be disabled. You might need to place the local actions block if you haven't yet, but I can't imagine a lot of people aren't using that block. It places useful links all throughout the admin interface.

I have the block placed... in the admin theme. The download action on views is not going to be in the admin theme for most views with exposed filters, at least not in my case.

Okay, so how do you propose going forward? Should we give the option to either show the old icon or the new local action? Or do you have something else in mind?

I think if we have a config setting to either use a local action or a download button, that would work well.

Though I think it'd be better to add in the solution from 📌 Increase size of download buttons RTBC instead of using the prior images. Images don't go well with site themes, and making them buttons works well.

patch works with 1.4

Repatch

Patch for the latest dev

As mentioned in 📌 Increase size of download buttons RTBC , I do not support these changes. I don't use the local actions block on my non-admin theme, and that makes it impossible to export view data in that case.

There should be a config option for if people want the existing behavior, rather than breaking the functionality for sites that already use the module and rely on the existing behavior.

So in 📌 Increase size of download buttons RTBC I committed some changes that would remove the old school feed icons, and instead add a button class.

Because this is a breaking change, it needed a 2.x version, and is currently the only difference between the branches, and now, a few months later, a bit silly.

I've actually just tried to use this on a site of mine and fundamentally I wanted to override the theming anyway to apply our site specific classes, which I did and was super easy etc.

So...I think this is mostly about the appearance of the download buttons/links/actions in an administration theme where you don't have a lot of control over the templates etc. Hence why some people want 2010s style links, some links with a button class and others local actions.

I'm very minded therefore to actually introduce some kind of configuration option of how the link should be rendered, and for new views use a plain link with a 'button' class, but keep the 1.x version around as an option and allow the local actions stuff in this ticket as another option.

It think that's the best way forward for a module that's minimally maintained (at the moment) and should work for everyone.

Based on the previous comment, this can actually go into 8.x-1.x.

I'm very minded therefore to actually introduce some kind of configuration option of how the link should be rendered, and for new views use a plain link with a 'button' class, but keep the 1.x version around as an option and allow the local actions stuff in this ticket as another option.

I think this would be a good solution.