Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#38059 closed defect (bug) (invalid)

'wp_trim_excerpt' is not stripping oembed url's like shortcodes before applying 'the_content' filter

Reported by: wordpressdevhdn's profile wordpressdevhdn Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Formatting Keywords:
Focuses: performance Cc:


The issue is performance related. We recently realized when more than 10 instagram urls are embedded into post directly via oEmbed urls, calling 'wp_trim_excerpt'(directly or indirectly via get_the_excerpt()) causes extreme slowness. If we wrap [embed]...embed shortcode around those urls, it does not cause any significant slowness. In context of function 'wp_trim_excerpt', both direct embeds and embedding with shortcode should result in same behavior and performance. So we should find way to strip shortcodes as well as any oEmbed urls before applying filter 'the_content'.

$text = get_the_content('');

$text = strip_shortcodes( $text );

/*We should strip any oEmbed urls here*/

/** This filter is documented in wp-includes/post-template.php */
$text = apply_filters( 'the_content', $text );

We're using version 4.5.3 but issue is also happening with latest development version.
To reproduce the issue, enable jetpack plugin(in our case) or any other plugins that calls 'wp_trim_excerpt'(get_the_excerpt()), and add more than 20 instagram oEmbeds url(but can be mix of any other oEmbed urls) to the post. The post should take a while(>20 secs) to load in front end.
The problem does not occur if we don't use Jetpack plugin or trigger wp_trim_excerpt function.
Expected behavior should take same time to generate as if we used [embed]...embed which is about few seconds. Actual behavior is it takes too long to load post in front-end(>20 secs).
It should happen in any environment since it's server side issue.

Change History (2)

#1 @swissspidy
8 years ago

  • Component changed from Embeds to Formatting

#2 @desrosj
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
  • Version changed from 4.5.3 to 2.9

Hey @wordpressdevhdn!

Welcome to Trac! First, I'm sorry that it took so long for someone to respond to this.

The only way that I am able to reproduce the issue you have described is to open the database and remove all _oembed_time_*key* and _oembed_*key* meta entries for the post (or have a plugin or theme that does something similar). Also, the issue will only happen for excerpts when using the Classic Editor, or the Classic Editor block in the new block editor.

The new block editor does not have this problem by default. The new excerpt_remove_blocks() function will remove all embed blocks before the excerpt is scanned for oEmbed URLs. The issue can be reintroduced if a plugin uses the excerpt_allowed_blocks filter to add an embed block, and there is code on the site removing oEmbed cahces, as described above. For example:

function myplugin_add_instagram_to_excerpt( $blocks ) {
	$blocks[] = 'core-embed/instagram';

	return $blocks;
add_filter( 'excerpt_allowed_blocks', 'myplugin_add_instagram_to_excerpt' );

Another thing to note is that oEmbeds are cached as they are loaded for the first time in both the front end and admin. So as they are added to the editor, they are also cached. So even when the post is viewed on the front end for the first time, displaying the embed should not require any external API calls.

I did look at the current version of Jetpack, and it does not appear that they are deleting oEmbed caches at all.

For these reasons, I am going to close this out. If you are still able to reproduce this with a fresh install, please add some more details so it can be investigated further.

Note: See TracTickets for help on using tickets.