FSE: New Patterns

[ianstewart]

This PR should add 23 new patterns to the FSE Plugin.

This is most of the patterns from …

https://dotcompatterns.wordpress.com/2020/05/13/quote/

through to …

https://dotcompatterns.wordpress.com/2020/06/16/audio-player/

with a few exceptions where I encountered a bug or small known issue. (We'll get to them in a later PR or via another deployment method.)

[matticbot]

Test live: https://calypso.live/?branch=fse/june-pattern-set

[matticbot]

Caution: This PR affects files in the FSE Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

D45735-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing in the FSE Plugin for more info: PCYsg-ly5-p2

[andrewserong]

Firstly, these patterns are looking very cool! I've noted a few PHPCS errors that are being thrown in the build.

I have a couple of concerns about adding this many new patterns in the current interface we have for displaying patterns. Some of the designs are quite tall, which doesn't feel like the best format for displaying them, and the scrollbar for the Patterns section selection is now very long, and slows down that part of the page with rendering everything at once. For example, here's how the Multi-column Text with Headline is looking on my test Atomic site:

Are we reaching a point where we need a new interface for browsing, filtering or selecting the patterns? (I know I've seen a few different mockups for it, but wasn't sure at what point we'll hit the need to improve the browsing of the patterns so that it really feels easy to use).

I haven't had a chance to investigate each of the block errors, but a fair few of the blocks are failing rendering in my Atomic site. E.g. List, Three Quotes, Heading and Text in Two Columns, Multi-column Text with Headline, Image and Text Mosaic, Subscription.

[iamtakashi]

Some of the designs are quite tall, which doesn't feel like the best format for displaying them

The narrow default viewport size for the preview is making patterns with text a lot taller. Let's add 'viewportWidth' => 1280 to each pattern like #43362

[ianstewart]

The last commit should address the viewport and the non-standards code. Doesn't yet address any Atomic issues.

[ianstewart]

Are we reaching a point where we need a new interface for browsing, filtering or selecting the patterns?

There are some improvements on the way in core Gutenberg for surfacing patterns on inline search in the canvas and some designs out there for at least two column browsing.

[ianstewart]

a fair few of the blocks are failing rendering in my Atomic site. E.g. List, Three Quotes, Heading and Text in Two Columns, Multi-column Text with Headline, Image and Text Mosaic, Subscription.

@iamtakashi any commonalities jumping out for you with this list?

[iamtakashi]

In my testing, the following patterns are broken in Simple sites too.

heading-and-text-in-two-columns.php
image-and-text-mosaic.php
three-quotes.php
multi-column-text-with-headline.php
list-02.php
subscription.php

In addition to the above, subscription-02.php is broken in Atomic sites. Though, this pattern appears fine in Simple sites.

any commonalities jumping out for you with this list?

It might be something to do with the column block. The following patterns share the use of the column block

heading-and-text-in-two-columns.php
image-and-text-mosaic.php
three-quotes.php
multi-column-text-with-headline.php

I'm not sure why list-02.php and subscription.php are broken.

[deBhal]

Ok, the first problem is that the %" in "flex-basis:x%" is being interpreted as an sprintf() formatting command. That's a bit of a head-scratcher, because %" is not a printf formatting command - https://www.php.net/manual/en/function.printf.php

My best guess is that it's invalid syntax, terminating the printf flag but consuming the character in the process:
printf( '>%"< >%#< >%y<. The d: >%d<' . "\n", '1', '2','3', '4'); =>
>< >< ><. The d: >4<

Interestingly, printf does complain if you don't provide an argument for those invalid flags, but still probably not a very useful behavioural quirk. I had no idea about any of this - :TIL:

Short version: sed -i '' 's/%"/%%"/g' *.php

If we grep -l '%"' *, we get:

heading-and-text-in-two-columns.php
image-and-text-mosaic.php
multi-column-text-with-headline.php
subscription.php
three-quotes.php

Which only misses list-02.php. I'll check that out next.

[deBhal]

The list-02.php pattern doesn't quite match the result of the save() function - there's one opening and one closing <p> tag that differ between what we've got in the repo and what gutenberg is generating on my AT site.

I've just pushed the change, as it seems the easiest way to communicate clearly here, but it needs testing in more scenarios. Let me know if you need to me to circle back to do that tomorrow.

Out of interest, where did these $markups come from? Are we looking at different Gutenberg versions here, or just something like a copy-and-paste error? I understood that the patterns generally live as posts on a blog, so if we're pulling them out of a blog like that, we should have a look at that tool.

There seems to be another intermittent issue where the list-02 does not receive the list items, which results in an error in the console and an empty example in the inserter, but the actual block when you click on it is just fine.

It's a bit late here, so I'll come back to that tomorrow unless someone knows the story there.

I'm also still seeing a bunch of console errors when opening up the inserter after applying the percent fix I mentioned above, so I won't push that until I've had a chance to look at them tomorrow.

[ianstewart]

Out of interest, where did these $markups come from? Are we looking at different Gutenberg versions here, or just something like a copy-and-paste error? I understood that the patterns generally live as posts on a blog, so if we're pulling them out of a blog like that, we should have a look at that tool.

Correct. It's https://dotcompatterns.wordpress.com/.

[iamtakashi]

Wouldn't this make two empty paragraphs and having three paragraphs in total?

The original markup was also weird though, it looks like a paragraph wrapped in a paragraph. And looking at the inline style, the paragraph tag <p style="line-height:.9;font-size:72px;"> has been duplicated in the markup for some reason?

[iamtakashi]

The particular pattern was made in here: https://wordpress.com/block-editor/post/dotcompatterns.wordpress.com/938

I saw a duplicated paragraph tag in the markup. Not sure how it got there, but I cleaned it up. So if we update the markup in list-02.php with the current markup that has only a single paragraph tag, the pattern should be fine.

[iamtakashi]

I spoke too soon. The duplicate tag comes back when I reopen the pattern.

This:
<p style="line-height:0.9;font-size:72px" ... </p>

becomes this, and it seems like a bug.
<p style="line-height:0.9;font-size:72px"><p style="line-height:.9;font-size:72px;"> ... </p></p>

[deBhal]

The notifications in the console and editor are triggered when the HTML regenerated by Gutenberg doesn’t match what’s on the page, so if there’s a bug in one of the component blocks, Gutenberg will complain if we fix it.

What should be able to unit-test this, I’ll have a look at writing that. It will probably be quicker than the manual testing I was planning, and should catch this whole class of problems in future

[ianstewart]

cc @ramonjd just in case any of the above turns out to be useful for the Patterns API work.

[ockham]

There are still a number of phpcs lints, all of which seem to be fixable through phpcbf. I wonder why our pre-commit hook isn't doing that for us? 🤔

wp-calypso/bin/pre-commit-hook.js

Lines 135 to 154 in 8e806f2

	// Format the PHP files with PHPCBF and then re-stage them. Swallow the output.
	toPHPCBF.forEach( ( file ) => console.log( `PHPCBF formatting staged file: ${ file }` ) );
	if ( toPHPCBF.length ) {
	if ( phpcs ) {
	try {
	execSync(
	`${ quotedPath( phpcbfPath ) } --standard=apps/phpcs.xml ${ toPHPCBF.join( ' ' ) }`
	);
	} catch ( error ) {
	// PHPCBF returns a `0` or `1` exit code on success, and `2` on failures. ¯\_(ツ)_/¯
	// https://github.com/squizlabs/PHP_CodeSniffer/blob/HEAD/src/Runner.php#L210
	if ( 2 === error.status ) {
	linterFailure();
	}
	}
	execSync( `git add ${ toPHPCBF.join( ' ' ) }` );
	} else {
	printPhpcsDocs();
	}
	}

[ockham]

I'll rebase and fix those lints.

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[ockham]

BTW what's the state of this PR? Does the block markup need more checking/fixing, or is it ready to go?

[ockham]

I spoke too soon. The duplicate tag comes back when I reopen the pattern.

This:
<p style="line-height:0.9;font-size:72px" ... </p>

becomes this, and it seems like a bug.
<p style="line-height:0.9;font-size:72px"><p style="line-height:.9;font-size:72px;"> ... </p></p>

This seems vaguely familar. Is this taken directly from the dotcompatterns site, or run through any additional tooling? Specifically something that involves an XML or HTML parser (block patterns API something something)?

I seem to recall a problem with those parsers that would change multi-node markup (<abcd>foo</abcd><efgh>bar</efgh>) into single-node markup -- IIRC by wrapping everything in a duplicate of the first node (<abcd><abcd>foo</abcd><efgh>bar</efgh></abcd>). (The solution was to make sure that the parser only got single-node markup in the first place -- if needed, by wrapping everything in a root node that could be removed after parsing.)

cc/ @deBhal

[ianstewart]

BTW what's the state of this PR? Does the block markup need more checking/fixing, or is it ready to go?

I missed this message on Monday, sorry @ockham. I'll need some help testing on Atomic sites but I'll test again on Simple and check the status there. If the patterns load w/o errors we can merge and ship!

[ianstewart]

Hmm. Four of these are patterns are not rendering correctly on my Simple test site.

[lsl]

<p><p></p></p> turning into <p></p><p></p>

That looks a lot like what I was seeing with the DOMDocument parser, it will emit errors but those are usually being tossed in most cases and the parser just repairs the html the best it can.

WordPress/gutenberg/pull/24645 or D48290-code may have fixed those for this case, if there is actually invalid html in the pattern source that probably needs to just be fixed.

[david-szabo97]

• Moved files from the old FSE folder to the new ET folder.
• Fixed an argument typo in Podcast Subscription
• Fixed markup in List
• Escaped percents in Heading and Text in Two Columns, Image and Text Mosaic, Multi-column Text with Headline, Subscription, and Three Quotes

They are all looking good on local. Can someone help me out by testing the patterns?

[roo2]

hmm this all looks good except for the youtube embed block, on my simple site, the youtube embed blocks comes up with this error:

After attempting block recovery, the block works as expected

[roo2]

I fixed that youtube bug and will deploy this once tests pass