Problem/Motivation
In core, REST views work by building a render array as for a normal view, and then passing it through a normalizer and serializer to turn it into JSON instead of HTML. Unfortunately, this limits the emitted JSON data for each field to what would normally be displayed in HTML.
This module's premise is to hook into the field system via field display plugins, and (instead of markup strings or render arrays) return a special object that, when normalized and serialized, returns the desired data.
Unfortunately, in order to do so, the special object must pass unscathed through the render system, which (since it is designed to work with strings and markup) may irreversibly flatten the object into its string representation. One of the new ways in which this can happen in Drupal 10 is by assigning it to a typed property (or returning it from a return-typed function) that is typed "string|MarkupInterface", eg FieldPluginBase::$last_render.
Steps to reproduce
- Create a REST view that uses the Fields display mode, and use any of the "(serializable)" field handlers provided by this module.
- Open the view.
Expected result:
- The JSON output contains the correct data for the field.
Actual result:
- The JSON output contains "[...]".
Proposed resolution
This can (for now) be avoided by "camouflaging" the RenderableData and SerializedData types from this module as MarkupInterface, allowing it to be assigned to properties and returned from functions that specify the "string|MarkupInterface" type.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | rest_views-3337859-2.patch | 1.51 KB | cburschka |
Issue fork rest_views-3337859
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cburschkaThis is the patch, but it absolutely needs test coverage.
Comment #5
cburschkaAdding functional tests for this module is going to be a larger effort (eg the lack of config schemas, which may be complicated further by the fact that we are adding views handlers dynamically via an alter hook).
I am therefore pushing the fix now and leaving test coverage for a separate issue.