…ssues

Remove requirement that amp_debug query var have a value

…y target template elements

Commit ba9365 removed this,
as it wasn't needed for 0.7.
This restores the logic for the REST API,
but not the wp-cron logic.

See PR #971.

The POST to the REST API in the JS file doesn't work yet.
And this doesn't apply a requirement in PR #1019:
'Pass validation errors back in REST API response when Gutenberg saves a post.'
But this is a prototype of a way to display notices for each block, async.
The UX would be like that in the previous PR #902.
As Weston mentioned earlier, edit() is synchronous.
And REST requests to validate content could delay it.
So add a component for 'edit.'
Display a notice, based on the state of isValidAMP.
The REST API request will update the state.

The approach changed,
and I'm going to add a response field to
existing endpoints.

@todo: implement the output callback.
Thanks to Weston's suggestion,
This will enable displaying notices in blocks.

In new field 'amp_validation_errors'.
@todo: we might not always want to output this.
It's mainly useful in the Gutenberg editor.

As Weston mentioned,
we can't use ES6 classes in IE11.
The script is probably going to change drastically,
in how it displays notices for validation errors.
So remove almost all of the existing logic.

Per Weston's suggestion,
if this is Native AMP (canonical),
it will be all posts with 'editor' support.
Otherwise, all REST objects that have 'amp' support.

Abstract existing logic into:
get_existing_validation_errors().
And reuse this for rest_field_amp_validation().
If this doesn't return errors,
make a request to the front-end for them.

Gutenberg doesn't init if the version is below this.
This addresses a failed Travis build.

So far, this only finds if there is an error somewhere.
And it displays a notice below the block.
But it has access to the errors by block name,
though not the specific ID of the block.

The response can have a 'block_name' value.
When it does,
store that specific block's errors,
This enables lookup by the block name
in the edit() method of the block.
@todo: consider keeping this in a store.
And find the specific block to which they belong.
Not only the block name.

To address a failed Travis build.
Also, change the text,
so that it can apply to singular an plural.
'invalid AMP' instead of 'AMP errors.'

Before, this got the block errors from getCurrentPost(),
in every block's edit() method.
Instead, store these in the module,
every time there is an action.
It would be better to use a reducer
for a specific action.
But so far, I haven't found a way to do that
for REQUEST_POST_UPDATE_SUCCESS.

module.blocksWithErrors stores errors by block name.
In the block edit() method,
it needs to find if it has the specific errors.
So find if the errors exist in the content
by searching it for the node_name,
and the attributes and properties.
@todo: account for other errors,
like enqueued scripts.

This is now at the top of the function scope.
Also, move 2 nested if blocks into 1 block.

As Weston mentioned, they will be useful
in matching the specific block to the errors.
This will make it much easier to access them.

This was actually in source, not blocksWithErrors.
So change it to source.

This can match blocks that add a stripped script.
Like the 'Categories' block.
That wasn't part of the content,
so it wasn't found before.
Also, refactor existing logic into:
doNameAndAttributesMatch().
This is better in a function,
as it uses a for loop to return a value.
Otherwise, it would need to set a flag.

This follows the convention in WP.
And update the notice text for this.
It was below the block before,
as the edit() function sometimes found errors quickly.
And this moved the block lower,
as the notice took the space of the block.

This links to the post.php page with the errors.
Use the component ExternalLink.

For example: This core/html block has invalid AMP: invalid_attribute, invalid_element.
@todo: consider having counts for each,
like in the classic editor notice.

Mainly uses Weston's work from:
AMP_Validation_Utils::output_removed_set().
@todo: address an case where multiple blocks
have the same error.
Their count is then higher than it should be.

'doNameAndAttributesMatch' has a complexity of 9.
So refactor part of it into:
getAttributesKey().

There were duplicate counts when blocks has
the same errors.
For example, if 2 HTML blocks have 'onclick' attributes.
Of if there are 2 Categories blocks with a dropdown.

It seems like each of these should have different keys.
And other examples of this in Gutenberg have keys.

There were 2 trivial conflicts:
class-amp-validation-utils.php
test-class-amp-validation-utils.php
Also, there was a failed test in:
test_enqueue_block_validation.
So I removed the : from
'This %s block has invalid AMP'.

There was a comma after the argument for:
result.unshift().

…ld in POST/PUT requests

Tidy jsdoc

* Fix population of notice children.
* Show simple list of error codes for now.
* Remove PHP-exporting of validation status post since needs to be dynamic REST field.
* Replace extraneous hasOwnProperty with simply key existence checks (since object literals).
* Add some todos.

Stop iterating sources for validation error once inner-most block is matched

Remove jscs

…rrent post

* Include post_id and block_content_index in block sources.
* Prevent reporting validation errors for blocks that are not in the current post.
* Include block_content_index for improved alignment between blocks and validation errors.

… errors

* Use custom store for block validation errors
* Connect extended BlockEdit to block validation errors via withSelect HOC.

This helps ensures that the validation errors in the response will properly align with the ordered blocks in the editor.

…ice messages

Props @gziolo

…dd/block-validation