-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Directory: Update endpoints to remove __experimental
namespace
#23528
Conversation
Size Change: +29 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
I think it might make sense to completely drop the tests now that the endpoint will be in core shortly. That matches what we did with the block types controller. |
Test failure looks legit |
I'm probably missing something but how is "moving of end points" from Gutenberg to trunk supposed to work exactly? :) As far as I see there are couple of ways to do this:
Seems 2 is the better way, and that's what is being done here. Then seems that for this PR to move forward all of the php changes have to be committed to trunk first. Then the js changes can be merged, new packages released, etc. |
It's a mess :) I don't think we've done it since 5.0 and the process there was kinda messy IIRC as we started merging things into 5.0 in Core.
I've been told, and don't really like, that the Gutenberg plugin needs to continue to work for 5.3 and 5.4 users. So we need to duplicate the endpoints in Gutenberg and in WordPress. The endpoints won't load in Gutenberg if the user is running trunk since the class is only included if it doesn't already exist ( see lib/load.php ). I think this is really error prone, and not sustainable for the REST API endpoints. We'd need to backport any changes to those endpoints from Trunk back to GB so things wouldn't be out of sync.
I prefer that as well. |
Ah, I see. Yeah, seems quite messy... It's not just the end point php classes, (eventually) other newer code will have to be backported to support older WP. For example Then in 2 above instead of removing the end points from Gutenberg, they will have to be replaced with what's in core trunk before merging the PR. Still seems like the better way to do this. |
I think we also want to update:
|
Didn't we agree to keep this endpoint experimental? |
Not to my knowledge. WordPress/wordpress-develop#359 (comment) |
Ok, if it's ready then 👍 |
Sure, I've removed them in 477d38e
That's what is happening here (combined with #23499). The endpoints here will be the same as what are in trunk, and they all now live at |
Do we want to switch out to the |
I thought that would be a good idea for a separate PR, so that this one is just about the endpoint changes. |
Sounds good! |
b537c3f
to
b8bc247
Compare
Merging this to fix the tests on master. |
Description
This is in tandem with WordPress/wordpress-develop#359, which adds the plugins & block directory endpoints into core under the
wp/v2
namespace. I also had to change how the assets are detected (JS vs CSS), since the regex wasn't matching files with version parameters (see #23499).I also changed the endpoints in gutenberg to use
wp/v2
, to preserve compatibility with sites not on trunk.How has this been tested?
I added a few blocks to a post, they added correctly. I removed some, and saved the post, the unused plugins were uninstalled correctly.