-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add filters on taxonomy and post page #1373
Conversation
Like Weston suggested, add this to the amp_validation_error term description. This will aid in searching that taxonomy page by error type. At the moment, there are only 3 types: HTML, JS, and CSS.
@@ -436,6 +436,11 @@ public function prepare_validation_error( array $error = array(), array $data = | |||
if ( ! isset( $error['code'] ) ) { | |||
$error['code'] = AMP_Validation_Error_Taxonomy::INVALID_ELEMENT_CODE; | |||
} | |||
|
|||
if ( ! isset( $error['type'] ) ) { | |||
$error['type'] = 'script' === $node->nodeName ? AMP_Validation_Error_Taxonomy::JS_ERROR_TYPE : AMP_Validation_Error_Taxonomy::HTML_ERROR_TYPE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also needs to be a js_error
if it is an invalidate attribute and the attribute starts with on
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. 3e9a81e sets a js_error
for on*
attributes:
For example, onclick. This will have JS in it, so this error code is more accurate. On Weston's suggestion in code review.
These were for an onload attribute, so update them for the latest commit.
Just realized you intend to do more on this PR before merging.
Borrowing heavily from: add_group_terms_clauses_filter(), filter the 'where' clause, to filter the taxonomy page by type.
Beginnings Of The Query Var For Type Implemented Borrowing heavily from add_group_terms_clauses_filter(), 3433791 adds a query var that can filter by error type on the 'AMP Validation Errors' taxonomy page. But this still needs the filter UI. For example, this URL will only show CSS errors: |
On clicking the 'Filter' button on the 'AMP Validation Errors' taxonomy page, edit-tags.php processes the POST request that this submits. Then, it redirects to a URL to display the page again. This filter callback looks for a value for VALIDATION_ERROR_TYPE_QUERY_VAR in the request. That means that the user filtered by error type, like 'js_error'. It then passes that value to the redirect URL as a query var, So that the taxonomy page will be filtered for that error type. @see AMP_Validation_Error_Taxonomy::add_error_type_clauses_filter() for the filtering of the 'where' clause, based on that query var.
Allows filtering by error_type, like only viewing JS errors. This UI now works for error_type, though work is probably needed for accepted status.
This still doesn't use the new terminology, like 'Identified.' There wasn't much to change, as filtering by error type worked thanks to Weston.
Though these views are now applied in a <select> filter, this uses much of their infrastructure. Also, it uses their counts for each status. For example, if there are 0 accepted errors, this won't display the <option> for 'Accepted Error'.
Create a new constant, NO_FILTER_VALUE. This is for the existing value of -1. And add this to the whitelist: in_array().
Filtering By Error Status The UI to view errors by status is now in a This uses the existing work to filter by status, and merely applies it to the |
Change this to 'Errors by Type,' to match the Sketch design.
Add Counts To Dropdowns Based on @westonruter's suggestion, I'll add counts to the error status |
There were counts earlier, when filtering by status was done by clicking an <a>. Thanks to Weston's work. Mainly copy the previous logic to add the counts.
Error Counts Applied caa2a26 applies the error counts, mainly copying the logic that was previously used for the |
Before, there was only HTML_ERROR_TYPE. Based on comments in issues like 1361, this adds 2 types of errors for HTML.
The AMP validation error page also needs these filters, but it doesn't need all of render_taxonomy_filters(). So abstract it into 2 functions that can be reused.
Using the functions created earlier, output the filter <select> elements on this page. There's more work remaining, like ensuring the query vars work.
Mainly by using the method that Weston wrote: filter_posts_where_for_validation_error_status() Look for the query var of the error type. And if that's present, add to the WHERE clause.
This is at the top of the taxonomy page (Errors by Type), and links to the post page (Errors by URL).
AND | ||
$wpdb->terms.term_group = %s | ||
AND | ||
$wpdb->term_taxonomy.description LIKE %s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This addition to the WHERE
clause is the same as before, except for the 2 lines above:
AND
$wpdb->term_taxonomy.description LIKE %s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it'd be better to search the amp_invalid_url
post content for the correct error_type
, instead of searching the amp_validation_error
term description
, like it does here.
I think that's what you suggested here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but what you've done here seems fine as well.
Instead of an if block for most of the method, simply return if the condition is false. Then, the remaining if blocks aren't nested.
Before, that didn't take account of the filter for error type So if that filtered for js_error, the total count of error status was the same as if it were for 'All Error Types.' So look for the query var for the error type, and pass that to the WP_Query if it's valid.
…rors' This is how the text was when it was inside a link. Check for the current screen, and conditionally add the 'With'.
… redirect Before, the filter for the redirect URL did not accept -1, which is for 'All Error Types' and 'All Statuses'. This means that the URL sometimes did not redirect, and it sometimes showed the same results as before.
Make PHP DocBlocks more clear, especially when they needed to be updated.
* On the 'Errors by URL' page, the <option> text should be different. | ||
* For example, it should be 'With JS Errors' instead of 'JS Errors'. | ||
*/ | ||
$possible_with_text = 'edit' === $screen_base ? __( 'With', 'amp' ) : ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not able to be properly translated.
|
||
} elseif ( 'edit' === $screen_base ) { | ||
// The post page should have <option> text like 'With New Errors'. | ||
$possible_with_text = esc_html__( 'With', 'amp' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not properly translatable.
Unfortunately, such variations in language require duplicating the entire strings.
…ion when changing selected error type
Request For Code Review
Hi @westonruter,
Could you please review this PR for error status and type filters?
Because
amp_validation_error
terms now has atype
in thedescription
, you might want to delete from your local environment all of theamp_invalid_url
posts andamp_validation_error
terms. And then run the WP-CLI validation again.amp_invalid_url
post (edit.php) andamp_validation_error
taxonomy (edit-tags.php) pages. This modifies the existing status links from before.type
to theamp_validation_error
termdescription
.html_element_error
,html_attribute_error
,js_error
, andcss_error
.Closes #1360, #1363.