Provide an API to validate block input, either client-side or server-side

Issue Overview

Sometimes it is crucial to validate input values on the server side, e.g. check if an email address is valid within the company by checking against an LDAP-Directory. (Server side because "Never trust the client" rules).

I could not figure out (overlooked?) a way to do that with Gutenberg.

Steps to Reproduce

1. Hook into rest api (pre_insert_post?) and return an error, something like
   return new WP_Error( 'rest_invalid_param', 'E-Mail not found in directory', array( 'status' => 400) );
2. 'Updating failed' is shown, but not the specific error message.

Possible Solution

• Document how to return an error (better a list of errors) correctly.
• Display the error messages.

In a second step it would be helpful to trigger a JS event in the corresponding block, so that a visual feedback can be given in the right place.

PS.
Is there some kind of validation framework present/planned in Gutenberg that i did not see?

[danielbachhuber]

👍 I agree with the general premise that it should be possible to validate block values (either client-side or server-side) and display an error when they're invalid.

[gziolo]

@adamsilverstein can you help answer this question? I'm not familiar enough with REST API integration with Gutenberg but I would assume you can use server-side hooks. The only remaining question is how to propagate that response to the client properly, i.e. how to shape the response to make sure it can be understood by Gutenberg. I think we use notices to display messages, so this might work out of the box.

[danielbachhuber]

Worth noting: the Customizer already has a validation API like this. As Gutenberg and the Customizer will eventually need to reconcile, it might be worth cribbing from the Customizer if we can.

cc @westonruter

[westonruter]

And the Customizer's validation API is designed to feel like the REST API's validation API. With the move to defining all block attributes server-side and having them exported to the client (see #2751) then this means we can amend the attributes schema with things like sanitize_callback and validate_callback to use during validation. The REST API endpoint to insert/update a post could run through the block validate/sanitize callbacks prior to saving the post content.

[gziolo]

@westonruter, I started working on moving the definition of all block attributes server-side in #5802. The idea is to have also a filter on the server which allows plugins to add some automated changes to all blocks. I was thinking about adding validation step just before all those definitions are exposed to the client. If you have some insights how this should be implemented, please leave a comment on #5802. In general, this blocks definition should be exposed as new REST API endpoint in the near future. So all that you shared aligns with what we are exploring at the moment.

[adamsilverstein]

@gziolo

can you help answer this question? I'm not familiar enough with REST API integration with
Gutenberg but I would assume you can use server-side hooks.

yes, the current REST API endpoints all include hooks at multiple points - before the query, on the response, etc. as long as you can identify the request, you can add whatever filter you want.

[westonruter]

@gziolo @adamsilverstein @danielbachhuber Something else that comes to mind in relation to block validation is allowing pre-parsed blocks to be exposed in the REST API response. I think this was previously talked about as /wp/v2/posts/:id/blocks or something. But that seems to be disconnected from the fact that the blocks are (for now) mostly managed as part of content. So what if just as we have content.raw and content.rendered we also had content.blocks? This could be an array data structure of blocks (and their nested blocks). A client could then manipulate the blocks in their parsed representations and then PUT back the modified content.blocks data to update the post. This is where the validate_callback and sanitize_callback functions could be called on the blocks, in the rest_pre_insert_{$this->post_type} filter. If there is a validation error the filter could return a WP_Error to cause prepare_item_for_database to return an error and thus cause update_item to be rejected.