Latest Posts: Read more links have identical text and ignore excerpt_more filter from themes

[sabernhardt]

Description

When #51190 matched the front end to the editor, instead of matching the editor to the front end, it created two problems:

1. All "Read more" links in the block have identical text, which goes against accessibility guidelines.
2. By using the excerpt_more hook, on the standard priority, this replaces filters that themes have used to add custom unique links in place of the ellipsis. That includes the bundled themes from Twenty Thirteen to Twenty Nineteen and Twenty Twenty-One.

Related: Trac 59409

Step-by-step reproduction instructions

1. Create several posts, each with a few paragraphs of text.
2. Add a Latest Posts block, either in a template or within the content of a page. In the sidebar, toggle the Post content on and show the Excerpt.
3. Activate Twenty Twenty-Three and visit a page with that Latest Posts block.
4. Observe that the post excerpts end with the ellipsis (…) and "Read more" links.
5. Check the text of the "Read more" links, and note that their accessible names are identical to each other. (You could inspect each element, or you might access the list of links with a screen reader or in a tool such as the WAVE browser extension.)
6. Activate Twenty Twenty-One and return to the page you visited earlier.
7. Check the text of "Read more" links again. With WordPress 6.2, these links showed "Continue reading" and included the post title as screen-reader-only text. In WordPress 6.3, that was replaced with the ellipsis and "Read more" links.

Screenshots, screen recording, code snippet

Twenty Twenty-Three had the bracketed ellipsis in WordPress 6.2

WordPress 6.3 added "Read more" links to each post excerpt

Twenty Twenty-One's "Continue reading" links applied to the post excerpts with the Latest Posts block in WordPress 6.2

WordPress 6.3 replaced the theme's text with "Read more" links

Environment info

WordPress 6.3, with or without Gutenberg 16.7.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[sabernhardt]

The solution for this could be similar to what is proposed in #51213, with a special class on the link and either an aria-label or screen reader text.

			$trimmed_excerpt = get_the_excerpt( $post );

			// Add "Read more" link with screen reader text.
			if ( str_ends_with( $trimmed_excerpt, ' […]' ) ) {
				$trimmed_excerpt .= sprintf(
					' <a class="wp-block-latest-posts__post-read-more" href="%1$s" rel="noopener noreferrer">%2$s</a>',
					esc_url( $post_link ),
					/* translators: %s: Post title. Only visible to screen readers. */
					sprintf( __( 'Read more<span class="screen-reader-text"> of &#8220;%s&#8221;</span>' ), esc_html( $title ) )
				);
			}

			if ( post_password_required( $post ) ) {
				$trimmed_excerpt = __( 'This content is password protected.' );
			}

[sabernhardt]

The (unnamed) excerpt_more filter would need to be removed from the plugin and Core. The editor likely should have an adjustment as well.

[ramonjd]

Thanks for filing this issue @sabernhardt I'll take another shot at rectifying it

[ramonjd]

I'm thinking that the plugin, also in the editor, should treat the default excerpt value as […], following Core's default in wp_trim_excerpt()

https://github.com/WordPress/wordpress-develop/blob/ff96003a0f91394d8e0f37643a5c96aaad42299b/src/wp-includes/formatting.php#L4028

Previously, the editor had always rendered "Read more" by default, so it looks like the editor should been made to conform to the frontend's default behaviour, and not the other way around.

Also good point about the accessibility deficiency. Thanks for raising it 👍🏻

The only inconsistency I expect is that, if a theme such as 2021 et. al., returns a value from the excerpt_more filter it will only appear in the frontend. The editor will continue to display whatever the hardcoded default is.

Given that's the current state of things (and has been forever) I believe it's acceptable (?).

[ramonjd]

First draft here: #55026

I've also flagged this issue on the 6.4 editor tasks board.

[ramonjd]

Actually now I've had the chance to reflect, I think I remember why we did use the excerpt_more filter in #51190

It was so that choices of the user in the editor were reflected on the frontend, even if those changes overrode theme custom text.

Theme custom text would still display if displayPostContentRadio was not set to 'excerpt' in the Latest Posts block attributes. However I believe we were missing the editor's "excerptLength attribute is less than the currently-set excerpt length" condition in index.php.

I'm not suggesting either approach is better than the other, just documenting the motivation.

[sabernhardt]

@felixarntz and @swissspidy started a discussion about including the "Read more" text within the same translatable string as the link.

If we keep the screen-reader-text (instead of switching to an aria-label), maybe something like this could work for both the editor and the front end (using empty strings for the two attribute placeholders in the editor):

/* translators: 1: Link attributes, 2: HTML attributes for the span element, 3: The post title only visible to screen readers. */
__( '… <a%1$s>Read more<span%2$s> of %3$s</span></a>' ),
' href="' . esc_url( $post_link ) . '" rel="noopener noreferrer"',
' class="screen-reader-text"',
esc_html( $title )

I like "Read more of" the post, though "Read more about" is probably just as good.

[ramonjd]

Thanks for cross posting here @sabernhardt

I saw that discussion. I'll backport any changes made to Core into Gutenberg.

If we were to go with a preposition, I think "about" is more appropriate in English.