Embed Wistia videos in Flare

[sforsyth]

Hi folks,

I've been given some Wistia embed codes so that I can include some of our videos in the web help. The problem is, I just can't seem to figure out how to get Flare to accept the code.

Code: Select all

<script charset="ISO-8859-1" src="//fast.wistia.com/assets/external/E-v1.js" async></script><div class="wistia_embed wistia_async_put16wpyh6 popover=true popoverAnimateThumbnail=true" style="display:inline-block;height:84px;width:150px"> </div>

The problem seems to be with the <script> tag.
When I compile my project Flare appends file:// to the beginning of the source URL, so it converts this:

Code: Select all

<script charset="ISO-8859-1" src="//fast.wistia.com/assets/external/E-v1.js">

to this:

Code: Select all

 <script charset="ISO-8859-1" src="file://fast.wistia.com/assets/external/E-v1.js"> </script>

(It also won't accept the async tag so I removed it for testing.)
I've tried various ways of using CDATA tags to wrap the script, but to no avail. Has anybody solved this problem before? I can figure out how to insert scripts into Flare but not when they include the charset, src, and async parameters.

Thanks,
Sandra

[NorthEast]

I'd suggest:
* For the src, use http:// ; i.e. src="http://whatever"
* Instead of async, use async="async". Flare uses XHTML, which means you can't minimise attributes like you can in HTML (for info, see http://www.w3schools.com/tags/att_script_async.asp).

[sforsyth]

Thanks for your help Dave. The async="async" trick seems to work.

Unfortunately though adding http: to the beginning of the URL doesn't seem to work with Wistia, as Wistia won't serve up the videos when http: is included on the URL. I had similar issues with our web fonts on typography.com - when http: was added to the URL it wouldn't serve up fonts. Both of these systems are locked down and only serve up resources to approved domains, so it might be related to that somehow.

Sandra

[NorthEast]

That script tag is fine if you use the format I suggested, and it gets the js file from the URL. Try it out.

However, you div tag has a lot wrong with it - it has some mistakes, and also invalid XHTML (which has different syntax to HTML).

<div class="wistia_embed wistia_async_put16wpyh6" popover="true" popoverAnimateThumbnail="true" style="display:inline-block;height:84px;width:150px;"> </div>

[sforsyth]

Hi Dave,

I'm certain that the issue is with the "http" part of the URL. I've tested it on our servers both from within Flare output and from some basic HTML files, and in both cases simply removing the HTTP from the URL causes the videos to load - and adding the HTTP prevents the videos from loading. Perhaps Wistia isn't using the HTTP protocol to serve up the javascript? Wistia does a lot of fancy stuff to ensure that you can only embed videos on approved domains, so there might be something going on on their end that isn't compatible with HTTP. It's a question for them I guess.

I had the same "http" issue with our paid-for web fonts on typography.com (I found a workaround for that one though). I wonder if there is some common technique that these servers are using when they are providing paid-for services that can only be served up to certain domains.

And thanks for the tips on converting their code to something that Flare is happier with.

I think for now we're going to have to embed thumbnails of our videos and link to them on the Wistia site.

[NorthEast]

Ok, but it wasn't valid XHTML (or HTML), so it wouldn't have worked regardless of whether or not the js file was loaded.

You're trying to use a protocol-relative URL, i.e. a URL that begins with // instead of a protocol like http: , https: , file:
All that means is that when the browser gets the file, it will use the current protocol; e.g. if your page is on a server using HTTPS it'll use https:// , or if you're viewing the page locallly it'll use file://

However, Flare doesn't like protocol-relative URLs. I think Flare inserts a file: prefix in the URL in the output.
I'd suggest reporting that as a bug, so there's a chance it'll get fixed.

Therefore, you need to use a protocol that will work (match) where the page is hosted. I tried http: and it loaded the js file from Wistia with no problem.
So, if your server where you host this help uses https:, then use that instead of http:

[sforsyth]

Thanks Dave, that fixed it!

Our server does use HTTPS, so appending https (not http) does the trick. Thank you SO MUCH, that really solves a couple of problems for us!
Our entire doc team is doing a little happy dance today.

Sandra

[eddiebo924]

Hello,

I know this post is pretty old but I could use a little hand. I'm very close. For the most part the async="async" fixed up my issue. However, there are two other items I could use some direction on. First, the video will play fine when I look at it in the preview and when I build it it plays but the the video disappears unless you hover over it. Second, as you can see from the screenshot, once I place the code in the text editor the xml editor shows "Unsupported media". Any suggestoins? THANK YOU!