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 think it makes sense to display more information (title, pager, style, etc...) about the view inside the meta, instead of just 'count'.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | interdiff.txt | 773 bytes | yahyaalhamad |
| #4 | meta_should_include_more_information-3292906-4.patch | 2.54 KB | yahyaalhamad |
| #2 | meta_should_include_more_information-3292906-2.patch | 2.5 KB | yahyaalhamad |
Issue fork jsonapi_views-3292906
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:
changes
Comments
Comment #2
yahyaalhamadComment #4
yahyaalhamadSome views don't necessarily have a pager, this will attempt to fix this fatel error.
Comment #5
markwittens commentedThanks for this patch! I needed the pager info in the output and this patch adds just that plus some more useful data.
Tests should be fixed however and there should be some new tests added for the new output.
Comment #6
decipheredThere is already a good amount of this information available from the `view--view` resource, so it's best not to duplicate work too much.
The biggest issue with the `view--view` resource is that it contains too much unfilterable data, and returns all displays. I think it would be better to concentrate on improvements in that area and then using the relationship from this resource to get that data as required.
Comment #7
markwittens commentedThen what do you propose? The pager information is loaded directly from the view itself, so there's hardly any code duplication. A pager is often essential for a view and I think it actually shouldn't take any extra work for it to be added to the API resource.
Comment #8
martindavi commentedGlad to see others talking about this - our use case would be to know what exposed filters exist on the view and what vocabularies they reference in order to programmatically build those exposed filters on the front end, rather than hardcoding.
I can get this information from the `view--view` like you say, but it would be pretty slick if the metadata of the view was available alongside the data.
Edit:
What makes that difficult though is that the
/jsonapi/view/view/${view_id}endpoint returns:"The current user is not allowed to GET the selected resource. The 'administer views' permission is required."to anonymous requests - I obviously don't want to give that permission to anonymous requests.Comment #11
vhin0210 commentedNoticed that the count is missing after the patch. Tweaked #4 a little bit.
Comment #12
anybody