WordPress Contributors Debate Dashboard Notice for Upcoming Facebook oEmbed Provider Removal

WordPress contributors are discussing different strategies for responding to Facebook and Instagram dropping unauthenticated oEmbed support on October 24. WordPress will be removing both Facebook and Instagram as oEmbed providers. When a user attempts to embed content by pasting a URL as they have in the past, they may not understand why it no longer works. They may assume that WordPress broke embeds, causing an increase in the support burden for this change.

A few participants on the trac ticket for this issue have suggested WordPress detect users who will be impacted and attempt to warn them with a notice.

“Since this may impact users unknowingly, it is possible to push a dashboard notice to users who have Facebook/Instagram embeds in their content, showing for site admins, as a one-off that can be dismissed,” Marius Jensen said.

“We’ve previously done post-update-processing to clean up comments, so the idea of looking over content for an embed isn’t completely outlandish, and would help with those who don’t follow WordPress’ usual channels to learn of this.”

Others don’t see the necessity. “Why should we make exception here?” Milan Dinić said. “It’s not the first time oEmbed support was discontinued for a provider, and I don’t remember anything specific was done then.”

There is still some uncertainty about what will happen with existing oEmbeds after Facebook updates its API. During a recent core developer meeting, Helen Helen Hou-Sandí confirmed that WordPress does not clear oEmbed caches regularly. “Technically oEmbed caches are cleared if you save and a valid response is returned, we do not do cron-based garbage collection,” Hou-Sandí said.

In a post today on the core development blog, Jake Spurlock assured users and developers that the existing embeds added before Facebook’s API change should still work:

Because oEmbed responses are cached in the database using the hidden oembed_cache post type, any embed added prior to the October 24th deadline will be preserved past the deprecation date. These posts are not purged by default in WordPress Core, so the contents of the embed will persist unless manually deleted.

Marius Jensen cautioned that there is still the possibility that existing embeds may not work going, depending on what Facebook does.

“We don’t know how they plan on implementing the use of unauthorized embed attempts,” Jensen said. “It could not return an embed code and your link would remain a plain link, or maybe they decide to return some kind of embedded ‘unauthorized’ content. I don’t think anyone has heard any specifics on how Facebook plans on doing this, so we’re all just kinda waiting to either hear more, or see what happens.”

Jensen said WordPress doesn’t re-check the cached results except when something changes with the post, but there may be plugins that clean up temporary data that may create an unpredictable outcome.

“The reliability of the caches are hard to determine (and being caches, it’s sort of in the term that it’s not guaranteed to always be there, but rather fetched and saved for a while when needed),” Jensen said.

Ideally WordPress’ oEmbed caches will prevent millions of embeds from breaking, but it’s still unknown how Facebook and third party plugins could change things.

Coming off a rocky 5.5 core update that deprecated jQuery Migrate and flooded official support forums with reports of broken sites, some contributors are wary of having another situation where users are left in the dark.

“I think a dashboard notice is desirable,” Jon Brown said. “Otherwise we’re not preemptively warning people in a way they can prepare and transition to another solution. We’re letting them know the same instant it’s going to break (when editing a specific post). I don’t think we can safely assume cached data is going to persist forever either, plenty of routines out there purge transient data before its stated expiration date.

“I see this as potentially being similar to the problems seen in dropping JQM. It’ll cause avoidable and silent breakage client side without even any error logging for a site developer to pick up on. In hindsight, what ideally would have happened with JQM would have been incorporating the detection code from Enable jQuery Migrate Helper into core temporarily, or simply installing that plugin automatically on behalf of users.”

Brown suggested WordPress detect calls to the cached embeds and warn users before the calls have the chance to fail so they can consider enabling a plugin to keep their embeds working more reliably.

The discussion remains open in the make.wordpress.org/core post and the corresponding trac ticket. Spurlock said WordPress will likely remove Facebook and Instagram oEmbed providers in the upcoming 5.6 release (scheduled for December 8) but it could also be shipped in a 5.x minor release that happens after October 24.