Discussion between bosco and DevelJoe

DevelJoe

19:40

Okay I found the first problem with a step debugger. The schema validation successfully validates with the first schema; validation is passed for entirely every single key-value pair, including the nested parts. That even with type="object". The problem seems to be that, in the file wp-includes/rest-api.php, in the method rest_find_one_matching_schema(), the validation continues with the second schema, although the retrieved value has been fully validated.

And this because $stop_after_first_match in the method mentioned above has a value of false. Then, after proceeding with the validation, it of course fails, as the validation fails with the second schema, which no longer matches. Now I just gotta find out by what that $stop_after_first_match value is controlled..

Turns out it cannot be controlled. The core file wp-includes/rest-api.php/` via the method rest_validate_value_from_schema(), calls rest_find_one_matching_schema()with the default value of false for $stop_after_first_match. Ergo, the validation will actually never stop after the first matching schema; leading to the resulting validation always to be null.

@bosco If I do this, "meta" : []is present in the response, so this does not solve the problem.

I guess I'll open a new question about this one; it seems to be a tricky one..

bosco

21:21

@DevelJoe I tested the code locally and it worked for me :/

DevelJoe

It doesn't for me, but I think I'm figuring it out slowly why..

Currently, it's looking like you must completely omit the type key in the array where you specify the oneOf key. Otherwise core scans for a properties key within your array where the oneOfkey lies, resulting in a complete chain of messes

bosco

Omitting the type key did not work for me - only explicitly setting it to null. I certainly haven't dug into the issue as far as you have, but I can provide the specifics of my test in any scenario. The schema I used was identical to the one you provided above, with only that modification: hastebin.com/imohutosif.php

(and registering the meta to post)

Oh hmm

I might have to eat my words - it's not presently reproducing

hmmmm

Oh no it still works - my docker mount broke

POST localhost:8888/index.php?rest_route=/wp/v2/posts/1

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

Both the POST and GET responses contain the meta

DevelJoe

22:05

Can you try to submit or get one that follows suit to the second schema?

bosco

Sure

DevelJoe

thx!

bosco

On a side note, on reviewing my test case, I see now that I omitted the 'type'=>'object' argument for the meta registration. However, after adding it both requests continue to operate as before

DevelJoe

This is precisely the last problem I have! See wordpress.stackexchange.com/questions/409131/…

Due to exactly that type => object mapping, core scans your $args array as an object with your matched schema! This is the last problem I have, actually

You mean you omitted the type => object mapping within $args ? Or within schema?

bosco

DevelJoe

22:09

ridiculous

bosco

@DevelJoe Args, but it seemed to work both with and without it

DevelJoe

hahahhahahah can't believi it

bosco

👀

DevelJoe

The current state of my step debugger shows this:

Works: Checks for the first schema and validates
Works: Checks for the second schema and fails
Works: Verifies that exactly one schema is matched, and store that schema successfully under $matching_schema.

The problem now seems to be that, due to the 'type' => 'object' present within the $args array provided to your schema, it relaunches a new validation with $matching_schema against your $args array, which of course fails, then returns `null` for your meta. That's the current point of failure.

I mean I took so much of your time already, so I feel bad for asking for more. If you still have the nerves to register a custom post type and do it for that one, let me know. But I completely understand if you don't want to..

bosco

Sure, no problem :)

I believe it will be running through the same controller though - should be the same outcome. But happy to confirm

DevelJoe

22:15

Yes there's actually little difference in between register_post_meta() and register_meta(), I can't imagine that it returns something different. If the result is the same, I'll do just do two different meta fields and relate the retrieval to the value of a custom taxonomy to know which one to retrieve.

bosco

register_post_type(
'djpt',
[
'label' => 'DJPT',
'public' => true,
'show_in_rest' => true,
'supports' => ['title', 'editor', 'custom-fields'],

]
);

damn chat formatting!

Successfully POST/GET'd the meta on the CPT there as well

You might try deleting your stored value and POSTing it instead of add_post_meta(), just to be absolutely sure it's validating

DevelJoe

thank you so much! but it's absolutely weird; I'm about to give you my production data

yeh lemme try a POST

bosco

(not that any of this is a fault in your approach - you've totally gotten eyes-deep in a substantial core bug 🤣)

DevelJoe

22:34

401 rest_cannot_edit error

POST {{scheme}}{{host}}{{wp_rest}}my_post_type/184
Content-Type: application/json

{
"meta": {
"my_meta_key": {
"hello": "there"
}
}
}

That's the intended payload, right?

bosco

Yep - but I take it you're not authenticating?

DevelJoe

nono

and I've even added an auth_callback returning true

just in case

bosco

That'd be authorization rather than authentication

Easiest way to authenticate for dev is to create an "App Password" for your user Dashboard > Users > {User profile} > scroll to the bottom, add a new one titled whatever

DevelJoe

huh but all of my other REST requests never required that??

bosco

A lot of the GET requests are completely public, but most every request which can modify data will require authentication

You'll pass your username and app password concatenated with a colon and b64 encoded as a header:

Authorization: Basic YWRtaW46dmZOcSBFa2I0IGVPUGggYUpUYiBERVg1IEJxdXo

But most HTTP thingies have a shortcut

Like Postman:

When you get around to making sensitive requests from your frontend, you'll want to use some other authentication mechanism, like passing around NONCEs alongside the WordPress cookies

> A lot of the GET requests are completely public, but most every request which can modify data will require authentication

That is, for the core routes, anyway. The core routes' authorization is handled automatically based on user roles/capabilities - if a piece of content would usually be publicly available on the front-end of the site, so too is it on the REST API. If a WordPress user has the capabilities to manage users or plugins on the dashboard - so too will they be able to over the REST API.

You can use the automatic roles & capabilities checks for your own routes - or customize them however you see fit with those auth_callbacks

DevelJoe

22:47

yesyes that stuff is clear don't worry

I've also coupled that stuff to the session management, and related an additional nonce I generate (as you must set the REST's nonce value to wp_rest) to something related to the session ID, retrieved post-authentication

Man I can't get the authentication working

b64(username:password), you say?

bosco

@DevelJoe excellent!

@DevelJoe IIRC yes, but it's been a minute since I've done it manually

DevelJoe

oh what you're saying is actually a plugin

according to this here

bosco

@DevelJoe It's listed as a plugin in the devhub right now, but it's since been merged into core

Yeah - btoa(${username}:${app password}) in JS gives me the right token

DevelJoe

Man

today literally nothing's working

Like I'm doing exactly this

'Basic ' . base64_encode( $username . ':' . $password )

boom 401

bosco

Where are you making the request from?

DevelJoe

22:51

oh, you need the auth cookie from wp?

I'm making it as normal HTTP request from my local machine

bosco

@DevelJoe I feel that - totally my last few days on a project

@DevelJoe Cookie auth/app password auth are separate mechanisms. You can use one or the other. If you've got cookie auth already working, you shouldn't need to go the app password route - I just find it a lot easier for dev and testing

@DevelJoe You're making the request from PHP?

DevelJoe

@bosco phpstorms HTTP Client

bosco

ahh gotchya

that looks correct to me - generates the right token

don't delete the spaces from the app password, for what that might be worth

DevelJoe

this just does not work

bosco

Maybe also worth a mention that some security plugins disable app passwords by default - but if you were able to see/create one from your user profile, then it should be enabled

DevelJoe

22:57

I'm doing it on my localhost, maybe that's the problem

all of the other requests work

there are no plugins enabled on the site

I think I should just accept that today's not a good day, make two distinct meta values, and that's it ^^

bosco

totally fair, I'd get that, lol

DevelJoe

hahaha

Man I can't thank you enough

Honestly; I've learned so much thanks to people like you, you're awesome

thanks a lot!

bosco

no problem! I find I learn a lot by these sorts of things as well. happy to help where I can

DevelJoe

true!

just a last little question

In your schemas, are you using stuff like additionalProperties etc.?

bosco

Like in the schemas I've written for other things?

DevelJoe

23:07

no for our case

you've literally taken the one I've sent you 1:1

?

bosco

Just about - I think I might have modified some required keywords when I was converting to JSON to test some things in a JSON Schema validator. But otherwise I think it's 1:1 - hastebin.com/imohutosif.php

(well, apart from the type => null, and the type => object arg that's missing from that hastebin)

DevelJoe

okay, thank you so much!

I'm really gonna leave it. If I read null one more time today, I'll get a nervous breakdown

bosco

:P

DevelJoe

You have any idea about how long such bugs take to be fixed? Where can I report that thing?

And you know what. Can I maybe send you a new somewhat more complex schema-couple? Again, I understand if you don't want, but it's literally the last idea I have

bosco

WordPress core issues are tracked in Trac using your wordpress.org profile, and for everything Gutenberg it's just the wordpress/gutenberg GitHub repo. This would go to Trac!

Core issues can take from weeks to... many years in some cases. Given the prominence of the REST API I'd reckon within a release or two, at least so far as to eliminate the current work-around for the strange behavior.

@DevelJoe sure!

DevelJoe

23:21

@bosco oki done

@bosco ok one sec and thanks again!

@bosco ok I prepared something, but it's too large to be sent across the chat

any ideas?

preferences *

bosco

No preferences - if it's a single file maybe just a hastebin or GitHub gist?

DevelJoe

23:38

If you manage to get things working by submitting a new purchase_details meta via add_post_meta() and then retrieve that with the value not being null, I officially give up. If you could exactly use my callback hastebin.com/xanafuteba.php; and not change anything in the schema, that would be really helpful!

Thank you infinitely

Transcript for

Discussion between bosco and DevelJoe