Add "More" block.

[mtias]

See #983.

[jasmussen]

So this is interesting... the "READ MORE" text is editable.

Was this intentional on your part? I'm leaning towards this text not being editable, and letting themes decide the text that goes there. But it's a very intriguing idea.

[jasmussen]

I dig the help text in the inspector! ⭐️⭐️⭐️⭐️⭐️

[mtias]

@jasmussen it is editable on purpose. WordPress handles it like this:
<!--more Your custom more text... -->

[jasmussen]

Interesting! I did not know that.

Then I'd like to redesign it a bit. I'll assign myself this branch and do it in code, if that's okay with you.

[mtias]

Sure thing. My plan was that the default text is not a placeholder but real text. Not sure it's trivial to get the text a theme has specified, so we may need to present it more abstractly.

[jasmussen]

Not sure it's trivial to get the text a theme has specified, so we may need to present it more abstractly.

I think this is key to figure out if we actually want to make it editable.

What exactly does the "Your custom more text..." do in <!--more Your custom more text... -->? Does it override the Read More text provided by the theme? And if yes, is this a feature that we think will stick around for a bit? It sort of has that "abandoned" smell on it.

In case it's a feature we think will stick around, and it already works today, then I totally love the idea that not only can you customize it but do it on a per-post basis.

The key thing to think about for the design (you touch on it with the "get the text a theme has specified"), is making the configurability discoverable. If we can't actually read the text that the theme has provided, then we should either go super abstract and perhaps not even show the "Read More" text on the block, but something else entirely. Or maybe we do show that, but only let you customize the read more text in the inspector. Something I think I'll need to sleep on.

[mtias]

Yes, it works, but is quite the hidden feature:

I actually love that we could surface this way better with blocks, and that it's much more obvious how it works when you can edit the text directly.

[dmsnell]

I'm proposing that we leave this as its own block for now and iterate if necessary later. Essentially <!--something--> becomes shorthand for a block comment header. We will need to whitelist the available ones so we don't accidentally capture HTML comments.

// <!-- more -->

{
  blockName: 'wp:core/more'
}

// <!-- more read on! -->

{
  blockName: 'wp:core/more',
  attrs: {
    customText: 'read on!'
  }
}

[swissspidy]

Can we somehow enforce that this block only can be used once in a post? Something for a separate PR, but just thinking out loud here.

[mtias]

@swissspidy ah, yes, definitely.

[jasmussen]

I pushed a little polish to this one. Now the text area doesn't span the full width. I also tweaked the description a bit.

I can't think of a better way to design this block so input is editable. It's not as discoverable as I'd like it to be, but I think we should get this in and iterate later.

Should we add a placeholder? Right now if you delete the text, it's just a dashed line.

[swissspidy]

Should we add a placeholder? Right now if you delete the text, it's just a dashed line.

I think so. "Read more" makes sense. Looking at get_the_content(), (more…) seems to be the default for the link. However, that doesn't really work well as a placeholder.

[swissspidy]

This could use the new <BlockDescription> element

[westonruter]

Can we somehow enforce that this block only can be used once in a post? Something for a separate PR, but just thinking out loud here.

See #1661.

[youknowriad]

I pushed some changes here (essentially the useOnce and some polish). I think this is ready to go, can we have some 👀 here?

[codecov-io]

Codecov Report

Merging #1440 into master will increase coverage by 0.05%.
The diff coverage is 41.66%.

@@            Coverage Diff             @@
##           master    #1440      +/-   ##
==========================================
+ Coverage   18.82%   18.87%   +0.05%     
==========================================
  Files         129      130       +1     
  Lines        4197     4207      +10     
  Branches      716      718       +2     
==========================================
+ Hits          790      794       +4     
- Misses       2868     2873       +5     
- Partials      539      540       +1

Impacted Files	Coverage Δ
blocks/api/serializer.js	100% <100%> (+3.03%)	⬆️
blocks/library/more/index.js	30% <30%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b4a30ac...e7f04b0. Read the comment docs.

[youknowriad]

Ok merging. We can iterate in smaller PRs

[swissspidy]

Maybe another invalid variation such as <!--more-->\nsome text<!--noteaser--> - how likely is this to happen?

It's not invalid in PHP. WordPress doesn't care where in the content <!--noteaser--> is. It doesn't need to follow right after the more tag. How should legacy content be handled in this scenario?

[ellatrix]

I haven't followed the discussion closely, and maybe I'm just repeating what someone else said, but what if we put the legacy content in the block body, and upgrade old ones when they're between blocks?

<!-- wp:core/more { "text": "some text...", "noTeaser": true } -->
<!--more some text...-->
<!--noteaser-->
<!-- /wp:core/more -->

[aduth]

@iseulde I'm not really sure. I like your proposal for consistency's sake. Maybe there's an argument for special-casing some "known" types.

[nylen]

Another way that would be cleaner: make core recognize the <!-- wp:core/more /--> syntax using our server-side parser. I'm not sure how difficult this would be, but if it's achievable then we could just remove the old tags.

[mtias]

I agree with @nylen, let's see if we can consolidate all comments under the same syntax. Doesn't make much sense to me to wrap an old comment in new comments, it just adds noise.