[wp-trac] [WordPress Trac] #61941: Adding app.screencast.com as an oEmbed provider

[WordPress Trac]

#61941: Adding app.screencast.com as an oEmbed provider
-------------------------------------------------+-------------------------
 Reporter:  brhodes                              |       Owner:  joedolson
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Embeds                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch needs-user-  |     Focuses:
  docs                                           |
-------------------------------------------------+-------------------------

Comment (by peterwilsoncc):

 I'm catching up on this, so responding to a few comments all at once:

 > @SirLouen
 > I see your concern. Now that I'm looking a little bit deeper, I can't
 see a public place to see these. This oEmbed feels more like enterprise
 solution

 > @swisspidy
 >  A public library or feed is not a prerequisite according to
 [https://make.wordpress.org/core/handbook/contribute/design-decisions
 /#adding-new-oembed-providers the allow list docs], last I checked.
 >
 > The only thing that comes close is the popularity/mainstream
 requirement.

 I agree with both of these.

 My concern is that there doesn't appear to be a way for WordPress users to
 find content. It appears the only content a screencast user can embed is
 their own.

 Other supported services don't have full public listing, but discovery of
 anyone's post is relatively easy. I don't follow ABC News on social media
 but can easily find their content on YouTube, Facebook, Twitter, Bluesky,
 etc.


 > @joedolson
 >
 > I don't think the 80/20 rule should apply to OEmbed providers; it's
 never going to be realistic to consider that a service needs to be of use
 to 80% of users; that would prevent us from ever supporting a lot of
 extremely valuable services.

 I agree with this. The embed feature passes the 80/20 rule but WordPress
 can't expect every service to have 80% penetration.


 > @joedolson
 >
 > Yes; those worked, but the original submitted URLs didn't. I want to
 know whether that's intentional. It's not a good implementation if there's
 inconsistency in how the endpoint resources behave, so I want to explore
 further *why* specific resources aren't working.


 > @brhodes
 >
 > We are just asking to get https://app.screencast.com on the allow list
 to use our oEmbed implementation for media. This site is a replacement for
 https://www.screencast.com which was already on the WordPress allow list.
 All our users from the old site have been migrated over to the new one.

 OK, I didn't understand this. There is a difference between updating old
 services nad adding new services.

 As Joe mentions, neither of the URLs on the previous ticket resolve
 anymore, is that because the content has been deleted or because old URLs
 are all set to redirect to the new home page?

 The old embed endpoint is returning a 410 Gone response:

 {{{
 $ curl -I https://api.screencast.com/external/oembed
 HTTP/2 410
 date: Thu, 12 Jun 2025 23:53:26 GMT
 [...snip...]
 }}}

 Does that mean that the embedding of previous content URLs has been
 broken? If so, this concerns me greatly as WordPress tries to support
 services that show stability in embeds.

 After Facebook and Instagram broke embeds, I think this has become more
 difficult to predict so past behaviour of a service is important to
 consider.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61941#comment:55>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform