I'm building a mobile app and website on a WP backend, which is the reason why I'm looking for a uniform JSON Request-Response pattern.
Everything's working fine, and the wp installation does not use any plugin / particular theme, every plugin / theme it uses is the result of custom development.
The app has users that each have a profile, which I registered and generate as a custom post type, solely for that purpose.
The last step I'm thinking of now is to store the wp post contents of that custom post type as JSON only. Like this I'll be able to use them without any additionally needed parsing, both for the web and mobile app development.
Before doing this, I wanted to double check:could this be a problem for the wp core, or break some other functionality of the wp core? I also intend to use the WP REST api for posts to query for posts of that custom type, using WP's, built-in REST API features for the query interfaces, includin tags, metas, and whatever else it offers.
Will using only JSON post contents be a problem here?
UPDATE
I've implemented the suggestion below, but can't get it working, actually. The value that I retrieve from the rest API, if I retrieve the according meta field, is always null
.
I've now checked in the wp_postmeta
db, and can see that this seems to be a retrieval error. Because, when I for example store ['hello' => 'there']
as a meta value, I get the following according value in the mentioned table:
a:1:{s:5:"hello";s:5:"there";}
so the serialized string. For some reason, wp fails to retrieve that back as a normal array. This even occurs when I omit the schema and the auth callbacks or whatever fancy additional function you can add to your register_post_meta
call. So it seems like I have to add some custom parsing anyway for the REST retrieval? Hence, I should rather use register_rest_field
for this? Or am I missing something?
UPDATE 2
Okay, found it. The first problem is that this here:
If the existing value for a meta field does not validate against the registered type and schema, the value for that meta field will be returned as null.
Simply inserts null
into your db, while the call to add_post_meta()
actually returns true in that case, falsely indicating that your metavalue has been properly created. In the same way, you can even have valid serialized object data in your DB (which was the case for me); but if your schema
does not match with the serialized data present within your DB, the rest API will retrieve null
, although you actually have properly serialized data within your DB. Here again, without indicating any error. Because the schema
seems to be applied for retrieval too, not only for storage.
With this, I can think about two problems now:
For everything to work properly, you have to assure that your schema matches all possible cases of your meta value.
The rather bigger problem I see here is: What if your schema of that value may change over time with updates of your application? This would mean that you would need to update your
schema
accordingly. This would in turn however turn the retrieval of all of your post meta fields that are still based on the oldschema
intonull
values. Except if you implement some compromise schema like setting properties of your new schema, that are mandatory in the new schema, asrequired => false
, to still be able to retrieve your old metas, not yet affected by the updates. But imho that will cause a mess.
So make sure you think about this and consider eventual future cases when using post meta fields. Or am I misunderstanding something?