Opened 4 years ago
Last modified 4 months ago
#40878 assigned feature request
Adding menus route
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | high |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | has-patch has-unit-tests needs-dev-note |
Focuses: | rest-api | Cc: |
Description
Currently there is no ${appUrl}/wp-json/wp/v2/menus
route inside REST API for WordPress.
I know I can create a custom endpoint and define a route for it, or use a plugin, but wouldn't it be better to have it in the core?
I couldn't find a ticket for this, and inspecting the routes via postman showed no menus
which means that it doesn't exists yet.
Is there any plan to add it to core?
Attachments (5)
Change History (54)
#2
@
4 years ago
Yeah, I'm aware of the plugin, but it seemed like something that would be good to include in the future :)
#4
@
3 years ago
As discussed in Slack #core-js channel, I'm uploading my current code for working with WordPress menus through the REST API.
The basic code works:
menu-locations
endpoint:
This provides basic enumeration, direct access through their slug, as well as linking and embedding the attached menus.
This is read-only, as the locations are defined in code, not stored in the database.
menus
endpoint:
Extension of the terms controller. Provides all terms functionality, with the addition of making the linked menu items embeddable, as this would be a common use case.
menu-items
endpoint:
Extension of the posts controller. Provides all posts functionality, with no customizations as of yet.
Shows the associated menu in the 'menus'
property, which can also be queried: menu-items/?menus=2
.
I assume that these implementations are still missing some subtleties, so consider this a first draft to serve as a basis for discussion.
#6
@
3 years ago
Some additional observations:
A first implementation I did created custom implementations for the menus and menu-items controllers. However, I think the more correct approach is to reuse the posts and terms controllers, and then add whatever information is needed to the post-type/taxonomy registration arguments to adapt them as needed.
With the above patch, the menu-items controller is just the standard posts controller.
The only thing that the additional menus-controller
now does is make the menu items embeddable. But I think that could actually be a default for all post-type/posts relationships.
#7
@
3 years ago
This is read-only, as the locations are defined in code, not stored in the database.
A POST
request could be made on the same endpoint where you provide location name, then a check could be made in the callback function that will check if the location name is taken using get_registered_nav_menus(), and if the check passes one could register new nav menu using register_nav_menus().
I can try to make a patch for this.
Also when I try to apply the patch it fails on src/wp-includes/taxonomy.php
(where 'rest_controller_class' => 'WP_REST_Menus_Controller'
is)...
#8
@
3 years ago
@dingo_bastard : I'm not sure I understand. Doing a POST
request would allow to add a new menu location, but it wouldn't be persisted. Unless you add a new PHP file somewhere, or start storing menu locations in the database, any changes you could make would be gone with the next page request.
#9
@
3 years ago
@dingo_bastard : I uploaded a fresh patch from a clean source tree. Apparently, the previous one started from a changed code base already, sorry for that.
#10
@
3 years ago
Oh right, my bad. I was working on a theme some time ago and we added additional menus via customizer settings, but those get saved in the database. Totally forgot about that.
We could add an option ${theme_name}_registered_menu_locations
that could be saved for each theme and would contain menu locations. Although that would probably be a case for another ticket (one concerning registering menu locations and saving them in the database programmatically).
This ticket was mentioned in Slack in #core-restapi by adamsilverstein. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-restapi by dingo_d. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-restapi by dingo_d. View the logs.
3 years ago
#15
@
3 years ago
40878.3.diff builds on @schlessera's earlier patch. I didn't see a controller for menu items, so this extends the WP_REST_Posts_Controller
for GET requests to menu-items
. You can now make requests like:
GET /wp/v2/menu-items/
for a full list of menu itemsGET /wp/v2/menu-items/:id
for a single menu itemGET /wp/v2/menu-items/?menus=2
for a list of menu items in menu with ID=2
I've added these so that we can get a Custom/Navigation Menu block in gutenberg, see this issue & PR. These are read-only, and they contain the extra menu-related fields like target
, classes
, attr_title
, etc. This also replaces the post's link
with the menu destination link (the link to the nav_menu_item
post type does not exist).
For reference, the endpoints from schlessera's patch:
GET /wp/v2/menus
for a list of available menusPOST /wp/v2/menus
to create a new menu (taxonomy object)GET /wp/v2/menus/:id
for a single menu objectPOST /wp/v2/menus/:id
to update a single menu objectDELETE /wp/v2/menus/:id
to delete a single menu objectGET /wp/v2/menu-locations
for a list of available menu locations (theme-dependent)
You can also do an OPTIONS
request on any of these to get more info.
Deleting a menu does not delete the sub-items in the menu, I think we'd want to call wp_delete_nav_menu
in the menus controller. This also doesn't include any tests.
Note, the two uploads (40878.diff & 40878.3.diff) are the same file, re-uploaded to get the .3
#16
@
3 years ago
@ryelle Erm... I'm pretty sure I coded a menu items controller (you can even see screenshots of its output above). Not sure what happened to it and why it wasn't in the patch, but I'll try to find the code and compare with yours to see if we did the same thing.
This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.
3 years ago
#18
@
3 years ago
I looked through my code to see how I handled the menu-items
endpoint.
I basically just reused the posts controller, by adding the following to the register_post_type()
call for the nav_menu_item
post type:
'show_in_rest' => true,
'rest_base' => 'menu-items',
'rest_controller_class' => 'WP_REST_Posts_Controller',
Through all the built-in mechanisms that the controller, and more specifically the posts controller provide, this allows for all general manipulations you might need.
Of course, as soon as we want to add menu-item-specific code, we'd need to extend the posts controller anyway, so @ryelle 's approach above makes sense.
This ticket was mentioned in Slack in #core-restapi by danbeil. View the logs.
3 years ago
#20
@
2 years ago
Will this be added in the 5.x release? It would be a nice feature to have out of the box.
This ticket was mentioned in Slack in #core-restapi by dingo_d. View the logs.
2 years ago
@
22 months ago
Implemented REST API endpoints for menus, menu items, menu locations, and menu settings.
#24
@
22 months ago
My latest attachment includes fully functional API endpoints for menus, menu items, menu locations, and menu settings.
There was a good bit of logic that is part of the wp_wpdate_nav_menu_item()
function that needed to be duplicated to get it working properly in the menu items endpoint. One of these was the handling of orphaned menu items.
I made menu locations writeable, but only for updating the menu ID assigned to a menu location.
Menu settings is a new introduction that provides access to the auto_add
option to automatically add top-level pages to a menu.
With all of these endpoints, it would be possible to completely replace the existing screen under Appearance
-> Menus
with a single page JavaScript app.
These endpoints are key to the initiative being explored here: https://github.com/WordPress/gutenberg/issues/13206
This ticket was mentioned in Slack in #core-restapi by wpscholar. View the logs.
22 months ago
This ticket was mentioned in Slack in #core-restapi by wpscholar. View the logs.
22 months ago
This ticket was mentioned in Slack in #core-restapi by wpscholar. View the logs.
21 months ago
This ticket was mentioned in Slack in #core-restapi by spacedmonkey. View the logs.
21 months ago
#29
@
21 months ago
- Keywords needs-unit-tests added
Thanks for everyone's work on this. I spent some time reviewing the patch and on the face of it looks good. But I personally believe that there is no way to have a meaningful code review via svn patches. I can not do code level reviews and discuss this. Any feature of this size, should start as a feature plugin.
To that end, we already have a feature plugin for this at wp-api-menus-widgets-endpoints. @wpscholar if you could take your patch and make it a pull request on that repo, we can work on it there. Once we have a solid api there, we can create a core patch from that, that should just a copy and paste in core.
#31
@
21 months ago
@spacedmonkey PR created: https://github.com/WP-API/wp-api-menus-widgets-endpoints/pull/21
#32
@
20 months ago
- Milestone changed from Awaiting Review to Future Release
- Owner set to spacedmonkey
- Status changed from new to assigned
After today’s api dev chat. We agreed that the pr, should be merged as is and work on the code from there.
We need to work on unit tests, but we need to do that after finalised the design of the api.
#33
@
20 months ago
Spent some time on this PR - https://github.com/WP-API/wp-api-menus-widgets-endpoints/pull/22 . I think it has a future, as it is pretty simple and easy to implement.
These endpoints, use override WP_REST_Terms_Controller
and WP_REST_Posts_Controller
, with some slight modifications.
If someone else from the REST API team could review, that would be extremely useful.
#34
@
19 months ago
I have merged the last PR so we now have a functional feature plugin.
I am working some two new PRs.
These PRs have been done on my fork, but future PRs will be done as branches. Any subscribed to this ticket, please give comments to these PRs.
#35
@
8 months ago
- Keywords has-unit-tests added; needs-unit-tests removed
- Milestone changed from Future Release to 5.5
- Priority changed from normal to high
The plugin has been merged into Gutenberg. Milestoning for 5.5 to handle the core merge. The navigation block is a 5.5 priority.
This ticket was mentioned in PR #319 on WordPress/wordpress-develop by spacedmonkey.
8 months ago
Feature plugin - https://github.com/WP-API/menus-endpoints
Trac ticket: https://core.trac.wordpress.org/ticket/40878
#37
@
8 months ago
- Keywords needs-dev-note added
- Owner changed from spacedmonkey to TimothyBlynJacobs
I have created a pull request ready for review and merge in 5.5.
Assigning to @TimothyBlynJacobs for review.
#38
@
8 months ago
TimothyBJacobs commented on PR #319:
We need to add @ticket
annotations for the tests.
I'm also going to hold off on committing this until the Gutenberg merge happens for 5.5.
This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.
8 months ago
#40
@
8 months ago
spacedmonkey commented on PR #319:
We need to add
@ticket
annotations for the tests.
I'm also going to hold off on committing this until the Gutenberg merge happens for 5.5.
Ticket number and version number comments added.
#41
@
7 months ago
- Milestone changed from 5.5 to 5.6
The Navigation Screen and Navigation Block are no longer shipping in WordPress 5.5. Based on our discussion in #core-restapi and @SergeyBiryukov's feedback I'm going to move this to 5.6. I know this will be a disappointment, but I think landing these endpoints with first party usage is critical to make sure we nail the API surface.
#43
@
7 months ago
TimothyBJacobs commented on PR #319:
Is this for the navigation screen? If so, not sure if it should be merged now.
Yes. I removed it from the milestone Saturday.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
5 months ago
#45
@
5 months ago
- Keywords needs-refresh added
Adding needs-refresh
due to PR 319 having merge conflicts.
#46
@
5 months ago
- Keywords needs-refresh removed
@hellofromTonya I have refreshed the PR, so there are now no merge conflicts.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
5 months ago
#48
@
5 months ago
- Keywords dev-feedback removed
Removing keyword per today's <bug-scrub>
discussion.
Also capturing the note from @TimothyBlynJacobs: this ticket will "probably be merged to Core when the Gutenberg merge happens closer to beta."
#49
@
4 months ago
- Milestone changed from 5.6 to Future Release
Removing this from 5.6 per https://make.wordpress.org/core/2020/10/01/navigation-screen-removed-from-5-6-release-features/.
There are no immediate plans to add support for menus to the REST API, and throughout 2017 the plans for the REST API only consist of stabilising the existing endpoints and looking into implementing them in the WordPress admin area.
There's a plugin available which adds support for menus in the REST API though: https://wordpress.org/plugins/wp-api-menus/