Add validation error reporting for plugins and themes #971
Conversation
If a <script> or stylesheet gets removed, store it in $removed_assets. There isn't yet a way to report inline scripts. Like <script type="text/javascript">myFunc();</script>. This uses the 'src' attribute to find the plugin or theme.
Iterate through all of the registered callbacks. If a callback is from a plugin and outputs markup, wrap the markup in comments. Later, the sanitizer can identify which plugin any illegal markup is from. Thanks to @westonruter for this strategy.
Also, address a Travis error. Instead of testing for the presence of 'amp-wp,' simply make it 'amp.' This plugin seems to be in the directory 'amp-wp' in the Travis tests.
The plugin is in 'amp-wp' in some Travis tests. So instead of expecting the plugin to be 'amp,' Simply expect it to contain 'amp.'
Add an extra parameter to track_removed(). If $source is passed, store that. Then, if a node is removed, look for the presence of $source.
If the query var of 'validate' is present, Output the previous validation response, like on the post.php page. But also add a 'plugins_with_invalid_output' value. This includes all of the plugins that output markup which had removed elements or attributes.
This might have caused issues, as the order of assignment is different in PHP 7.0. So insted, access the array values.
Substitute all uses of 'remove_invalid_callback' With AMP_Validation_Utils::CALLBACK_KEY.
Mainly use the logic in WP_Hook::apply_filters(). This accounts for the number of accepted args.
|
Figuring out where to display validation errors is tough. Normally this is something that we'd want to show in the admin bar, but this isn't available to us… yet. I think it should be a goal for us to get the admin bar to be fully supported, and then we can show the errors in it. But otherwise, what we may want to do is introduce a new admin screen for “AMP status”. This could eventually interface with the Google Search Console, maybe, to get an external view of AMP validity. This can be augmented with an internal view of validity, being populated with the results of what you are building here. Maybe what we should do is introduce a new By having the errors logged then a user could be informed of them asynchronously, and with the original URL being present, the validation errors could be re-checked after the fact. There could be a button like “Re-check”. Duplicates should be avoided. So I suggest storing the validation error and the responsible plugin/theme in the post content and then taking the data and creating an md5 hash which then can be used as the Eventually we'll want to include a WP-CLI command to crawl the entire site and find all validation errors with these being all logged. |
westonruter
force-pushed
the
add/842-plugin-validation
branch
12 times, most recently
from
439a233
to
d968626
Compare
westonruter
force-pushed
the
add/842-plugin-validation
branch
from
d968626
to
0484bd9
Compare
In the PHPUnit test class, there's no need to declare the methods statically. Also, this adds assertions for a plugin function that doesn't output anything.
Also, remove add_header(). Adding a response header isn't part of the plan.
After the preprocessors have run, get the validation response. If a plugin output invalid markup, store the response in a custom post type.
The <ul> in print_validation_errors_meta_box() is only indented, with almost no change. Its class is moved to the new parent <div>. If the recheck reveals no errors, it redirects to the CPT edit.php page. And displays 'The rechecked URL has no validation error.' If it still has an error, it stays on post.php, with a message stating that the error remains. @todo: consider a scenario where there is more than 1 URL. On rechecking and finding no error, it might make sense to redirect to redirect to that same post.php page. The user might want to then recheck all of the URLs. It's likely that the error won't exist there.
|
URLs on /wp-admin/post.php Hi @westonruter,
|
* Remove needless lookup of post when it is passed as $post in print_status_meta_box. * Fix markup.
* Generalize remove_invalid_callback to be validation_error_callback; intend to pass validation error array, not just node. Merge track_removed into add_validation_error. * Check for stylesheet length overage while iterating over stylesheets; report validation error once reached instead of outputting HTML comments. * Report CSS mutations when removing !important and overflow from stylesheets. * Report validation errors regarding amp-keyframes.
|
Additional potential todos:
Future ideas:
|
… possible * Move validation logic from theme support to validation utils * Eliminate saving of validation status post when doing GET request; only store validation errors by invoker.
…with duplicated name
westonruter
changed the title
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.
This pull request for #842 shows which plugin echoed invalid markup.
If the user has the
'edit_post'capability, and the query var ofamp_validateis present, it adds a response header.This has all of the data the the response on
post.phphas, in addition to a'plugins_with_invalid_output'value. This array has all of the plugins that output invalid markup.But maybe this isn't the best way to display an error.
The main item remaining for me is the failed Travis build. The tests seem to stop, without error, on PHP < 5.5. This might be related to the closure.
Fixes #842.
Fixes #843.