Duplicating a view with an exposed form as data export causes issues

I tested this today on a fresh Drupal 10.3.x, umami install. I installed views_data_export, made the view and exposed the 'published' filter, tested, duplicated the view and tested again. In all cases this worked without error.

This still needs steps to reproduce. I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

The work above was done at DrupalSouth 2024

I've also been able to replicate by changing an exported data export display exposed form to `exposed_form: false` following #10

And then reimporting config, the RestExport::usesExposed class that DataExport class inherits always returns true and so when an exposed form is not present it throws error.

I was not able to replicate through the UI but just through manual manipulation of the configuration.

Hola, this came up in the #bugsmash channel as the PMNMI daily triage target.

Since we haven't had an update in nine months, if there is no update in the next three months, this issue may be closed.

Same issue here on Drupal 10.4.1, after using "Duplicate as Data export" on a page display that uses Better Exposed Filters. #10 resolved it.

As per #40 it looks like this is not a core issue. Please raise an issue in BEF if necessary.

I reopen this issue as I encounter the same problem and was able to determine the reproduction steps.

Drupal 11.2.2 fresh install.

1. Install Views Data Export
2. Go into the Content view : admin/structure/views/view/content/edit/page_1
3. Create a new page display and set it a path, then save
4. Go back to the initial page display : admin/structure/views/view/content/edit/page_1
5. Click on "Basic" near "Exposed Form"
6. In the "For" list, choose "This page (override)". Apply, and save
7. On the right in the select list "View Page", select "Duplicate as data export"
8. See that you immediatly get an error : "Oops, something went wrong. Check your browser's developer console for more details."

You can enable DBLog or check the log by another way and see that the error is : "Error: Call to a member function preExecute() on null in Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute() (line 2367 of core/modules/views/src/Plugin/views/display/DisplayPluginBase.php)."

I'm going to investigate further but for now I understand that, as soon as you override the Exposed form configuration for a display, you obtain an entry "exposed_form: false" in the "defaults" part of the display :

display:
  default: [...]
  page_1:
    id: page_1
    display_title: Page
    display_plugin: page
    position: 1
    display_options:
      exposed_form: [...]
      defaults:
        exposed_form: false
      [...]

which means "This display does not use the exposed form settings of the master display".

When you duplicate this as a Data Export you get :

display:
  default: [...]
  page_1: [...]
  data_export_1:
    id: data_export_1
    display_title: 'Data export'
    display_plugin: data_export
    position: 1
    display_options:
      defaults:
        exposed_form: false
    [...]

which means the same thing : "This display does not use the exposed form settings of the master display" but in this case there is not the exposed_form additional entry.

For now I guess that the solution would be to not include the

display_options:
  defaults:
    exposed_form: false

part in the duplicated display if this one does not allow to use an exposed form or to not considere it in DisplayPluginBase.php.

Note that the provided patch is not ok as it will prevent to override exposed forms on displays (since the exposed_form: false entry is not exported anymore).

After further investigation, I found the following :

1. $exposed_form->preExecute() is call because $this->usesExposed() returned TRUE
2. $this->usesExposed() invoke RestExport::usesExposed() because DataExport extends RestExport and do not redefine usesExposed()

According to https://www.drupal.org/project/drupal/issues/2340623 → it seems necessary that usesExposed() return TRUE so exposed filters will apply on the export.
This seems to be confirmed by my test as if I put FALSE in the return, the admin/content exposed filters are not anymore taking into account in the data export.

So I was wondering how a REST export would handle this and I can see that the exact same problem occurs if I duplicate my page as a REST export.

This should confirm that the probleme is in core as we can reproduce even without Views Data Export.

I ended finally with this two patches (for drupal 10.4.5 and 11.2.2) for which the idea is the following :

1. As per #2340623: Views REST export does not support exposed filters → , both Rest and Data export should define that "they use exposed" but anyway they cannot store any exposed form display configuration
2. They neither can store which was their "original display in the duplication" and they do not really seem to need to know that
3. So to avoid these problems we could just say : if the exposed_form option seems overrided but the display does not has a key for the override, we will just get this information from the default display

The fix is global as it concerns all possibles options but I let maintainers say if that's ok or not or this a better way to fix it.

Thanks for that @nixou but changes need to be done in an MR.

It would also be great if you could put those steps into the issue summary using the standard template under the steps to reproduce heading.

Thanks!

I tried reproducing the original issue locally by manually duplicating a view display with an exposed form and simulating the faulty override (exposed_form set with defaults set to FALSE). However, the test I wrote passed successfully without applying the patch.
This suggests the issue might already be resolved in the current version of core.
Do we still need to proceed with adding the test, or is this no longer reproducible and can potentially be closed?

I was able to reproduce on the last core version 11.2.2 so I don't think the issue is resolved.

What was the core version you tested on ?

I'm currently testing on Drupal 11.3-dev, and I’m able to reproduce the issue through the UI. After applying the patch, the issue is resolved in the UI as expected.
However, I wasn't able to reproduce the error reliably through automated tests. Given that, I'm submitting this MR with the patch and leaving the addition of tests to someone else who might be able to implement them more effectively.