Make WordPress Core

Opened 22 months ago

Last modified 22 months ago

#56440 new defect (bug)

Embed blocks in widget areas caching in many posts

Reported by: eceleste's profile eceleste Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.0.1
Component: Embeds Keywords: dev-feedback
Focuses: Cc:


When I am using blocks for my widget areas I can include an oEmbed easily enough. For example, I might include a video in a sidebar or footer widget area using the embed Gutenberg block. This is great!

Then I notice that every single post that a user visits which displays that widget area as part of its templates will get duplicated post_meta entries caching the embed. This quickly pollutes the post_meta table with hundreds of duplicate entries for the same embed on different posts.

These "_oembed_xxx" and "_oembed_time_xxx" entries all have the same identifier for the "xxx" since they all come from the same embed in the widget area. Shouldn't these entries be associated with the widget area instead of the post?

In fact, why are these oembed cache values stored in post_meta at all? Isn't this the kind of thing that deserves more universal storage in case the same embed is used on more than one page in any circumstance?

Change History (3)

#1 @eceleste
22 months ago

It appears that there is an alternative to post_meta that is invoked when WP_Embed is used without a $post_ID. In those cases, the embed is cached as an "oembed_cache" post_type in the wp_posts table. This seems like what should happen when embeds are included in widget areas.

Maybe one approach would be to have the embed block never pass along the post ID to WP_Embed, which would force all these cached items into the posts table? Or at a minimum, to not include the post ID when it is being used anywhere outside of post_content?

Last edited 22 months ago by eceleste (previous) (diff)

This ticket was mentioned in Slack in #core-test by ironprogrammer. View the logs.

22 months ago

#3 @ironprogrammer
22 months ago

  • Keywords dev-feedback added

Thank you for your report, @eceleste!

Marked with dev-feedback for input from a component maintainer. This may require discussion as to why the caching works this way.

Note: See TracTickets for help on using tickets.