Adding app.screencast.com as an oEmbed provider

[brhodes]

This ticket is a request to have ​https://app.screencast.com added to the list of oEmbed providers.

TechSmith opened a ticket with you 8 years ago to add Screencast.com (original ticket: #38367). We have created a new version of Screencast with an updated domain name and new oEmbed api than the old ticket.

The new version of Screencast also has oEmbed endpoints and header metadata tags set up for unfurling.

Example embeddable URLs:
​https://app.screencast.com/<hash>/e or
​https://app.screencast.com/connector/embed/index/<hash>

The hash is unique for each content page.
E.g. ​https://app.screencast.com/jRnW7zEIqmf6w/e or
​https://app.screencast.com/connector/embed/index/jRnW7zEIqmf6w

[swissspidy]

What's the difference between Screencast Classic and the new one?

If this is a completely new app, then I think it would be good to fill out ​the questionnaire again.

A lot has changed in 8 years. From what I can see, there is no longer any API documentation whatsoever. The old URLs also have oEmbed discovery tags, whereas the new ones don't. If they had discovery tags, then maybe they don't even needed to be added to our allowlist because they just work.

Those are just 2 concerns I see at a glance.

[brhodes]

Here is an updated Questionnaire for this new version of Screencast.

Is the service popular enough for core developers to have heard of it before? Is it “mainstream?”

Developers may know of other TechSmith products such as Snagit and Camtasia which all integrate with Screencast to share images and video. ​Screencast Classic which is approved as an oEmbed provider by WordPress has been around for 15 years and hosts roughly 99 million pieces of content. The newer version of Screencast has been available for 2 years in October. We are in the process of moving all Screencast Classic users to the new Screencast and shutting down the Classic version at some future date.

If similar services are already supported, how does this service compare in terms of size, features, and backing?

The new Screencast currently has 440,000+ active monthly users and continues to grow as we migrate Classic Screencast Users to the new Screencast. As mentioned above, it integrates with many of TechSmith's other products including the latest versions of Snagit and Camtasia. Screencast is actively being worked on and supported by TechSmith.

Does this service have a large following on Twitter, Facebook, or other social media? Is its Twitter account verified?

Screencast itself doesn't have a Twitter account, but ​TechSmith does. The account is verified and has 31.9k followers. TechSmith also has a Facebook page ​here.

Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)

The oEmbed API on Screencast is fully supported and is currently in use with the live service. You can find the documentation on the ​oEmbed API Here. This was created for this ticket.

Does the service make an effort to build relationships with developers, such as through robust APIs?

We have APIs that allow other TechSmith products like Camtasia and Snagit to integrate into Screencast. But these are not public.

How old is the service?

Modern Screencast is 2 years old in October.

Does it have a well-established Wikipedia article?

Screencast does not have its own Wikipedia article, but TechSmith Snagit has a Wikipedia article ​here.

Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?

No, not for the new Screencast. There is an old unmaintained Screencast Classic plugin.

Is the provider frequently proposed?

I believe this is the first request. We have customers of Screencast that use WordPress and would love for their media urls to embed correctly in their pages.

---

Let me know if you have further questions.

[swissspidy]

Tentatively moving to future release milestone for consideration.

Would it be possible to add this documentation somewhere on the provider's website? The point about providing documentation is not for the sake of this questionnaire, but generally for developers.

Developers will look at your website to see if oEmbed is supported. And right now this can't be seen.

There's also this question:

Does the oEmbed endpoint work with WordPress’ oEmbed auto-discovery?

Could you add those oEmbed auto-discovery tags to your content?

Then we might not even need to make changes in WordPress, as it would just work.

[brhodes]

Sorry I missed that other question. I believe we do include the tags for oEmbed auto-discovery? But you may be referring to something else. Our media view pages include these links in the header.
​https://app.screencast.com/xNlN9BMD8Emli

I tried to embed media url as a content block in your test site and it failed. When looking at your docs I see you have the (old) Screencast block.
​https://wordpress.org/documentation/article/screencast-block/

I'm wondering if this was updated to the new url format then oEmbed would just work?

[swissspidy]

I was looking at ​https://app.screencast.com/jRnW7zEIqmf6w/e, which you provided in the description, and it doesn't have the discovery tags. ​https://app.screencast.com/xNlN9BMD8Emli does have them though.

Both pages however return a HTTP 404 status, so WordPress does not attempt auto discovery. Is this something you can fix?

That's why the embed failed for you when you tried it.

And yes, the Screencast Block would need to be updated, but that's what this ticket here is for :-)

[brhodes]

When you say "Both pages however return a HTT 404 status" are these the pages you are referring too?

https://app.screencast.com/api/v1/oembed/.json?url=https://app.screencast.com/xNlN9BMD8Emli
https://app.screencast.com/api/v1/oembed/.xml?url=https://app.screencast.com/xNlN9BMD8Emli

We are in the process of fixing an issue where the url should be encoded. So wondering if that could be the issue?

[swissspidy]

When I visit https://app.screencast.com/jRnW7zEIqmf6w/e and https://app.screencast.com/xNlN9BMD8Emli they both return a 404.

$ curl -I https://app.screencast.com/xNlN9BMD8Emli
HTTP/2 404 

That looks wrong to me.

If they'd return a proper 200 status, then the discovery & embedding will probably work.

[brhodes]

Thank you for clarifying. I'll bring this back to my team.

[brhodes]

We have fixed HEAD requests on ​https://app.screencast.com. So those links should now return 200.

I wanted to clarify that for now we do want to keep the ​https://wordpress.org/documentation/article/screencast-block/ working as is for those users of our Classic Screencast site.

So our ask is the addition of the new Screencast media.

[swissspidy]

So our ask is the addition of the new Screencast media.

We'll get there :) But first we need to ensure your oEmbed endpoint is standards-compliant. Right now this isn't the case. Once it is, it will work with WordPress out of the box.

We have a certain standard for oEmbed providers in core. In order to add a new one to the existing allow-list, they must:

1. be well-established, popular, and mainstream services,
2. properly and fully implement the oEmbed specification,
3. and clearly be a trusted provider.

Right now at least (2) is missing.

Glad you fixed the HTTP status issue, but there are more problems.

Here are some of my observations:

Issue 1: Missing oEmbed discovery tags

​https://app.screencast.com/jRnW7zEIqmf6w/e does not contain any <link> tags with oEmbed discovery markup.

Weirdly enough, ​https://app.screencast.com/xNlN9BMD8Emli does contain them.

Why is that?

If both support embedding, you should add the discovery tags to both.

Issue 2: incorrect markup

The "+" (plus sign) character in the <link> tag's type attribute is mistakenly encoded.

This is the markup you serve at ​https://app.screencast.com/xNlN9BMD8Emli:

<link rel="alternate" type="application/json&#x2B;oembed" href="https://app.screencast.com/api/v1/oembed/.json?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli" title="(9&#x2B;) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28 oEmbed Profile" />
<link rel="alternate" type="text/xml&#x2B;oembed" href="https://app.screencast.com/api/v1/oembed/.xml?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli" title="(9&#x2B;) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28 oEmbed Profile" />

This should be type="application/json+oembed", NOT type="application/json+oembed". Ditto for type="text/xml+oembed", which should be `type="text/xml+oembed"

According to the screenshot you shared on ​https://app.screencast.com/xNlN9BMD8Emli?conversation=zTolDBzVZxpcYJUNWHzku0, this appears to have been correct at one point but regressed.

So this needs to be fixed.

Issue 3: incorrect oEmbed response (photo vs rich)

​https://app.screencast.com/api/v1/oembed/.json?url=https%3a%2f%2fapp.screencast.com%2fxNlN9BMD8Emli returns the following response:

{
  "type": "photo",
  "version": "1.0",
  "title": "(9+) frame_08.png - TechSmith Screencast - 2024-09-10_13-46-28",
  "author_name": "Benjamin Rhodes",
  "provider_name": "TechSmith Screencast",
  "provider_url": "https://app.screencast.com",
  "width": 1434,
  "height": 70,
  "html": "<iframe scrolling='no' frameborder='0' style='width: 1434px; height: 70px; border:0;' src='https://app.screencast.com/connector/embed/index/xNlN9BMD8Emli' allowfullscreen></iframe>",
  "url": "https://app.screencast.com/xNlN9BMD8Emli",
  "thumbnail_url": "https://app.screencast.com/xNlN9BMD8Emli/thumbnail",
  "thumbnail_width": 320,
  "thumbnail_height": 180
}

According to ​https://oembed.com/, the photo type must return URL to a photo file.

However, what you are returning is an html field with an <iframe> code.

If you want to keep photo, return a proper photo URL and remove html.
If you want to return an iframe embed code in html, switch to type: rich.

Additional recommendations

Some additional things I noticed when embedding those URLs. Not blocking for this ticket but I thought I'd share it nonetheless.

• Embeds throw errors trying to set cookies when the iframe is sandboxed
• Embeds should probably have a minimum height. Embedding ​https://app.screencast.com/connector/embed/index/xNlN9BMD8Emli with a height of 70px cuts off all the emoji reactons and the Screencast logo. See ​https://i.imgur.com/OehbtFJ.png for an example.
• There are console warnings for using document.write(), which is discouraged. See ​https://developers.google.com/web/updates/2016/08/removing-document-write
• There are console warnings for non-passive event listeners, which is bad for performance. See ​https://www.chromestatus.com/feature/5745543795965952

[brhodes]

Thank you for the detailed feedback. Addressing your first issue.

Issue 1: Missing oEmbed discovery tags

The site currently expects a user to share media in two ways.
1) User shares a link to the video / image, we want them to share the view page url.

https://app.screencast.com/(media_id)

2) A user can also get an iframe markup to embed in their site from the view page. This markup uses the follow link structure in the iframe source.

https://app.screencast.com/(media_id)/e

format. We don’t expect anyone to directly share the /e url and that is why we don’t include those links in that page.

We will work on the other issues you have pointed out.

[brhodes]

How are you looking at those link tags? I just checked this out in Chrome, Safari, Firefox and Edge devtools and the encoding is all correct for me.

​https://app.screencast.com/YAdPyx6PygL6N

[swissspidy]

I'm viewing the source code directly, not in devtools. That makes a difference.

[brhodes]

We have now fixed the encoding issue with the link types and changed our images to use 'rich' type instead of 'photo'

Thank you for pointing out those issues.

[brhodes]

Hello, I'm checking in to see if there is anything else we need to do to move this forward? Thank you.

[swissspidy]

Thanks for the ping. As per my previous comment, it's important that a provider and the oEmbed API is well-established and well-documented. Right now my impression is that the endpoint is still in its infancy and not yet mature. The fact that the endpoint didn't adhere to the discovery spec until it was pointed out here confirms that.

So regarding that point, my main guidance right now is to just wait and see this become more established and robust. We can then revisit this next year or so.

Note: That's also why I recommended moving the documentation from ​https://docs.google.com/document/d/1NzamkRo1NKYc6leCuu1wvAolQAU2L4hItzPN60e-BzU/edit to a public website.

Ideally another core contributor here chimes in as well so we can hear their thoughts. (cc @azaozz @peterwilsoncc)

---

The good news is with your latest fixes the oEmbed discovery now works for your content as expected! i.e. you can drop a Screencast URL in the editor and it gets embedded.

The downside is that the embed won't load. That's because the iframe is sandboxed (since the provider isn't allowlisted yet), and you are loading some JavaScript that tries to access document.cookie. That doesn't work because of the sandboxing and results in a SecurityError

Then there are also some console warnings about the page using document.write.

You can reproduce this using the following snippet that's generated by WordPress:

<iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" title="oEmbed link type encoding" scrolling='no' frameborder='0' width='500' height='75' src='https://app.screencast.com/connector/embed/index/YAdPyx6PygL6N#?secret=66UvUE2BUq' data-secret='66UvUE2BUq'></iframe>

If your content can at least be displayed in such a sandboxed iframe, that makes it easier for everyone on the web to leverage your oEmbed endpoint and help make it more established and stable.

[brhodes]

I do want to clarify that ​https://app.screencast.com isn't a new provider, but a rewrite and migration of www.screencast.com. We expect by the end of this year all the existing users of www.screencast.com will be migrated over to ​https://app.screencast.com and the old site will be shut down next year.

We have existing customers of Classic Screencast unhappy that now they are migrated to the new Screencast their media no longer works in WordPress.

We did have some issues with how we implemented oEmbed in app.screencast.com, but depending on the tool we used to test oEmbed these tools unfurled the media even with the errors you pointed out. But I'm glad we are in a better spot with oEmbed support.

To your point about sandboxing, if I understand you correctly when ​https://app.screencast.com is on the allowlist the iframe will contain:

sandbox="allow-scripts allow-same-origin allow-presentation"

"allow-same-origin" is required for our view page to work and testing out our Screencast Classic embeds that value is added to the sandbox attribute for those media.

We do not plan on getting our media iframe embeds working without "allow-same-origin".

The last point about public api documentation, this is something I believe we can make happen.

[swissspidy]

Slight correction: sandboxing is not applied for allowlisted embeds.

[brhodes]

Thanks for the correction, but in the case of our existing www.screencast.com media it was part of those embeds from my testing today. And if the sandboxing attribute is used for app.screencast.com we would need "allow-scripts allow-same-origin" for our media to work.

[brhodes]

Just a quick update. We have moved the oEmbed api documentation to a public Github repository ​https://github.com/TechSmith/screencast-public-api-docs/blob/main/sections/oembed.md.

[dustintechsmith]

Hey WordPress team. I am working with the dev team as the product manager on Screencast. We currently have a remaining 6,000 customers that we need to move but cannot as this wordpress issue would impact them greatly. We need to move them by end of February 2025. What more is needed to resolve this issue?

[swissspidy]

Thanks for the ping & publishing the documentation more properly.

Moving to 6.8 for consideration.

[audrasjb]

As per today's bug scrub: It appears this ticket is still needs a patch. As 6.8 beta 1 is very close, I'm moving it to Future Release. Feel free to move it back to 6.8 if it can be committed by Monday.

Trac ticket: https://core.trac.wordpress.org/ticket/61941

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

## Unlinked Accounts
The following contributors have not linked their GitHub and WordPress.org accounts: @nhatkar@….

Contributors, please ​read how to link your accounts to ensure your work is properly credited in WordPress releases.

To understand the WordPress project's expectations around crediting contributors, please ​review the Contributor Attribution page in the Core Handbook.

Please use @nikunj8866 WordPress profile.

[SirLouen]

Test Report

Description

✅ This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8687.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.4.6
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.4.6)
• Browser: Chrome 136.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Reproduction Steps

1. Create a new Post
2. Add a new Embed Block
3. I'm using this URL: ​https://app.screencast.com/PPiJZaHPkSNxP

Expected Result

1. Embedded shows correctly.

Actual Results

1. ✅ Issue resolved with patch.

Additional Information

It can be safely added to 6.9.0
Remember to ​update the section to this version

Supplemental Artifacts

Embedded example:

[sandeepdahiya]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8687.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Firefox 139.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Embeds from Screencast are showing as expected.

Additional Notes

• Created a new post, Embeded URL ​https://app.screencast.com/PPiJZaHPkSNxP and it is showing nicely in editor as well as front end post.

Supplemental Artifacts

Editor: ​https://ibb.co/TMd3YHLY
Frontend: ​https://ibb.co/nqnSwDps

[peterwilsoncc]

Sorry @swissspidy, I missed your ping many months ago.

While attempting to test this ticket, I'm having trouble finding an index of content available to be embedded. ​https://app.screencast.com/ is a marketing page detailing types of account and costs.

If I sign up, can I see an index of all content or simply an index of my own content? If so, is there any intention to make that public?

Without an obvious index of content, I am struggling to see how this benefits a significant percentage of WordPress users.

[SirLouen]

Replying to peterwilsoncc:

Without an obvious index of content, I am struggling to see how this benefits a significant percentage of WordPress users.

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

Similar to SmugMug, I've reported already #63556

[SirLouen]

Given the reported nature of SnagIt (Entreprise solution, not open to public), I'm adding this as a candidate for wontfix

[brhodes]

I'm not sure what the confusion is with this ticket. Our customers want to embed a specific image or video into their WordPress page. To do that they are use the site url with the HASH that maps to that media.

[SirLouen]

Replying to brhodes:

I'm not sure what the confusion is with this ticket. Our customers want to embed a specific image or video into their WordPress page. To do that they are use the site url with the HASH that maps to that media.

No confusion, basically this is an Enterprise solution, ​closed for paying customers.

WordPress is not supporting this kind of oEmbed with a "premium" nature. If you need to provide such, you should build your own plugin block with the oEmbed for your customer. In fact, this raised me the curiosity to search for other oEmbeds that are of the same nature, like SmugMug, and they should also be wiped.

[brhodes]

Screencast has a totally free tier with an option to buy a Pro subscription. The free option limits the total number of videos you can host at one time.

[SirLouen]

Replying to brhodes:

Screencast has a totally free tier with an option to buy a Pro subscription. The free option limits the total number of videos you can host at one time.

Is there a public directory or listing?
​Like this

[brhodes]

Screencast does not provide a public library view of someones content. The owner of the media (or anyone with the link) has the option to share a specific image or video with others using the direct link.

[SirLouen]

Replying to brhodes:

Screencast does not provide a public library view of someones content. The owner of the media (or anyone with the link) has the option to share a specific image or video with others using the direct link.

This is the prerequisite of eligibility that @peterwilsoncc was informing here.

There is a rule on WordPress that features should technically favour the majority (not a minority that uses the service). If it only favours a minority, it should go into the realm of plugins.

[dustintechsmith]

I am trying to understand this better. Anyone can create a Screencast account it's not restrictive on creation or even image uploads. We don't allow a crawler to traverse this site but rather allow individuals to share images that they want to be shared in specific locations. There are no restrictions on the link itself other than you must have the specific target to view the content. This allows all of the user base of Screencast to share specific images and videos that they would like to be consumed on WP which would benefit creators abilities to share information with their visitors.

How does that not favor the majority?

[SirLouen]

Replying to dustintechsmith:

I am trying to understand this better. Anyone can create a Screencast account it's not restrictive on creation or even image uploads. We don't allow a crawler to traverse this site but rather allow individuals to share images that they want to be shared in specific locations. There are no restrictions on the link itself other than you must have the specific target to view the content. This allows all of the user base of Screencast to share specific images and videos that they would like to be consumed on WP which would benefit creators abilities to share information with their visitors.

How does that not favor the majority?

Yes, I can agree with you.

In fact, it makes sense, as, for example Videopress is whitelisted and serving basically a similar service.
There are some policies around that are complex.

My advice is that you come next devchat (18th June, 3PM GMT @ Slack channel #core) and bring this topic (in general) and see the popular opinion about this topic.

I'm not going to dig further on this because I feel we are entering the swampy waters.

[brhodes]

I still don't know the fate of this ticket?

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.

It looks like the patch was made and tested to get this to happen. So why now the desire to bury it?

[SirLouen]

Replying to brhodes:

I still don't know the fate of this ticket?

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.

It looks like the patch was made and tested to get this to happen. So why now the desire to bury it?

It's not a desire to bury it. It's just an opportunity to reevaluate whether it is time to bury it or not. Generally, when these "events" happen (changing URL like in this case), many things have to be considered. There is a backwards compatibility policy that somewhat inhibits removing things that work. But since screencast will be deprecated in favour of app.screencast, that doesn't really exist in WP yet, there won't be backward compatibility issues in case its not added (and screencast removed when they deprecate it). As I said, it's a big opportunity to reevaluate and decide if screencast will be merged into a newer version, or if it's time to fully wipe this.

Services with oEmbed whitelisting change a lot over the time from what they were originally, and the only thing that "saves them" is the backwards compatibility policy I was talking about before. But still, as I said @dustintechsmith if you want this to progress, this is something to be discussed openly in a dev-chat

The fact that this has a patch, that was brought by me in my last bug-scrub and has been code-reviewed, still is not enough to make a pass. Still, Joe, was willing to speak with the managers of Screencast to see if they could add some accessibility features to the resulting oEmbed. Maybe if they are willing to collaborate, this could pass anytime soon.

[swissspidy]

Replying to SirLouen:

Replying to brhodes:

Screencast does not provide a public library view of someones content. The owner of the media (or anyone with the link) has the option to share a specific image or video with others using the direct link.

This is the prerequisite of eligibility that @peterwilsoncc was informing here.

There is a rule on WordPress that features should technically favour the majority (not a minority that uses the service). If it only favours a minority, it should go into the realm of plugins.

A public library or feed is not a prerequisite according to ​https://make.wordpress.org/core/handbook/contribute/design-decisions/#adding-new-oembed-providers, last I checked.

The only thing that comes close is the popularity/mainstream requirement.

[dustintechsmith]

We invested several cycles ensuring as we spun up new back end infrastructure. This was to keep our existing Screencast functioning on a newer tech stack. A great amount of attention went towards keeping original content working. We didn't want to spin up a subdomain but determined that was the only way to tackle a graceful transition. As such we custom built a proxy that will translate original screencast.com links to app.screencast.com targets.

We have several customers complaining that we "broke" functionality in WordPress. However, every other application(or web service) that unfurls or embeds content is still functioning. The content has not changed, just merely the DNS resolution for the content is pointing at a subdomain of the original domain. Not supporting this new subdomain of the original service is taking away actively used embeds from existing customer implementations.

[dustintechsmith]

What would it take to stop harming these users and penalizing existing embeds? Even if we don't allow new embeds I am really advocating for our users that have existing content in the wild.

[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.

Not having a browseable library also doesn't make a difference, as @swissspidy mentioned. It's a minor barrier to testing - if the test samples in the ticket go away, we'd need to create accounts to be able to test; but this isn't that much of a problem.

Also, @dustintechsmith - we don't currently have a release date for WordPress 6.9, which is probably the soonest this would go in - it's an unlikely candidate for a minor release. We're not in a rush to resolve this because it's not imminent.

My testing of this PR yielded inconsistent results; the media URLs included in the original ticket weren't working. Is this expected? Are those resources not using the updated specs?

[SirLouen]

@joedolson did you take any of the data provided in any of the two testing reports here? this or this

[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.

[SirLouen]

Replying to 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.

This is, probably, the moment when Peter discovered why public testing artifacts were useful for providing support for an oEmbed without having to doing all the registering process through their enterprise system or without having to deal with the support representatives.

Just for QA purposes, I think I'm going to take some time this weekend and do a quick audit for the current oEmbeds and deliver this for the next dev-chat. As we commented, this is nothing very fascinating, but I think that something public, easily accessible, should be like the minimum essential for an oEmbed support, then the rest of the categories.

Tomorrow they change whatever thing in their embedding code, and we have here a number of guys creating a report with the problem and for anyone to develop, test and review the patch, having to do a whole research including having to register on a service you are not even going to use, to find out what is going on.

And this is still as easy as creating a simple plugin and listing in the repo. Anyway, as you said, until 6.9 there are still months to go.

[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 ​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.

[brhodes]

@peterwilsoncc

Are you referring to these example links? If not can you be more specific?

• ​https://app.screencast.com/jRnW7zEIqmf6w/e or
• ​https://app.screencast.com/connector/embed/index/jRnW7zEIqmf6w

https://api.screencast.com/external/oembed

Is the URL for the old version of Screencast which is now shut down. We migrated all of the user content to the new version of Screencast so we could shut down the old service.

[peterwilsoncc]

@brhodes Yes, they are the links I am referring to.

​https://api.screencast.com/external/oembed [i]s the URL for the old version of Screencast which is now shut down...

Understood and that is my concern.

WordPress is considered about services added to the allow list for this reason. As an external dependency they need to be stable to avoid breaking WordPress.

By returning a 410 Gone response rather than migrating/redirecting to the new endpoint demonstrates a lack of stability.

[peterwilsoncc]

I've reviewed the current state of the existing embeds, ie embeds that WordPress users have added to their site since screencast.com's inclusion in WordPress 4.8:

• thumb.screencast.com no longer resolves
• legacy URLs of embedded content on content.screencast.com no longer work, eg https://www.screencast.com/users/RalphNeighbour/folders/BASIC%20PRESENTATIONS/media/f46c7521-abdd-477e-8782-02a9ed87ec6e/embed

This has broken all previous embeds.

Updating the oembed endpoint in newer versions of WordPress won't fix this issue for legacy URLs as the embed code is cached in post meta.

The only way legacy embeds can be fixed is the thumb... and content... domains to be redirected from the legacy URLs to the new URLs.

At a minimum WordPress needs to remove the old URLs from the allow list.

As screencast.com has a history of breaking embeds, I am not inclined to add the new URL to the allow list.

I may change my mind if the following occurs:

• legacy thumbnails redirect to https://app.screencast.com/<hash>/thumbnail
• legacy content iframes redirect to https://app.screencast.com/connector/embed/index/<hash>
• details are provided on how any future URL migrations will occur and what plans are in place to prevent further breakage of WordPress embeds.

A refactor of systems at screencast.com has broken existing embeds and removed the existing oembed endpoint.

https://api.screencast.com/external/oembed now returns a 410 Gone response.

See the lengthy discussion on the ticket from comment 35 onwards.

Trac ticket: https://core.trac.wordpress.org/ticket/61941

[paulstanos]

Hi Peter. My name is Paul Stanos, lead developer of Screencast Classic. I wanted to jump in here and give some additional context on the history of these URLs and why some my not be resolving anymore.

thumb.screencast.com no longer resolves

That's true, though to my knowledge we never provided those URLs for users of Classic to copy-paste. The oembed API may have returned them, but it's not intended for direct usage by users.

From your post, it sounds like these are cached URLs pulled from the oembed endpoint?

legacy URLs of embedded content on content.screencast.com no longer work

Back in 2019, we stopped generating embed codes with content.screencast.com links. Instead, we use the /embed style URL on the www.screencast.com domain, like the one you provided.

When we shutdown Classic in 2025, most direct content.screencast.com URLs stopped working. We were able to maintain links to images, but not videos due to technical limitations of the new storage backend.

I understand that creating dead links isn't ideal, but hopefully this added context shows that we did take steps to minimize this, and gave a long runway for old links to get used less and less over the years.

This has broken all previous embeds.

When we migrated content from Classic into the new system, we created redirects for /embed links where possible. However, the URLs that are cached may no longer be valid for other reasons.

Content that was deleted, moved, or made private are some of the common reasons that these URLs don't work anymore. The example link you gave is a result of that content having been moved to a different folder, making the URL invalid. This is not a result of the migration, but of the user making changes on their end.

Given what I recall about our implementation and testing, there should be /embed URLs that are still valid and will properly redirect to their location in new Screencast.

---

Hopefully this gives a greater understanding of the decisions made and our efforts to maintain links working where reasonable.

+1 to backporting to 6.8.2 (but not 4.8.2 thanks). The "Removed" version number will need to be changed.

I confirm we'll want to backport this to branch 6.8.

[audrasjb]

Adding dev-feedback to double sign-off the decision of removing existing endpoints for Embeds for now (as proposed in the related PRs), and to backport it to branch 6.8.

Adding needs-dev-note and needs-user-docs workflow keyword as well.

[peterwilsoncc]

In 60345:

Embeds: Remove screencast.com from oEmbed allow list.

Screencast have updated their URL structure to use a sub-domain and the prior oEmbed endpoint in the allow list now returns a 410 Gone response.

For discussion regarding the legacy endpoint refer to #61941, comment #35 onwards.

See #61941.
Props audrasjb, brhodes, dustintechsmith, joedolson, johnbillion, nikunj8866, paulstanos, peterwilsoncc, sandeepdahiya, sergeybiryukov, sirlouen, swissspidy.

Merged:

• r60345
• ​https://github.com/WordPress/wordpress-develop/commit/15fb5354ecc71bf34ae2bb181a792851e627f899

[dustintechsmith]

Possibly a zoom call or scheduled call could be useful here. This is a user that changed a variable that broke an existing embed we were using for testing. Essentially the customer removed that media so the error statement is valid. We took extreme care to ensure that things would not break during this change of URLs. As described above we can't prevent users from deleting or moving their content to a more permission restrictive location and thereby breaking an existing link. We do support all content that a user previously embedded with the URL screencast.com. I think this is a disservice to those leveraging this that have not moved their content in the service and want to keep links functioning. We are taking something away from that group. I have been shielding our customer complaints from this ticket and saying we are working with WordPress but I can start directing them here to convey this concern.

[johnbillion]

@dustintechsmith This is not a Screencast tech support avenue. It is inappropriate to suggest sending support requests for your commercial service to an open source project maintained mostly by volunteers. I understand that launching new infrastructure and continuing to support old data is a significant undertaking, but this "disservice" is a problem of your own making.

[jorbin]

@dustintechsmith Please also remember that you are welcome to ​create and submit a plugin to the WordPress Plugin Repository if you would like to provide embed functionality for your users.

[jorbin]

[60345] looks good to me for backport to the 6.8 branch.

[johnbillion]

There are two separate issues being discussed in this ticket.

1. All existing Screencast oEmbeds have been broken. This has nothing to do with WordPress.
2. The new app.screencast.com URL format is not supported by the oEmbed allow-list in WordPress.

Recap of where this issue is at:

• All existing Screencast embeds are broken because the thumb.screencast.com and content.screencast.com domains no longer resolve.
• The api.screencast.com oEmbed endpoint no longer works.
• It is not possible to embed a new-style app.screencast.com link into content in WordPress because a) the URL format is not supported, and b) the api.screencast.com oEmbed endpoint no longer works.
• Due to the above, support for Screencast will be removed from WordPress when 6.8.2 ships in July.
• A decision needs to be made on whether adding support for app.screencast.com (and its new oEmbed endpoint) should be added to WordPress.

[johnbillion]

In 60354:

Embeds: Remove screencast.com from oEmbed allow list.

Screencast have updated their URL structure to use a sub-domain and the prior oEmbed endpoint in the allow list now returns a 410 Gone response.

For discussion regarding the legacy endpoint refer to #61941, comment #35 onwards.

Merges [60345] to the 6.8 branch.

See #61941.
Props audrasjb, brhodes, dustintechsmith, joedolson, johnbillion, nikunj8866, paulstanos, peterwilsoncc, sandeepdahiya, sergeybiryukov, sirlouen, swissspidy.

[audrasjb]

Closing this ticket as fixed for milestone 6.8.2.