Views REST Export JSON output inconsistency for boolean fields when fields are missing across content types

Created on 25 September 2025, 16 days ago

Problem/Motivation

When using Views REST Export in Drupal 11 with JSON output format, selecting multiple content types that include fields which are present in some content types but not others leads to inconsistent serialization behavior. Specifically,
for boolean fields (e.g., a boolean field named "is_accessible" present in the "article" content type but absent from the "page" content type), the JSON output shows true/false values for entities where the field is defined (e.g.,
articles), but returns an empty string ("") for entities where the field is missing (e.g., pages). This inconsistency affects data consumers expecting uniform boolean values, such as false in cases where the field is absent or
undefined, which breaks API reliability and predictability.

Steps to reproduce

  1. Create two content types in Drupal 11: "page" and "article".
  2. Add a boolean field named "is_accessible" to the "article" content type, but do not add it to the "page" content type.
  3. Create several nodes: some of "page" type and some of "article" type. Ensure at least one "article" node has the "is_accessible" field set to true, and another to false.
  4. Create a View of type "REST export" in Drupal Views UI.
  5. Select the "page" and "article" content types in the View filters.
  6. Add the "is_accessible" field to the View fields configuration, ensuring it is exposed in the JSON output.
  7. Set the View's output format to JSON.
  8. Access the REST export URL and examine the JSON output for both page and article nodes.
  9. Observe that "article" nodes show "is_accessible": true/false, while "page" nodes show "is_accessible": "".

Proposed resolution

Modify the Views REST Export serialization logic to treat missing boolean fields as falsy by default. Specifically, update the field output to return false (or the appropriate boolean equivalent) when a boolean field is not present on an entity, rather than serializing it as an empty string. This could be implemented in the REST export plugin or through a Views field handler override, ensuring consistent output across multi-content-type Views. The change should be configurable or at least maintain backward compatibility where possible.

Feature request
Status

Active

Version

3.1

Component

Code

Created by

🇮🇳India someshver Panchkula

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.

Production build 0.71.5 2024