Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I was having difficulty getting this module to work with a Search-API-based view, and after some digging, discovered this is due to the REST Views module only supporting Views Entity Fields. I moved the EntityFieldExport logic into a trait so that it may be reused to extend other types of Views Fields, such as Search API Content Datasource Fields in this case. I added a child module so that support for these fields may be optionally enabled. Patch to follow.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | rest_views-3015382-5.patch | 3.16 KB | cburschka |
| #4 | search_api_field_support-3015382-4.patch | 7.56 KB | balbuf |
Comments
Comment #2
balbuf commentedPatch for the functionality described in the issue description. This was rolled against 1.0.0-alpha9, but it should work fine against 1.0.0-alpha10 as well.
Comment #3
balbuf commentedFixed patch! There was a namespace issue in the original.
Comment #4
balbuf commentedI'm not sure how I uploaded an empty file last time, but here is the actual fixed patch. Oy vey!
Comment #5
cburschkaThe trait refactor is an interesting idea, but since those methods are overrides I don't think we can/should do that. Referring to
parent::inside a trait will at the very least violate code standards, and there is no clean pattern to get around it.::renderItems() could possibly be extracted to a trait, but that'd still require adding abstract methods / getters for all methods and properties used by it (->renderer, ->multiple, ->prepareItemsByDelta()), and wouldn't reduce tech debt.
All in all, without multiple inheritance in PHP, I suspect duplicating the code ends up being the lesser evil there.
Comment #7
cburschka