-
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
Update editor sidebar validation notifications #5929
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #5929 +/- ##
=============================================
+ Coverage 75.28% 75.41% +0.12%
- Complexity 5722 5735 +13
=============================================
Files 214 218 +4
Lines 17283 17362 +79
=============================================
+ Hits 13012 13094 +82
+ Misses 4271 4268 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Plugin builds for 17ef326 are ready 🛎️!
|
@delawski FYI: There's a conflict now with |
Thanks for the heads-up. I'll take care of the conflicts when working on the few updates that are still on my todo list for this PR. |
|
# Conflicts: # assets/src/block-validation/sidebar.js
On the build step, I was getting the following error thrown by the `block-validation/icon.js`: ``` Property value of ObjectProperty expected node to be of a type ["Expression","PatternLike"] but instead got "JSXExpressionContainer" ``` Cleaning up the `amp-logo-icon.svg` markup and passing it through svgomg fixed the issue.
@westonruter @jwold With 543ab48 and c37125e a loading state and an API errors handling have been added to the sidebar notification area: sidebar-api-error.movThe error message displayed in the notification is whatever the REST endpoint returns. This might be improved over time. However, since such API-level errors are rather rare I wouldn't worry about that too much at this point. |
This is perfect for now. Great job @delawski ! |
…304-validation-notifications * 'develop' of github.com:ampproject/amp-wp: (77 commits) Summarize cleaned markdown file count Indicate WP_CLI::error() among earlyTerminatingMethodCalls Revert change to WORDPRESS_DB_USER Remove sizereport.config.js Rename env file Move duplicate env vars to file Supply WP related env vars to CLI container as well Debug wp config Remove --quiet flag Use alternative method to execute SQL command Create db before ensuring connection to WordPress Debug mysql command Disable pseudo-tty allocation for docker-compose command Use latest WP image for local env; create database during env setup Update workflow name Use alternative workflow ID Rename workflow Don't run workflow if certain files change Cancel any previous queued or in-progress workflow runs on push to a branch Reduce specificity of CSS selector ...
Sorry for the delay in reviewing. @delawski For validation errors which are reviewed, could you add a white left-border or add additional padding so that the unreviewed and reviewed have consistent alignment: |
@delawski Also, where did the link go to access the Validated URL screen? There should be a details link still. |
The error titles can be much longer than just “invalid element”, especially when translated. Currently the client-side logic is doing something hacky by truncating the title at the first colon. So instead of I think we need to:
Here's a more extreme example of how long the titles can be: Naturally the |
if ( isEditedPostNew ) { | ||
return ( | ||
<SidebarNotification | ||
icon={ <StatusIcon /> } | ||
message={ __( 'Validation will be checked upon saving.', '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.
Would it make sense to move this condition up to be the first after the isFetchingErrors
conditional?
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.
That makes sense, yes.
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.
Done in 56ceb8c.
While testing this I found given a HTML block with the content potential_bug.mp4 |
Bug replicated on the |
</PanelBody> | ||
) | ||
{ hasReviewedValidationErrors && ( | ||
<div className="amp-sidebar__options"> |
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.
Would it be better to place this above the list of errors? One would potentially have to scroll all the way down to see this button (due to viewport constraints or having many errors).
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.
The idea is that this would be clicked infrequently. The main thing a user will care about are the unreviewed issues. The link to show all is there just for curiosity.
Maybe the entire sidebar should be called "AMP Validation" instead of just "AMP" for now? |
That could work as well. |
@pierlon It's simply because your Also see this example code: <?php
use AmpProject\Dom\Document;
$script_first = '<div>
<script</script>
<?php
?>
</div>';
$pi_first = '<div>
<?php
?>
<script</script>
</div>';
$script_first_doc = Document::fromHtmlFragment( $script_first );
$pi_first_doc = Document::fromHtmlFragment( $pi_first );
echo "## script_first_doc\n";
echo $script_first_doc->saveHTML( $script_first_doc->body );
echo "\n\n";
echo "## pi_first_doc\n";
echo $pi_first_doc->saveHTML( $pi_first_doc->body ); Output: ## script_first_doc
<body><div>
<script>
<?php
?>
</script></div></body>
## pi_first_doc
<body><div>
<?php ?>
<script>
</script></div></body> Notice the PHP processing instruction gets rendered inside the |
@delawski Would you open a new issue for adding the pre-publish panel? |
@pierlon @westonruter I've addressed your feedback. I think the only thing left to do is to update the unit tests for the
Yes, I'll create a single ticket for the pre-publish panel and for the panel in the document sidebar. |
const blockDetails = clientId ? select( 'core/block-editor' ).getBlock( clientId ) : null; | ||
if ( clientId && ! blockDetails ) { |
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.
As in aa668d0, we could get here just the block name instead of the entire block object, i.e.
const blockDetails = clientId ? select( 'core/block-editor' ).getBlock( clientId ) : null; | |
if ( clientId && ! blockDetails ) { | |
if ( clientId && ! select( 'core/block-editor' ).getBlockName( clientId ) ) { |
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.
When I think about it, we could actually replace the entire loop with find
method like
- let _hasErrorsFromRemovedBlocks = false;
- for ( const validationError of select( BLOCK_VALIDATION_STORE_KEY ).getValidationErrors() ) {
- const { clientId } = validationError;
- const blockDetails = clientId ? select( 'core/block-editor' ).getBlock( clientId ) : null;
- if ( clientId && ! blockDetails ) {
- _hasErrorsFromRemovedBlocks = true;
- break;
- }
- }
-
- return {
- hasErrorsFromRemovedBlocks: _hasErrorsFromRemovedBlocks,
+ const errors = select( BLOCK_VALIDATION_STORE_KEY ).getValidationErrors();
+
+ return {
+ hasErrorsFromRemovedBlocks: Boolean( errors.find( ( { clientId } ) => clientId && ! select( 'core/block-editor' ).getBlockName( clientId ) ) ),
But I guess it might not be as readable as the loop.
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.
I like that latter suggestion. Go ahead with it!
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.
Sounds good, it's done (in an even shorter form) in 17ef326.
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.
A thing of beauty!
It is a gift!
Ah that makes sense. Thanks for solving the mystery @westonruter 🔍. |
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.
Marvelous work done here 🏆.
hasErrorsFromRemovedBlocks: Boolean( select( BLOCK_VALIDATION_STORE_KEY ).getValidationErrors().find( | ||
( { clientId } ) => clientId && ! select( 'core/block-editor' ).getBlockName( clientId ) ), | ||
), |
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.
Nicely done 👍
Summary
Fixes #5304
Relates to #5741
This PR updates the look and feel of the AMP sidebar, most notably the validation notifications area.
List of collapsed errors:
Expanded error with a long message:
Here are the most important changes included in this PR:
<Sidebar />
component into the newamp-validation-status
components (<AMPValidationStatusNotification />
and<AMPRevalidateNotification />
).<SidebarNotification />
component (along with a dedicated container component).text-overflow: ellipsis
property for error title when collapsed.font-weight
for the reviewed errors.amp-error
-related CSS to a separate stylesheet.<code>
are properly rendered.The new components are meant to be reused in the Pre-Publish Dialogue and in the general Sidebar, in the AMP section.
Checklist