Fatal error on Drupal 8.5, on a data_export display that uses not the data_export style but the *default* style

\Drupal\views_data_export\Plugin\views\display\DataExport does class DataExport extends RestExport {…}.
And \Drupal\views_data_export\Plugin\views\style\DataExport does class DataExport extends Serializer {…}.

It looks like #2449143: REST views specify HTML as a possible request format, so if there is a "regular" HTML view on the same path, it will serve JSON made changes that caused the already-brittly-defined \Drupal\rest\Plugin\views\display\RestExport + \Drupal\rest\Plugin\views\style\Serializer to change in slight ways that broke views_data_export's subclasses.

Unfortunately, it looks like this module is not actively maintained. Last release in December 2016, and an alpha release at that. No automated testing set up against the current and next core minor. Then this would have been discovered back in October of 2017…

Marked #2954768: REST views: Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() as fixed, because support was given there, but the bug needs to be fixed here.

@brooke_heaton provided an export of his failing view at #2954768-6: REST views: Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() .

The relevant bits are these:

  data_export_1:
    display_plugin: data_export
    id: data_export_1
    display_title: 'Job Description Export'
    position: 5
    display_options:
…
      style:
        type: data_export
…

  data_export_2:
    display_plugin: data_export
    id: data_export_2
    display_title: 'Active Users Export'
    position: 1
    display_options:
…
      style:
        type: data_export
  data_export_3:
    display_plugin: data_export
    id: data_export_3
    display_title: 'Board of Directors Export'
    position: 1
    display_options:
…
      style:
        type: data_export
…
  data_export_4:
    display_plugin: data_export
    id: data_export_4
    display_title: 'Committee Members Export'
    position: 1
    display_options:
      style:
        type: default

Note how the first four all of have display_options[style][type]=data_export. But the last has display_options[style][type]=default.

That last one is problematic. The data_export display builds on top of the rest_export display, i.e. \Drupal\rest\Plugin\views\display\RestExport. But AFAICT this should never have worked, because already since before Drupal 8.0.0 was released did \Drupal\rest\Plugin\views\display\RestExport::collectRoutes() call $style_plugin->getFormats()!

(This is the problem with subclassing existing coupled classes that do not constitute an API — if the coupling between those classes changes, your subclasses need to be updated as well!)

I sort of minimally maintain the Drupal 7 branch.

No automated testing set up against the current and next core minor. Then this would have been discovered back in October of 2017…

Can you point me at some docs for how this should be set up for a contrib module?
Whenever I edit the automated testing settings the forms seem to have changed and there are more labels and options that ever.
It also doesn't help that the interface is well...very Drupally.

I agree the interface is pretty painful :(

You want something like in the attached screenshot — that's for https://www.drupal.org/project/http2_server_push.

Hey guys,

I'm getting the same issue too...Did anyone get a fix for this? I even uninstalled the module and still have the issue.

EDIT: I was able to fix the issue when I click "serializer" inside my views..Is this some sort of glitch?

Thanks!

In our case it happened because of migrated views that originally used XLS data export in Drupal 7 which is not available in Drupal 9. Therefore they used default style plugin instead of the missing XLS one. Switching the style plugin to CSV fixed the issue.

In core/modules/rest/src/Plugin/views/display/RestExport.php function collectRoutes

find the line
$formats = $style_plugin->getFormats();

replace with
$formats=false;
if (method_exists($style_plugin,'getFormats'))
$formats = $style_plugin->getFormats();

Urgh, this really is a core bug, as you can reproduce it with a plain Drupal 11.2 site.

Steps:

1. Create a new view
2. Add a page display, and override the default display plugin, but set it to the 'default' plugin, which is called 'Unformatted' in the UI.
3. Use the 'Duplicate as REST export' functionality to produce another display
4. Tweak the path of this display so that you can save the view
5. Save the view
6. On collecting routes, this will now cause a fatal error, since the Rest Export display plugin assumes that the style plugin is compatible, but it isn't because it's the 'default' plugin and doesn't have a getFormats method.

This is actually related to another VDE issue: #3551130: Improve cloning in views to prevent crashes.

Yeah, Drupal core doesn't bother to validate that a selected style plugin is valid.

I've got some code in https://git.drupalcode.org/project/views_data_export/-/merge_requests/90 that does, and that at least stops you from creating new views with this issue via the views UI. Not sure if that method gets called at other points to stop views that have made it to the config system already, and are incorrect...but honestly you could break lots of things like that.

I think that the fix over there will cover off the most common way to get to this error, and we can work on 'migration' support, and we can also raise the core bug and let that one sail off into the 'never fixed' ether.

Okay, so in #3551130: Improve cloning in views to prevent crashes. I've added some code that will validate the display as having valid style and row plugins, so that'll avoid users getting into this sort of situation I believe.

If some migration framework is simply cobbling together some random YAML and hoping that it'll work in Views, then that's the thing that needs fixing really. You could break lots of Drupal by playing around with config at a very low level. And there's plenty of code that'll break etc.

At least now, if you were to edit the view you'd get some helpful messaging.

I'll raise a ticket against core, explaining the issue etc. and maybe it'll get sorted and in.

I think I'll mark this ticket as a 'won't fix' because I'm not sure there's much we can do here.