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

Created on 14 June 2018, about 7 years ago
Updated 22 March 2024, over 1 year ago

I had duplicated the view form an existing view (that has an exposed form) as a data export. When I try to use VDE (CSV button) on that view, I get this:

Create a view of taxonomy data with an exposed filter.
Duplicate view for views_data_export
Try exporting the data
Error:

Error: Call to a member function preExecute() on null in Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute() (line 2272 

The code it fails on is

    if ($this->usesExposed()) {
      /** @var \Drupal\views\Plugin\views\exposed_form\ExposedFormPluginInterface $exposed_form */
      $exposed_form = $this->getPlugin('exposed_form');
      $exposed_form->preExecute();
    }

I then did #10 and now it works fine.

šŸ› Bug report
Status

Postponed: needs info

Version

11.0 šŸ”„

Component
Views UIĀ  →

Last updated 4 days ago

Created by

šŸ‡ŗšŸ‡øUnited States labboy0276

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • šŸ‡³šŸ‡æNew Zealand quietone

    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!

  • šŸ‡³šŸ‡æNew Zealand quietone

    The work above was done at DrupalSouth 2024

  • šŸ‡¦šŸ‡ŗAustralia RichardGaunt Melbourne

    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.

  • šŸ‡¦šŸ‡ŗAustralia griffynh Sydney

    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.

  • šŸ‡¬šŸ‡§United Kingdom davej

    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.

  • Status changed to Closed: cannot reproduce 3 months ago
  • šŸ‡¦šŸ‡ŗAustralia acbramley

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

  • Status changed to Active 6 days ago
  • šŸ‡«šŸ‡·France Nixou Toulon

    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).

  • šŸ‡«šŸ‡·France Nixou Toulon

    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.

  • šŸ‡«šŸ‡·France Nixou Toulon

    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.

  • šŸ‡¦šŸ‡ŗAustralia acbramley

    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!

  • šŸ‡«šŸ‡·France Nixou Toulon
  • šŸ‡®šŸ‡³India divyansh.gupta Jaipur

    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?

  • šŸ‡«šŸ‡·France Nixou Toulon

    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 ?

  • šŸ‡®šŸ‡³India divyansh.gupta Jaipur

    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.

  • Pipeline finished with Failed
    4 days ago
    Total: 214s
    #538114
Production build 0.71.5 2024