Make WordPress Core

Opened 3 years ago

#52935 new defect (bug)

oEmbed cache is no longer refreshed upon post update

Reported by: davidbinda's profile david.binda Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.0
Component: Embeds Keywords:
Focuses: Cc:


Before the Block editor was introduced, an AJAX request was used for refreshing oEmbed cache of a given post upon it's update.

See related code:


However, this code is no longer being triggered by the block editor for multiple reasons ( post update is happening via REST API, thus there is no redirect and the edit_form_advanced action prints only hidden fields in the block editor ), and even if it were, the WP_Embed::cache_oembed does not seem to properly parse the Block's editor notation. So, even switching to classic editor and updating the post won't make the oEmbeds to refresh.

The only way to refresh oEmbeds is a WP CLI command ( see ).

Due to the way the Block editor handles display during the editing part and it's discrepancy in the front-end displaying part, an embed which, for whaterver reason failed to cache ( there is this {{unknown}} post meta for the URL stored in the database ), the embed may appear working in the edit post screen, but would appear broken when rendered on frontend.

Steps to reproduce / debug the issue would be:

  1. adding a mu-plugin blocking any oEmbeds ( eg.: add_filter( 'pre_oembed_result', function() { return false; }, 11 ); ),
  2. create a new post with YouTube oembed
  3. view the post, see it's broken
  4. remove the mu-plugin
  5. open the post in editor, see YouTube working, eventually try to re-save the post
  6. view the post on front-end, see it's still broken

The above steps do not produce broken oEmbed in the last step, when all are performed in the classic editor.

While there is a WP CLI command for refreshing the oEmbed cache, there is no longer an easy way for a user w/o access to the server to refresh the oEmbed cache (which used to be as easy as re-saving the post).

Perhaps a cache refreshing logic could be introduced server-side, during the post update action?

Change History (0)

Note: See TracTickets for help on using tickets.