Parser: Parse  tag and  #1460

dmsnell · 2017-06-26T17:12:43Z

These tags are officially supported by WordPress and are an exception
with the concept of blocks. They contain structural data and yet they
are just HTML comments without any further indication.

The "more" tag supports an optional custom text string and if it is
immediately followed by the "no teaser" tag then that contains
additional information.

In this change we parse those tags and combine them into a single "more"
block with attributes of the custom text and whether or not the
noTeaser option has been selected.

By the way, I haven't added this yet to the PHP parser. That's something I'm
still thinking about. Please feel free to augment it on this PR.

At first I planned on making this a syntax-sugar for blocks but then I realized
it's a special case and there are few other exceptions, so I made it specific
and encoded in the semantics of the noteaser tag with it.

cc: @swissspidy

swissspidy · 2017-06-26T17:25:13Z

blocks/api/post.pegjs

+  } }
+
+WP_Tag_NoTeaser
+  = "<!--" WS* "noteaser" WS* "-->"


 support in WordPress is hardcoded to exactly this string. No whitespace allowed. See get_the_content().

thanks! I removed the allowance in b5fb0c1

swissspidy · 2017-06-26T17:27:38Z

blocks/api/post.pegjs

  / WP_Block_Balanced
  / WP_Block_Html

+WP_Tag_More
+  = "<!--" WS* "more" customText:(WS+ text:$((!(WS* "-->") .)+) { return text })? WS* "-->" noTeaser:(WS* WP_Tag_NoTeaser)?


As mentioned in #1329,  doesn't need to directly follow the more tag (although it makes sense to put it there). It can theoretically be anywhere in the post content. See get_the_content().

yeah I deferred to the Codex for the behavior. which should we fix? the Codex or Core?

actually, I think I can say that I would prefer we enforce the documented syntax. we're already making a break in some fashion with the old, plus when someone loads a post with an incorrect  tag it will just disappear I think, then they can see the option on the more block.

just musing thoughts here

dmsnell · 2017-06-26T17:32:21Z

This PR is not tracking the branch. I'm going to give GitHub some time in case their systems are the problem. If it doesn't resolve I'll recreate the PR.

swissspidy · 2017-06-26T17:36:45Z

@dmsnell Yeah, it's GitHub. Just noticed it before as well. See https://status.github.com

By the way, thanks for creating this PR! I was looking into the grammar thing as well, but didn't really have time for it.

mtias · 2017-06-26T17:39:58Z

Here's a broader question: should we understand the legacy ones but always convert to new ones on save, and update core to understand new ones?

mtias · 2017-06-26T17:43:14Z

It could become:

<!-- wp:core/more { "customText": "Keep on reading!", "noTeaser": true } /-->

mtias · 2017-06-26T17:44:44Z

post-content.js

@@ -12,6 +12,9 @@ window._wpGutenbergPost = {
 			'<section className="cover-image wp-block-cover-image" style={ { backgroundImage: \'url("https://cldup.com/GCwahb3aOb.jpg");\' } }><h2>Gutenberg Editor</h2></section>',
 			'<!-- /wp:core/cover-image -->',

+			'<!-- more Keep on reading! -->',
+			'<!-- noteaser -->',


I think we can keep this one out of the demo.



good question! if we do this then we do have one more unique feature: the "fallback HTML" no longer carries the same rendering because WP will not appropriate handle the more tag.

as a serialized block it will only work if we have a block registered.

I'm not sure how I feel, but I have a commit ready to serialize the normal more tag

mtias · 2017-06-26T17:45:15Z

Looks good, thanks!

dmsnell · 2017-07-03T12:12:06Z

For now, in follow-up with @swissspidy and @mtias what I'd like to do is merge this incremental change: follow the WP spec, which says that the noteaser must immediately follow the more and also withhold from trying to convert to a formal block spec on save.

Both of these questions are valid I think but could easily be done in another PR later.

These tags are officially supported by WordPress and are an exception with the concept of blocks. They contain structural data and yet they are just HTML comments without any further indication. The "more" tag supports an optional custom text string and if it is immediately followed by the "no teaser" tag then that contains additional information. In this change we parse those tags and combine them into a single "more" block with attributes of the custom text and whether or not the `noTeaser` option has been selected.

dmsnell · 2017-07-03T12:29:01Z

Rebased: former HEAD was a1343a4

swissspidy · 2017-07-03T12:30:22Z

See also #1467 for some tests that perhaps could be useful for this. The parser still has some problems with these tags I think (see 35ef9f12a595168b14062a9377d064c163306803)

dmsnell · 2017-07-03T12:38:43Z

@swissspidy the problems with the parser in #1467 are related to the way that early on the concept of a Token was stripped from the parser. It has made it hard to deal with things since then and since we've built the parser around this weakened state. It's been on my todo list to fix but I have very little time to dedicate to it.

Therefore the problem isn't with these tags but with the WP_Block_HTML rule (which I think is a weak rule anyway to have since it's literally the absence of rules) and how it has to prevent detecting everything else that could be a top-level token.

swissspidy · 2017-07-03T13:19:09Z

@dmsnell Yeah this WP_Block_HTML rule was just pointed out to me as well, see #1467 (comment)

swissspidy · 2017-07-04T21:40:00Z

blocks/api/serializer.js

@@ -115,6 +115,10 @@ export function serializeBlock( block ) {
 	const saveContent = getSaveContent( blockType, block.attributes );
 	const saveAttributes = getCommentAttributes( block.attributes, parseBlockAttributes( saveContent, blockType ) );

+	if ( 'wp:core/more' === blockName ) {
+		return `<!-- more ${ saveAttributes.customText ? `${ saveAttributes.customText } ` : '' }-->${ saveAttributes.noTeaser ? '\n<!--noteaser-->' : '' }`;


This should actually be <!--more instead of <!-- more according to get_the_content().

Addressed in #1440.

nylen · 2017-07-05T08:35:01Z

Please do not merge anything else that touches parsing without test cases in place first.

Add image alignment controls

dmsnell added the [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f label Jun 26, 2017

dmsnell requested review from westonruter, nylen and mtias June 26, 2017 17:12

swissspidy reviewed Jun 26, 2017

View reviewed changes

mtias reviewed Jun 26, 2017

View reviewed changes

dmsnell force-pushed the parser/parse-more-tag branch from 42efe9e to b633388 Compare June 26, 2017 17:57

swissspidy mentioned this pull request Jun 26, 2017

Add pagination block #1467

Merged

dmsnell added 2 commits July 3, 2017 14:28

Remove allowance for whitespace in noteaser tag

065d158

dmsnell force-pushed the parser/parse-more-tag branch from a1343a4 to ef45dfb Compare July 3, 2017 12:28

Serialize to the more tag

edb838d

dmsnell force-pushed the parser/parse-more-tag branch from ef45dfb to edb838d Compare July 3, 2017 12:31

dmsnell added 2 commits July 3, 2017 14:44

appease the angry linter

d5eab31

appease the angry linter

6a4ca43

dmsnell merged commit fdbfc9b into master Jul 4, 2017

dmsnell deleted the parser/parse-more-tag branch July 4, 2017 14:19

swissspidy reviewed Jul 4, 2017

View reviewed changes

dratwas pushed a commit that referenced this pull request Nov 14, 2019

Merge pull request #1460 from wordpress-mobile/issue/198-image_alignment

efde2da

Add image alignment controls

This was referenced Sep 16, 2021

[Snyk] Security upgrade yargs from 14.2.3 to 15.0.1 Verdinjoshua26/gutenberg#23

Open

[Snyk] Security upgrade yargs from 14.2.3 to 15.0.1 MaxMood96/gutenberg#50

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Parser: Parse  tag and  #1460

Parser: Parse  tag and  #1460

dmsnell commented Jun 26, 2017

swissspidy Jun 26, 2017

dmsnell Jun 26, 2017

swissspidy Jun 26, 2017

dmsnell Jun 26, 2017

dmsnell Jun 26, 2017

dmsnell commented Jun 26, 2017

swissspidy commented Jun 26, 2017

mtias commented Jun 26, 2017

mtias commented Jun 26, 2017 •

edited

Loading

mtias Jun 26, 2017

dmsnell Jun 26, 2017

mtias commented Jun 26, 2017

dmsnell commented Jul 3, 2017

dmsnell commented Jul 3, 2017

swissspidy commented Jul 3, 2017

dmsnell commented Jul 3, 2017

swissspidy commented Jul 3, 2017

swissspidy Jul 4, 2017

swissspidy Jul 5, 2017

nylen commented Jul 5, 2017

Parser: Parse  tag and  #1460

Parser: Parse  tag and  #1460

Conversation

dmsnell commented Jun 26, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dmsnell commented Jun 26, 2017

swissspidy commented Jun 26, 2017

mtias commented Jun 26, 2017

mtias commented Jun 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mtias commented Jun 26, 2017

dmsnell commented Jul 3, 2017

dmsnell commented Jul 3, 2017

swissspidy commented Jul 3, 2017

dmsnell commented Jul 3, 2017

swissspidy commented Jul 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nylen commented Jul 5, 2017

mtias commented Jun 26, 2017 •

edited

Loading