Almost all of my item live preview is broken

Hi there,

I just got a comment from user if preview link aren’t working, then I checked it

Envato preview load http content over https that make it not work, but I don’t have any control over it, since live preview url is actually using https not http.

Can Envato team fix it soon ?

Sorry I put it here, because I don’t find any support contact form for Author.


put slash ( / ) on the end of url for https to make it work
but it’s working fine if use http without ( / ) on the end of url

It’s a bit weird and confusing, please envato team make it more simpler and clear to avoid future confusion.

1 Like


Yes here also broken let’s tagging envato engineer team @rosssimpson could you please help this author ?
Or get in touch with envato market authro help center they would like to assist you with an official answer.



Hello :slight_smile:

Could you please try adding a trailing slash in the end of your live preview URL & Check ?

Replace with

1 Like

Hi @redfoc,

The preview page has a small bit of logic in it; if the demo URL from the author is plain HTTP, the preview page is served over plain HTTP. If the visitor accesses the page via HTTPS, they are redirected to the plain HTTP version. The same is true of demo URLs using HTTPS; the preview page is served over HTTPS and visitors using plain HTTP are redirected to the HTTPS version. This ensures that there are no mixed-content-warnings from the browser, and that the iframe target is actually loaded.

The issue you’re seeing is because your site is performing some strange redirects. When accessed as originally mentioned, over HTTPS but without a trailing slash, your site redirects to plain HTTP (!) with the trailing slash:

$ curl -I
HTTP/2 301

That’s unexpected, and what’s causing the problem here. Our site sees the HTTPS in the demo URL and serves the page over HTTPS, but then the redirect causes your site to be served over plain HTTP, and the browser’s security model refuses to load it (error message: “The page at … was loaded over HTTPS, but requested an insecure frame ‘’. This request has been blocked; the content must be served over HTTPS.”)

Following that redirect takes us back to HTTPS, this time with a trailing slash:

$ curl -I
HTTP/1.1 301 Moved Permanently

If we follow that redirect, we finally get a successful response from your server:

$ curl -I
HTTP/2 200

Whatever is performing that first redirect should be updated to use HTTPS, not plain HTTP. Using an HTTPS link with the trailing slash (as @baevox suggested) also works.