Discussion between bosco and DevelJoe

« first day (3 days earlier) ← previous day next day → last day (18 days later) »

DevelJoe

15:39

@TomJNowell which I don't need, the data will always be retrieved in one block

@TomJNowell 1. Yes I said I require to make my website work as a JSON mobile app API, and 2. I don't get what you mean here

@TomJNowell well feel more than free to share if you see a better suited solution than the currently discussed post_meta solution

@bosco cheers, agreed!

bosco

@DevelJoe That was for the stuff from yesterday - probably not still applicable to whatever you're working with now :)

DevelJoe

yup, so yeah I don't get the currently last problem; one sec I'll paste the code. and @TomJNowell cheers for your help too

Tom J Nowell

@DevelJoe the requirement that you store the JSON you recieve as a singular blob of data is entirely self-imposed

it's a mismatch between equality and equivalence

and it's forced your hand with how you store that data because you've chosen equality

e.g. if the app sends the number 5 then storing 5.0 or '5' is unacceptable

DevelJoe

@TomJNowell you're saying that's the reason why I'm getting null upon retrieval via REST, but not via get_post_meta() ?

Tom J Nowell

I never mentioned null, or get_post_meta

that would be a leap of logic

I was making the point that taking in data and responding with that same data is the pattern, but you've taken it one step even further and it's limited your options

you don't have to store the input and reuse it as the output to implement the pattern

processing it into its constitutuent parts then re-generating it on output is ok too

they don't have to be equal, they can be equivalent

DevelJoe

15:50

@TomJNowell sorry I don't understand what you're saying. The current state is that the object is delivered as one single payload. Splitting up the payload into the constituents makes absolute no sense in my usecase; as I'll only ever use the entire object, hence I would need to aggregate the constituents upon every request. This makes no sense

Tom J Nowell

you already do that, and would need to do that anyway to avoid JSON encoded inside JSON

eitherway you're not seeing what I'm saying

I'm not telling you to break it apart

I'm not telling you to never break it apart

I'm not telling you how to fix the issue either

DevelJoe

well I don't understand what you're trying to tell me^^

Tom J Nowell

I'm just saying you don't have to store the exact original and present it exactly the same whitespace and syntax and all

discard that notion and you can be more flexible about how you store things

e.g. if you were using a custom table your approach would make a string based column a hard requirement

but if you use equivalency instead, then JSON columns become an option

DevelJoe

but wp provides an interface for that via register_post_meta, and I would like to understand it

Tom J Nowell

as does minimising the response, JSON schemas, etc

meta values are strings

WP doesn't provide a mechanism for storing JSON and then including it as actual JSON, you'll just get a string that contains encoded JSON

like if you did echo json_encode( [ 'meta' => json_encode( [ 'values' ] ) ] )

DevelJoe

15:55

developer.wordpress.org/rest-api/extending-the-rest-api/…

Tom J Nowell

that's not a raw arbitrary JSON structure

DevelJoe

```
"release": {
"version": "5.2",
"artist": "Jaco"
}
```

Tom J Nowell

and it isn't going to preserve your JSON blob as is pristine and unmodified

DevelJoe

you know what

I'll just share my code

Tom J Nowell

it'll be decoded, validated and processed

DevelJoe

15:57

one sec

Tom J Nowell

register_rest_field would let you use callbacks allowing you to accept the raw JSON then decode it so it appears as you wanted, no schemas etc

DevelJoe

@TomJNowell That's why I started to think about that function yesterday. But I actually prefer a solution with a schema, sounds better to me

So, @bosco; take this call to register_post_meta as an example:

```
register_post_meta(
post_type: 'my_custom_post',
meta_key: 'my_meta_field',
args: [
'type' => 'object',
'single' => true,
'show_in_rest' => [
'schema' => [
'type' => 'object',
'oneOf' => [
[
'title' => 'first_possibility',
'type' => 'object',
'properties' => [
'first_name' => [
'type' => 'string',
'required' => true
],
'age' => [
'type' => 'integer',
'required' => true
],
'gender' => [
'type' => 'string',

Tom J Nowell

hmm if it's predictable enough that you can do it that way, my concern is that it may involve a decode and encode and I'm not sure how well your mobile app handles that as PHP's JSON encoding may differ a little

DevelJoe

To this field, let's say you add a value that gets stored as this in your DB:

a:5:{s:10:"first_name";s:7:"DévelJ";s:3:"age";i:28;s:6:"gender";s:1:"m";s:9:"languages";a:2:{i:0;s:2:"en";i:1;s:2:"de";};s:9:"locations";a:1:{s:12:"unitedstates";a:2:{i:0;s:8:"Colorado";i:1;s:10:"Washington";}}}

You do so by adding this to `add_post_meta()`:

[
"first_name" => "DévelJ",
"age" => 28,
"gender" => "m",
"languages" => [ "en", "de" ],
"locations" => [ "unitedstates" => [ "Colorado", "Washington" ] ]
]

And when trying to retrieve that via:

GET https://example.org/wp-json/wp/v2/my_custom_post?_fields[]=id&_fields[]=meta.my_meta_field&_fields[]=title

You get all the correct post IDs and titles, but `null` for the my_meta_field

Tom J Nowell

16:15

note in this case a very old WP feature is running serialize on that array/object and storing the PHP serialised data

it's actually safer to json_encode it

DevelJoe

you mean, instead of storing:

[
"first_name" => "DévelJ",
"age" => 28,
"gender" => "m",
"languages" => [ "en", "de" ],
"locations" => [ "unitedstates" => [ "Colorado", "Washington" ] ]
]

store the `serialize` output of it?

Tom J Nowell

I mean WP sees it's not a string or a basic type such as a boolean etc, so it runs serialize on it which is a PHP function and stores the result

then when you call get_post_meta there's a function maybe_unserialize that tries to undo it so you never notice

it's something they added to help newish devs who would run into the arrays aren't strings problem, it was popular to just store all your settings in an object or array then save it

but PHP serialising has security issues, and it would be a major backwards compat break to remove that "helper" code

DevelJoe

yeah I saw that. But the thing is, retrieiving via get_post_meta() works perfectly. The only case where it's retrieved value is null is if retrieved via REST in the way explained above.

Tom J Nowell

so add_post_meta( 123, 'mymeta', [ 'Im an array'] ); is effectively add_post_meta( 123, 'mymeta', serialize( [ 'Im an array'] ) );

DevelJoe

@TomJNowell understood

bosco

16:24

Well at a glance, the sample data validates against the schema (at least when converted to proper JSON Schema) - I'll need to load it into a WP environment to see what's really going on. There might be some hint if you try to POST to the REST route to try and add/update that meta

POST /wp-json/wp/v2/my_custom_post/{some post id}

{
  "meta": {
    "my_meta_field": {
      {
        "first_name" : "DévelJ",
        "age" : 28,
        "gender" : "m",
        "languages" : [ "en", "de" ],
        "locations" : { "unitedstates" : [ "Colorado", "Washington" ] }
      }
   }
}

@TomJNowell I'll have to read up on that - I was unaware of security issues with PHP's serialization 👀

Tom J Nowell

the issue is that you can pass along serialized objects which can execute code when they're deserialized

bosco

16:39

ahhh that makes sense

Fascinating

There's a little JavaScript-based "hacking" game called "hackmud" - we used to use some similar methods to exploit each other's scripts by passing around values with overridden serialization methods and dynamic accessors. I never considered how they might apply to PHP

Oh wow unserialize just operates in the global scope - that's crazy

I still don't quite understand the mechanism of some of the examples - but it is scary enough to put me off of using PHP serialization on user-supplied values 👀

bosco

17:26

@DevelJoe it looks like this is a quirk of WP's schema - SallyCJ sorted out the solution here. The type of the object for which you're oneOfing the rest of the definition should be set to null

e.g.

[
  'type'  => null,
  'oneOf' => [ /* ... */ ]
]

I'm clear as to why - it may be worth some digging. It looks like a bug to me, but maybe there's a good reason for it

bosco

17:46

*unclear

Tom J Nowell

18:00

that's cropped up enough that there should be a bug report for it

2 hours later…

bosco

19:42

@TomJNowell At a glance, I'm not finding any definitively related tickets - but I'll dig around a little more, and if necessary, attempt to sort out the specifics and open a ticket this week

« first day (3 days earlier) ← previous day next day → last day (18 days later) »

all rooms

Transcript for

Aug28

Aug '2229

Aug30

Discussion between bosco and DevelJoe

Imported from a comment discussion on wordpress.stackexchange....

custom-post-types php post-content rest-api wp-query

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC