Collect all REST API meta errors at once

[TimothyBlynJacobs]

Currently, when updating meta, we return immediately after encountering a WP_Error. If there are issues with multiple meta keys, you have to correct each value and send a new request one at a time. I think it'd be ideal if we could process all the meta fields and then return all the errors that are encountered at once.

WP_Error supports multiple error messages with the same code, but it does not support multiple bits of error_data for the same code. This would be a problem for the errors that include the affected meta key in the error data. Right now, the REST API duplicates this data for each error with the same code ( WP_REST_Server::error_to_response ). I think we'd need to find a way to retain the error message and data correlation in WP_Error.

[TimothyBlynJacobs]

Going to try taking a look at this for 5.7 now that we can merge WP_Error objects and keep additional data.

[hellofromTonya]

Per Timothy in today's core scrub:

Needs patch probably. Planning on working on it this week

Trac ticket: https://core.trac.wordpress.org/ticket/48823

[hellofromTonya]

​Per Timothy, this ticket is blocked by #46191.

[TimothyBlynJacobs]

Punting as multi error data isn't solved yet.

[desrosj]

This one has not seen any activity during the 5.8 cycle. I'm going to punt to Future Release to prevent repeated punting. But it can be moved back to a numbered milestone at any time.

[spacedmonkey]

This change looks good @TimothyBlynJacobs . I think we can get this in the next release.

[oglekler]

The patch is still applicable, no rebase is needed. @TimothyBlynJacobs and @spacedmonkey what is the next step, testing? If so, we need testing info.

[spacedmonkey]

@TimothyBlynJacobs Can you add testing instructions.

[hellofromTonya]

In discussing with @azaozz, we both have concerns of potential regressions and/or unexpected behaviors due to the code not bailing out immediately with an error, i.e. being allowed to continue processing.

Given how important the REST API is, we're thinking this one is a good early candidate. Rather than committing it right before 6.4 Beta 1, instead commit it when 6.5 Alpha opens.

​I noted:

early would give it a long soak time to potentially discover if there are indeed regressions or unexpected behaviors. For example, the Gutenberg plugin uses the REST API. It's a good candidate to flush out if there are any unknown issues.

@azaozz ​noted:

Yea, thinking it may be a bit risky, and testing it and confirming it doesn't bring a regression would be great

@TimothyBlynJacobs @spacedmonkey what do you both think? Are there risks?

[spacedmonkey]

Let's punt.