Show an orange bullet in the sidebar analysis when a recommended block is removed#1116
Show an orange bullet in the sidebar analysis when a recommended block is removed#1116johannadevos merged 31 commits intodevelopfrom
Conversation
…ng, always set its value to Unknown
…ive to recommended blocks
It is no longer equal to the RequiredBlockType
…issingBlocks function
So that they appear as lower case in the analysis message in the sidebar
…nded rather than required
…commended blocks with issues
…ting tests Also improve some CS
packages/schema-blocks/src/core/validation/BlockValidationResult.ts
Outdated
Show resolved
Hide resolved
packages/schema-blocks/src/core/validation/BlockValidationResult.ts
Outdated
Show resolved
Hide resolved
packages/schema-blocks/src/functions/presenters/SidebarWarningPresenter.ts
Outdated
Show resolved
Hide resolved
packages/schema-blocks/src/functions/presenters/SidebarWarningPresenter.ts
Outdated
Show resolved
Hide resolved
packages/schema-blocks/src/functions/validators/innerBlocksValid.ts
Outdated
Show resolved
Hide resolved
packages/schema-blocks/src/functions/validators/innerBlocksValid.ts
Outdated
Show resolved
Hide resolved
increddibelly
left a comment
There was a problem hiding this comment.
zie opmerkingen; het zou nog zeer waardevol zijn om dit deel over te dragen aan de onderliggende functie dwz dat daar de splitsing op recommended / required wordt gemaakt, maar alleen als het in een uur of twee kost.
…-706-orange-analysis
It's not the issues who are required, but the blocks
…r a need to pass this value through the `job-posting.block.template`
| return warning.replace( "{parent}", __( issue.parent, "wpseo-schema-blocks" ) ) | ||
| .replace( "{child}", __( issue.name, "wpseo-schema-blocks" ) ) | ||
| .replace( "{status}", __( issue.status, "wpseo-schema-blocks" ) ); | ||
| .replace( "{presence}", __( issue.presence, "wpseo-schema-blocks" ) ); |
There was a problem hiding this comment.
Hmm, this will cause merge conflicts with #1127 where this logic (replaceVariables) has been removed.
Also please not that dynamic arguments for translations aren't translatable. The potfile builder will take issue.presence as value to translate.
| issue.result === BlockValidation.MissingAttribute ) ) { | ||
| return { | ||
| text: __( "Not all required blocks are completed! No " + issues[ 0 ].parent + | ||
| text: __( "Not all required blocks have been completed! No " + issues[ 0 ].parent + |
|
|
||
| const messages = messageData.map( msg => { | ||
| return { text: replaceVariables( msg ), color: "red" } as sidebarWarning; | ||
| return { text: replaceVariables( msg ), color: ( msg.presence === BlockPresence.Recommended ? "orange" : "red" ) } as sidebarWarning; |
There was a problem hiding this comment.
Tip: I would make this more readable by adding newlines. Especially the conditional makes this all hard to read/process
There was a problem hiding this comment.
Good point. But I believe this code has been changed in #1127 anyway.
Summary
This PR can be summarized in the following changelog entry:
Analysisin the side bar when a recommended block is removed.Relevant technical choices:
enum BlocktypeinBlockValidationResult.ts, which holds the different block types (required, recommended, optional, and for the time being, also unknown).blockTypeparameter to theBlockValidationResultclass, with the type beingBlockType.BlockVariationResultclass is instantiated, it needs to be passed ablockTypeparameter.unknownas a value to the enum; I'm passingunknownto all instantiations ofBlockValidationResultwhich are outside the scope of this PR. We could look into fixing this, but I'm not sure it worth the time investment right now. The thing is that we don't know the block type for many block instances, since the block templates themselves don't pass their own block type (instead, it is listed injob-posting.block.phpwhat is the block type for each block).validateInnerBlocksfunction ininnerBlocksValid.tsnow also calls thefindMissingBlocksfunction for recommended blocks (it used to call this function only for required blocks).findMissingBlocksfunction to reflect this.findMissingBlocksfunction adds the block type to theBlockValidationResult. These results will be used in the sidebar (as thestatusof themessageDatainSidebarWarningPresenter.ts) to show the appropriate warning.Test instructions
This PR can be tested by following these steps:
Analysisin the side bar, because all the recommended blocks are present upon initialization.Test scenario 7
Remove a recommended block, for example the 'Requirements'.
See an orange bullet and the text: "The 'Requirements' block is recommended but missing.":

See that the Requirements block is greyed out and can be added:

Remove another recommended block and see another orange bullet appear (with the right text).
The red bullet saying "Not all required blocks are complete! No job posting schema will be generated for your page." should still be present.
Test scenario 8
Test Schema output
Note that scenarios 7 and 8 both contain a line regarding the color of the emoticon in the pre-publish check; I didn't solve that yet as there is a separate ticket for this task: https://yoast.atlassian.net/browse/P2-789.
Impact check
*
UI changes
Quality assurance
Fixes https://yoast.atlassian.net/browse/P2-706