bosco

Nor, evidentally, the details of how it came to be a part of the WP project.

I was a big fan of Gutenberg those first couple years, but it had more to do with it's code and architecture and supporting tooling than anything else. I liked the DX and likely never gave the UX and impact on the project and ecosystem enough consideration

Sometimes I really love it and others I despise it... but I guess that describes all tools, really

I've tinkered with it a bit for mostly non-code things, but that was a model or two ago. I'll have to give it another run now that some time has passed. I've been using Co-pilot for many months now and I still can't figure out if it's helping or hurting me

@MarkKaplun I was just sifting through the "Year in review" data in meta out of curiosity. It does sort of look like things were slowing down even prior to this year... I guess in retrospect things were feeling a bit quieter each time I returned. And most of the old-guard have moved on. It all bums me out a bit, albeit among many compounding issues.

I'm kind of surprised that the conflict isn't spilling over into WPSE, given the shennanigans elsewhere. I came here to put out fires, but there's nothing to cook my smores over.

Oh, definitely! I had a vaguely similar experience there where a plugin's JS in a closure would DOS the site if left to run in an open tab for many hours... My hack-around was quickly obsolete thanks to their quick patch

Definitely! It always felt dirty to me. One scenario was exactly as you described. I couldn't fork or modify the plugin, but I needed a reference to a class instance which was unobtainable outside of the hook's callable.

@kero @TomJNowell thank you very much - I really appreciate that input :)

If there is no other means to achieve a specific result, would it be an egregious hack to dig a third-party hook out of $wp_filter, remove the registration, and add a new one which wraps a manual execution of the original callback with my own functionality? I've used this to enact a temporary patch under heavy restrictions a couple times before - but I have to imagine such a practice would not be considered fit for distribution in a public plugin?

ayyyy we're back

Man I understand your frustration now

@DevelJoe I can't get it... even with modifications to the schema which would be permissible in JSON Schema, like setting common properties and oneOfing additional property sets. I think this reveals some other issues with WordPress's implementation - I'd like to dig in further, but it may have to wait for now

hmmm

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

@DevelJoe sure!

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.

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!

:P

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

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

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

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

totally fair, I'd get that, lol

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

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

that looks correct to me - generates the right token

ahh gotchya

@DevelJoe You're making the request from PHP?

@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 I feel that - totally my last few days on a project

Where are you making the request from?

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

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

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

@DevelJoe excellent!

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

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.

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

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

Like Postman:

But most HTTP thingies have a shortcut

A lot of the GET requests are completely public, but most every request which can modify data will require 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

That'd be authorization rather than authentication

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

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

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