More-links lack consistency in input (backend) and output (frontend)

[jaapwiering]

To insert a more-link in the block editor:

1. type /more in an article
2. a dashed line with capitalized "READ MORE" appears

In the frontend the text "(more...)" is printed by the function the_content(); (without any arguments).

In the frontend the text "some text" is printed by the function the_content(‘some text’);.

The problem

The read more-text prints inconsistently in backend ("READ MORE") and frontend ("(more...)" or something else), while the backend is supposed to mimic the frontend.

Additional problems

• To content creators it is unclear that you can actually customize the read more-text
• The capitalization suggests that this text should be capitals, and will be printed in the frontend as capital, which is not the case.
• Content and presentation are not separated properly

Proposed solutions

1. If nothing else would change, then at least the placeholder text should be “(more..)”, not capitalized, by default
2. A better solution would be that the argument in the_content(‘argument’); would be printed in the backend
3. The default read more text could appear as a an option in the theme customizer

[Thelmachido]

I was checking the read-more block on a test site, at the moment it looks like the frontend (archive page) doesn't display any text to show that a post has the read-more block as shown below:

https://user-images.githubusercontent.com/41231764/186836259-8fdb6e87-a4b5-4538-8c53-dcd73a7eef9c.mov

WordPress 6.0.1

Gutenberg 13.9.0

[carolinan]

It does not show on the archive page if it is set up to use an excerpt, only if it uses the post content.

[richtabor]

Design wise, the big disadvantage here is that it's difficult to scan a post in the editor, and see where the more is applied. I see this more of a page break UI, than a 1:1 front-end to editor UI. Otherwise, it looks like the more block is part of your post document, which it isn't.

I don't think we should style it like the rest of your content, it's more utility than anything else. I would expect the opposite even, that it would look more like the editor UI than the site's.

[carolinan]

It is different from the page break block, though, because it does show on the front on archives, and the current design means the content will never match what you see on the front.

[richtabor]

But to most users, they're the same idea.

the current design means the content will never match what you see on the front.

I don't think the more block should be the same design as on the front.

You don't see it on the post anyhow, only within templates/query loop, right?

[carolinan]

I understand that this is only one user reporting that they need the block to match in the editor and front. The other open issues are about the block "not working" because it is very difficult to understand how it is meant to be used.

But if user testing reports or conversations in the support forums show that this block is an exception, please share that material.

[carolinan]

I can't add a screenshot right now, but what if the dashes were kept and the text content showed the correct editable text with the correct link style and capitalization?

It wouldn't look right to me, because the block is left-aligned on the front and can't be aligned on its own; that is, it does not have any alignment or text alignment options. But it would be a compromise where it may be more visible.

[richtabor]

I think that can work in part. If we maintain the border, using the styles from the body to apply the correct background color, text color, and typography styles.

But I'm not convinced that (more…) as a default text label in the block itself would help understanding the block's intention.

Here are a few visuals of how this would look across different fonts/colors:

[richtabor]

because it is very difficult to understand how it is meant to be used.

Yes, this is. I'm not even quite sure what "Hide the excerpt on the full content page" does, or why that controls exists on this block.

I would expect a control for not showing the link at all though.

I think a big part of the confusion is why is a seemingly random (and not ideal) "(more…)" text added to the bottom of my post. Bringing that default text into the editor won't make that clearer; I think it'll just make the editor also confusing.

But a way to just not render a link at all, but still have the more block work like it says, would though.

[richtabor]

"Hide the excerpt on the full content page"

I'm not sure this should be on the post level anyhow, shouldn't a template decide when an excerpt is rendered or not?

[carolinan]

The option to hide the content that is before the more block when you view the single post, as well as the default text, are there because they are part of the classic more tag and noteaser tag:

https://codex.wordpress.org/Customizing_the_Read_More

I don't think that "Read More" is suitable default text because 1) it increase a the risk that it is mixed up with the read more block. 2) It is inconsistent with the classic feature it is meant to replace.

Part of me thinks that this block was not a good idea. But I don't know if deprecating it is an option, there isnt really anything to replace it with.

[carolinan]

I would expect a control for not showing the link at all though.

The block was added as a block equivalent of an existing classic feature with a specific behavior, it was not possible to forsee how the templates would evolve. Perhaps another reason for considering a deprecation.

[richtabor]

It's certainly useful, I use it all the time on my blog when I have posts that I don't want to go full content on index views.

The block is useful, I'm just noting that one particular control.

I don't think that "Read More" is suitable default text because 1) it increase a the risk that it is mixed up with the read more block.

What's the "Read more" block?

[carolinan]

This:

https://github.com/WordPress/gutenberg/tree/trunk/packages/block-library/src/read-more

[richtabor]

Yea, that's not a suitable replacement. It's not really a "read more" like the more block is; it's a permalink block.

[jaapwiering]

I just tested again this issue that I created 3 years ago. This is WP-version 6.5.2 with the Twenty Twenty-Four theme. The issue still exists: "READ MORE" in the backend shows up as "(more...)" in the frontend. To my opinion it is inconsistent and therefore confusing.

backend entry in the post

backend query block on a page

frontend result

I think of a two options to improve this:

• change backend text from "READ MORE" to "(more...)"
  • users will see the link, might dislike it, and edit it
  • it would help if it is more visible that this is an editable option
• change frontend text from "(more...)" to "READ MORE"; this is trickier, because it could change existing website

An extra option might be to add a default more-link text in the Site Editor.

[richtabor]

change backend text from "READ MORE" to "(more...)"

Again, I don't think "(more...)" makes this less confusing, potentially the opposite. "Read more" is at least indicative of what utility this block provides.

it would help if it is more visible that this is an editable option

If it's unclear that it's editable, let's add an input field in the inspector, empty by default (as the initial value could be whatever the filter provides).

[carolinan]

I thought we were moving away from inputs in the inspector for anything that is not part of the navigation block. It would make the block inconsistent with others, and potentially more confusing.

Changing the default front facing text is an unexpected breaking change for existing sites. This is functionality that has been around since before WP version 1. The default text is added in get_the_content.

https://github.com/WordPress/wordpress-develop/blob/6.5/src/wp-includes/post-template.php#L311

[richtabor]

Yes, I'm not for changing the default text. But I don't think we should change the "Read more" to (more...).

[richtabor]

I don't think an input control would be confusing; it provides opportunity for helpful description as well - but it's just an idea.

It could have no impact (which means it's not a good idea ha).