Store custom post type with JSON content

Question

The core WordPress data structures and the REST API’s core controllers aren’t really designed to ever treat post content as anything other than one big string. As Tom mentions in the comments, this means that storing JSON in that field will result in it being presented as an escaped string in REST responses rather than structurally part of JSON response itself – you would need to perform a second pass of JSON-parsing on the field in the client.

Nothing will really “break” – it will just be a bit uncomfortable to see a serialized JSON string included in a JSON REST response instead of as part of the response, in addition to the special parsing case required on the client-side. Another drawback is that if the client is capable of setting the data in this JSON string, then you will likely need to write a fair bit of custom server-side logic to handle validation and sanitization of submitted values (or otherwise find a way to direct that value through the mechanisms which WordPress offers).

A better option might be to store the data in post-meta, as WordPress is already capable of handling complex data stored in meta-values. This also means that within server-side PHP you can interact with the structured data (if necessary) via traditional means without manually unserializing/serializing the data:

update_post_meta(
  $profile_post_id,
  'user_profile_data',
  [
    'status'   => 'Eating a kabob',
    'bio'      => 'Lorem Ipsum dolor sit amet...',
    'bg_color' => '#efefef',
  ]
);

A post meta-field can be exposed on the core REST routes via the register_post_meta() function, which also offers a lot of configurability to assist in validating and sanitizing the data, custom authorization checks, and more. See the Modifying Responses page in the REST API Handbook for more information.

function wpse408959_register_profile_meta() {
  register_post_meta(
    'user_profile',
    'user_profile_data',
    [
      'type'          => 'object',
      'single'        => true,
      'auth_callback' => function( $allowed, $meta_key, $object_id, $user_id, $cap, $caps ) {
        return current_user_can( 'edit_post', $object_id );
      },
      'show_in_rest'  => [
        'schema' => [
          'type'       => 'object',
          'properties' => [
            'status'   => [
              'type'      => 'string',
              'maxLength' => 120,
            ],
            'bio'      => [
              'type'      => 'string',
              'maxLength' => 1024,
            ],
            'bg_color' => [
              'type'      => 'string',
              'format'    => 'hex-color',
            ],
          ],
        ],
      ],
    ]
  );
}

add_action( 'rest_api_init', 'wpse408959_register_profile_meta' );

The Schema page will help in determining how to best write and leverage the schema.

The meta-data will then be available for REST interactions through a property in the meta object:

GET /wp-json/wp/v2/user_profile/1234

{
  // ...
  "meta": {
    "user_profile_data": {
      "status": "Eating a kabob",
      "bio": "Lorem Ipsum dolor sit amet...",
      "bg_color": "#efefef"
    }
  }
  // ...
}

As a final note, if you intend to use any of the complex data within core WordPress systems – say, to filter or sort profiles, or perform a search based on specific fields – then the data would be better organized into WordPress’s core data structures – taxonomy terms or individual post-meta with primitive values, for example. WordPress has facilities for storing and retrieving complex meta-data, but it doesn’t really offer the means to interact with it beyond that, owed to the complexity and overhead involved in operating on serialized values in SQL.

Related Posts: