Migrating experimental navigation and widgets screen to bulk REST API

[adamziel]

Both navigation and widget management screens are interacting with the API using suboptimal methods. One of them reuses the customizer endpoint, the other sends multiple requests every time the user hits the "Save" button. Fortunately, the support for bulk API requests is coming as discussed in https://core.trac.wordpress.org/ticket/50244.

One problem there is that there will be a period of time when both screens are going to be available via Gutenberg plugin, but the bulk API support is only going to be available in latest WordPress trunk. This means that some users attempting to test the feature won't be able to use the full power of bulk API (including pre-validation), and will potentially experience partial errors on save.

There are a few ways to address it, the consensus at the moment seems to be improve the validation and catch most errors client-side before issuing any request. For the experimental feature it doesn't sound too bad. Even with 100-200 requests required to save the navigation, we could catch most errors client-side during the validation. As long as the user don’t close their browser during the save, it should work fine 90%+ of the time. Slowly, true, but consistently for the most part. The transition period will not be too long either, and once WordPress 5.6 gets released everyone will have access to the bulk API.

Does that make sense? Does anyone think there's a better way?

CC @draganescu @TimothyBJacobs @noisysocks @talldan @mtias

[noisysocks]

Could we have Gutenberg polyfill the functionality added in Trac#50244 if it doesn't already exist?

[TimothyBJacobs]

The plan is to polyfill as much of the functionality as possible, but it won't be able to support pre-validation because it requires extensive refactoring to WP_REST_Server::dispatch() that would be very difficult to do in Gutenberg.

[draganescu]

Blocked on #25096

[adamziel]

Now that #25096 is merged this one may be picked up, although keep in mind it will be affected by #25958.

[adamziel]

The more I think about it the more I'm convinced that the widgets editor should address this in the same (or related) PR as the migration to #25958.

[adamziel]

This is now ready for dev since #25958 and #26042 got merged. Two related issues/PRs that could potentially address it:

• First pass at using the new sidebars and widget endpoints. #26086
• Support batch requests in data layer #26024

[adamziel]

This PR could affect batch processing: #26389

[noisysocks]

Just flagging a thought I had: If we implement previewing on this screen (and I think we should), we'll probably want to use a REST API for creating and publishing changesets instead of the batch processing API.

https://core.trac.wordpress.org/ticket/38900

[noisysocks]

Unassigning @adamziel as I know he's moved onto bigger and better things 😛

[noisysocks]

I'd consider this ✅ done for the widgets screen. #28210 rewrote the batch processor into something which I think can eventually serve as the final API.

I'll leave the issue open though since I think the navigation screen needs to be updated cc. @talldan.

[talldan]

As mentioned above, batch saving was implemented as part of the widgets work (#28210).

For menus, I think the reorder endpoint is currently needed to allow saving via the REST API - #25093

There’s some more background about why this is required in #21964.

[spacedmonkey]

Re-sharing here for visibility.

1. The menu items endpoint, already supports batching and has done for a while.
2. Current thinking is we should just use batching functionally and not bother with the reordering endpoint. See REST API: Introduce reorder menu endpoint #25093 (comment)

[spacedmonkey]

@adamziel @TimothyBJacobs Can we close this ticket now that #34541 is merged?

[TimothyBJacobs]

I believe so, I'd wait on Adam to confirm though.

[adamziel]

Thanks for staying on top of that! Yup, we're good here. There are a few follow-up items, but I believe we could track them separately. I'll create dedicated issues today.

[adamziel]

I think these are all the follow-up items:

#35048
#35047
#35046
#35045
#35037
#34999

Edit: Any idea how to make GitHub expand ticket numbers into descriptions?

[Mamaduka]

Thanks, @adamziel

Maybe we should create separate tracking ticket for data-related issues.

P.S. I think GitHub only expands ticket numbers when used with task list - [ ]

[adamziel]

@Mamaduka

Maybe we should create separate tracking ticket for data-related issues.

Which ones specifically?

P.S. I think GitHub only expands ticket numbers when used with task list - [ ]

ah that's good to know, thank you!