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

Can confirm I'm getting the exact same error when duplicating a view with exposed filters

I am having the same issue. In D8. I have a View display that is using the format Datatable from the Datatable contrib module. I need to switch it to output Json but maintain its many content fields, field rewrites, and filters. So I duplicated its display as a Rest export to output Json, then add a url path so I can see the Json output. I did this on a View we setup and it worked. I am now doing it to a different View and I get a WSOD and an error. I tried removing all of the fields and filters but I still get the error. Has anyone seen this before? The error: phpError: Call to a member function preExecute() on null in Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute() (line 2272 of /var/www/html/fda1/docroot/core/modules/views/src/

I see a related post for D7 and they said to remove 'Better Exposed Filters' if the View uses it. Mine is using it, removing it did not fix the problem.
https://www.drupal.org/project/views/issues/1784070

I have the same problem without any view filters.

I fixed this to create a new display without views duplicate feature.

Same thing happened to me. I had to split up my views displays into individual views and make them the "master" view so I could then create a new views display as the export for it to work.

The issue is the Views Data Export view display's configuration contains a "exposed_form: false" if you export the view as YML.
To solve this I:

1. exported the view
2. located the view display that was generated by the "duplicate" operation in the YML.
3. Removed the "exposed_form: false" line.
4. Imported the YML back into Drupal.
5. Refresh the page my view is on and it now works.

Hope this helps someone else out rather than rebuilding views based off of defunct/outdated Master displays in a view.

#10 works... many thanks @_randy

#10 also worked for me, thanks @_randy!

#10 works. Thanks @_randy.

#10 works perfectly. Thanks @_randy

Thanks @_randy, it works.

Looks like this is a core bug, should this be moved to the core's issue queue?

Moving to the core's issue queue and tagging "Bug Smash Initiative"

#10 worked for me as well. Thanks @_randy

So how do we reproduce this with vanilla core?

If the problem is exposed_form:false, the question is how did you get that value into the config? exposed_form should be an array not a boolean as far as I can tell.

#10 worked for me as well. Thanks

#10 did it for me, thanks @_randy

Many thanks @_randy, #10 fixed this issue for me

#10 also worked for me, thanks @_randy!

+1 for #10, thanks @_randy

The issue occurs if you have set an exposed form style other than Basic, e.g. Views Autocomplete Filter from https://www.drupal.org/project/views_autocomplete_filter, on the display to copy.

#10 also worked for me on D9, thanks @_randy.

#10 for the win. Thanks for the finding.

So #26 sounds like something that needs to be fixed in the contribs and not in core. Checked again and both core plugins set the value to an array as it should. Took a look at the module pointed out in #26 but don't see a custom exposed filter form in that one?

Anybody know a module that could cause this so we could pinpoint what is breaking this (thinking of missing schema here, but would be nice to check)?

I'm also using an exposed form style distinct from Basic, and is Better Exposed Filters with Layout

https://www.drupal.org/project/vefl
https://www.drupal.org/project/better_exposed_filters

I just ran into this issue with creating a views_data_export where I have exposed filters on my view.

The parent view had 3x exposed filters and 1 other view that wasn't exposed. The exposed_form ends up on "default" display option.

2022/12/12 01:02:41 [error] 834#834: *5060 FastCGI sent in stderr: "PHP message: Error: Call to a member function preExecute() on null in /home/vagrant/WG/wg/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php on line 2323 #0 /home/vagrant/WG/wg/web/core/modules/views/src/ViewExecutable.php(1695): Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute()
#1 /home/vagrant/WG/wg/web/core/modules/views/src/ViewExecutable.php(1630): Drupal\views\ViewExecutable->preExecute()
#2 /home/vagrant/WG/wg/web/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay()
#3 [internal function]: Drupal\views\Element\View::preRenderViewElement()
#4 /home/vagrant/WG/wg/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array()
#5 /home/vagrant/WG/wg/web/core/lib/Drupal/Core/Render/Renderer.php(772): Drupal\Core\Render\Renderer->doTrustedCallback()
#6 /home/vagrant/WG/wg/web/core/lib/Drupal/Core/Render/Renderer.php(363): Drupal\Core\Render\Renderer->doCallback()
#7 /home/vagrant/WG/wg/web/core/lib" while reading response header from upstream, client: 192.168.10.1, server: wg.test, request: "GET /by_bank_accounts/317?_wrapper_format=drupal_ajax&page=0&_format=csv HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php8.0-fpm.sock:", host: "wg.test", referrer: "http://wg.test/admin/structure/views/view/transactions/edit/block_5"

Here I just made it not export the exposed_form: false when duplicating the view so we don't have to keep going in and deleting it in the exported yml. I'm sure there's a better way that each module could implement this for duplicating.

You will need to recreate the view if you have one that you've manually fixed.

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 #2340623: Views REST export does not support exposed filters 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 overriden 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 if there is 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.

I am getting this as well. One display has exposed filters, then I duplicate it as data export, and I get WSOD when clicking on the export with the error in the issue summary.

Not sure how to reproduce this on a test either.