-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Block] Post Excerpt - Allow inline HTML tags #49449
Comments
Thanks for the report. I think the problem is a bug. The post excerpt should not remove HTML tags by default, but this block removes HTML tags on the front end. Below are the results of the test on Twenty Twenty One. When the excerpt contains HTML tags, the Post Excerpt block outputs the HTML tags on the editor: However, this block removes HTML on the front end: Twenty Twenty One uses |
I've just experienced the same issue. Everything is working fine with WordPress 6.2.2 for me, but as soon as I activate Gutenberg 16.1.2, the inline HTML is stripped out from Post Excerpt block output. I think the issue is related to word trimming in the block output. The Please fix this somehow. |
Hey @christianguerrag ! User reports like the one you've shared here are best reported on issues in https://github.com/WordPress/wp-calypso/ , rather than here in the https://github.com/WordPress/gutenberg/ repo. Even though Automattic/wp-calypso#74675 directs to this report as an underlying issue, we use the |
Although I don't know if it's the best long term strategy, you should be able to patch this by hooking into Try:
|
Hello. In which file is this filter to insert? Best regards, lisia |
That's specific to your project setup. Technically any plugin, mu-plugin or theme function file should work. |
Hello Steven! Great, I inserted it in the function.php and the problem is fixed. Thanks a lot. lisia |
Warning: Undefined array key "excerptLength" in ...\wp-includes\blocks\post-excerpt.php on line 27 Hi everybody! then comment out or delete: |
This should be marked as an urgent bug because it is long-established WordPress functionality that HTML tags are not stripped from custom excerpts. I have just built a site with a block theme for the first time, and my client is confused and complains that it is not working as their previous theme did. It's not acceptable to have to say "the WordPress people have taken an arbitrary decision to change the way it works and there's nothing I can do about it". |
Hi Peter-HVD, |
I've always gone by the adage that you shouldn't ever edit core files as you will lose the mod next update. @StevenDufresne's code to change the excerpt length, however, does work for me and I can recommend it, even though it is spamming my debug.log file with those Undefined array key errors. However, I shouldn't have to change or add any code - my point is that it should be honouring the way WP has always worked! Hopefully it's a bug that will get fixed soon. Thanks. |
This commit does two things: 1) It allows inline tags in the Post Excerpt block when a user has manually created an excerpt and 2) It removes the excerpt length limit for manual excerpts. See: WordPress/gutenberg#49449
I haven't fully tested this to know if there are any consequences that I'm not seeing, but I needed to get excerpts working as they have traditionally worked in WordPress. The following code:
Feel free to use, test, or modify as needed: <?php
// Add a filter on `pre_render_block` to determine if the excerpt is manual. If
// so, add a filter to `wp_trim_words` to handle formatting ourself.
add_filter('pre_render_block', 'themeslug_pre_render_excerpt', 10, 3);
function themeslug_pre_render_excerpt(
?string $pre_render,
array $block,
?WP_Block $parent_block
): ?string {
if (
'core/post-excerpt' === $block['blockName']
&& is_null($pre_render)
&& ! is_null($parent_block)
&& isset($parent_block->context['postId'])
&& has_excerpt($parent_block->context['postId'])
) {
add_filter('wp_trim_words', 'themeslug_format_excerpt', 10, 4);
}
return $pre_render;
}
// Add a filter to Post Excerpt block to remove the filter we added earlier on
// the `wp_trim_words` hook.
add_filter('render_block_core/post-excerpt', 'themeslug_render_post_excerpt');
function themeslug_render_post_excerpt(string $content): string
{
if ($priority = has_filter('wp_trim_words', 'themeslug_format_excerpt')) {
remove_filter('wp_trim_words', 'themeslug_format_excerpt', $priority);
}
return $content;
}
// Used to filter `wp_trim_words` to allow manual excerpts to work, limiting to
// a subset of inline HTML tags.
function themeslug_format_excerpt(
string $text,
int $num_words,
string $more,
string $original_text
): string {
return wp_kses($original_text, [
'a' => [ 'href' => true, 'title' => true, 'class' => true ],
'abbr' => [ 'title' => true ],
'acronym' => [ 'title' => true ],
'bold' => [ 'class' => true ],
'code' => [ 'class' => true ],
'em' => [ 'class' => true ],
'i' => [ 'class' => true ],
'mark' => [ 'class' => true ],
'small' => [ 'class' => true ],
'span' => [ 'class' => true ],
'strong' => [ 'class' => true ]
]);
} |
The contribution by justintadlock worked great for me. |
Commenting to vote up allowing basic HTML in excerpts again, since block themes and Site Editor experience are now the way many new users will use WordPress. Ran into this helping a friend set up a new website: they expected a line break added with |
+1 |
I had a look into this. I think there are some options for fixing it, but it might be good to get some further feedback first. Here's a quick breakdown of the state of things
Options for fixing:
|
Could we just try and preserve markup but also the trim? I don't have a strong opinion. I do think that, compared to classic themes, block themes introduced a change that was likely not meant (?) to alter WP historical hehavior of not trimming manual excerpt. But that was something else, may I say. In the highly intreactive context of the block editor, setting a trim value in a post loop just to have some excerpts trimmed and some not is very confusing. If we proceed with not trimming manual excerpts we should have a sort of help text mentioning manual excerpts are not affected by this setting, right there in the inspector. But I think best would be to always respect that, on both auto and manual excerpts but also preserve markup ... if that is somehow magically possible ... |
This was a change that was introduced in Gutenberg 15.2 (WP 6.3?) from what I can see: #44964 With that change, sites were already suddenly impacted by two things:
Trimming manual excerpts while preserving HTML would only fix 1/2 of the bug. If going this route, there needs to be a way to turn off trimming of manual excerpts. Otherwise, some developers are still stuck with overly complicated fixes in place. Personally, I'd be in favor of a second control for applying/not-applying trimming to manual excerpts. At the very least, the attribute (something like Honestly, this would likely be the best of both worlds. There are scenarios where it makes sense to trim both (grid layouts with posts that should be relatively uniform) and scenarios where the full manual excerpt works better (more traditional top-down lists of posts). |
It looks like this #65209 PR has stopped up.... |
What problem does this address?
The Post Excerpt has traditionally allowed limited HTML formatting (strong, em, etc), but it's being stripped by the Post Excerpt Block. Could we have an option to keep formatting?
People like being able to format their excerpts by hand for many reasons. Here's one case, where a WordPress.com user wants to add a little extra meta to the excerpt, and it works fine unless they use the Post Excerpt Block for designing their site. Other example use-cases include: haiku, adding links, sectioning off a part for emphasis, etc. This all gets removed in the Post Excerpt Block.
The workaround for now is to use some other posts-related block, but they don't offer as much control as the query loop.
What is your proposed solution?
The Post Excerpt Block has its own text-formatting features; OP wonders if that's why they're being stripped. Maybe we could only strip tags if one of those features is utilized, and otherwise display the inline HTML as entered?
The text was updated successfully, but these errors were encountered: