s9e Media BBCodes pack

s9e Media BBCodes pack 20231102

No permission to download
Overview FAQ Updates (315) Reviews (80) History Discussion
JoshyPHP said:
I think you meant the Lazy Load add-on; This add-on has a lazy load option but I don't think they interfere with each other. I can replicate the same issue on my local board with UI.X and with the default theme. I still don't know exactly what's wrong but I believe it will work better if you disable the deferred loading in this add-on (not the Lazy Load add-on.) Go to your admin panel, go to Options > s9e Media Pack, scroll down and choose "Load embedded content immediately."
Click to expand...

Yes, when I said 'lazy-load' I was referring to the s9e defer loading embedded content option within settings - not any other lazyload plugin.

Makes no difference which setting it is on.

181026 s93 settings.webp

I'm now experimenting with moving the helper file from s9e.github.io to my own domain to see if the issue is server response related. Early indications is a solid... maybe?? ...
 
Last edited:
mverta said:
We're having this same problem as well. Anybody find a solution?
Click to expand...
JoshyPHP said:
It works for me. Try Google Support, see why you're getting that error?
Click to expand...
I am also getting the same error when I try to post my own spreadsheet, but it works fine when I use the one that you linked, but anyway, I think the function to embed google sheets is pretty much useless if it can only be used with one sheet, the one that you linked. When I got the error, I clicked get shareable link, and anyone with the link can view it. Why isn't it working?
 
I tried that URL and it doesn't work because Google redirects the embed to a page that cannot be embedded. My guess is the URL is not the "Publish" URL for the document, but I can't tell based on the redirect alone.

I tried creating a new spreadsheet for myself and use the "Publish to the Web" link. New documents have a new kind of URLs and a new embed page for which I will add support soon. Otherwise, my best guess is that URLs that don't work don't come from the "Publish to the Web" dialog.
 
I just went back to the test post that I made on my site with that spreadsheet, and now the embed is working and I didn't change the link to one from the publish to web link, but now it is showing, weird.
 
CarpCharacin said:
I just went back to the test post that I made on my site with that spreadsheet, and now the embed is working and I didn't change the link to one from the publish to web link, but now it is showing, weird.
Click to expand...

It might be working for you because the sheet is owned by you and you are logged in to your google account - are you certain others can load and view the sheet??
 
skicomau said:
I'm now experimenting with moving the helper file from s9e.github.io to my own domain to see if the issue is server response related. Early indications is a solid... maybe??
Click to expand...

@JoshyPHP

Hosting the helper file on my own server definitely improved performance of Instagram loading correctly. But did not eliminate at it.

It appears that the primary purpose of the helper file is to provide notification for people who have ad-blocking or some other form of content blocking enabled - is that all it does or does the helper file perform some other important task?
 
The iframe hosted on GitHub is a sandbox; Its purpose is to load Instagram's script in its own environment. The error message that appears when Instagram's script is blocked or fails to load is just a bonus.

The iframe communicates with the host page (XenForo's) via cross-document messaging. Hosting the iframe on the same domain as the host page has an impact on the security model and on timing. That's the only difference I can think of between self-hosting and a third-party iframe. When I looked at the page back when it used the default iframe, I didn't see any errors in the console so I don't know how they factor in. I'll see if I can reproduce it locally, but I think I already tried that last time.

Ideally, if you could host a static version of the page that uses the self-hosted iframe and another that uses GitHub's, I could look for discrepancies. If you do that, remember to log out of XenForo or save the HTML in Incognito mode so you don't inadvertently leak any information that appears as the forum admin.
 
Twitter have changed the markup they use for embedded tweets, it's possible their new layout still needs some work.

I have uploaded a test page to see if a temporary fix can be implemented in the meantime. If you go to this test page you should see 4 identical tweets. If they differ, you can report here (which ones and how) and I'll take a look at it.
 
JoshyPHP said:
Twitter have changed the markup they use for embedded tweets, it's possible their new layout still needs some work.

I have uploaded a test page to see if a temporary fix can be implemented in the meantime. If you go to this test page you should see 4 identical tweets. If they differ, you can report here (which ones and how) and I'll take a look at it.
Click to expand...
Here’s what I see on mobile safari
 

Attachments

  • DED3DD99-538F-41A8-9ED4-8D9053D90F52.webp
    DED3DD99-538F-41A8-9ED4-8D9053D90F52.webp
    33.6 KB · Views: 7
I suppose it depends on the page's style then. You can try editing your media site in the admin panel to use one of the experimental iframes to see if it fixes your page. Any of these could work:
Code: 
<iframe data-s9e-mediaembed="twitter" allow="autoplay *" allowfullscreen="" data-s9e-livepreview-ignore-attrs="style" onload="var a=Math.random();window.addEventListener('message',function(b){if(b.data.id==a)style.height=b.data.height+'px'});contentWindow.postMessage('s9e:'+a,'https://s9e.github.io')" scrolling="no" src="https://s9e.github.io/twitter1.min.html#{$id}" style="background:url(https://abs.twimg.com/favicons/favicon.ico) no-repeat 50% 50%;border:0;height:186px;max-width:500px;width:100%"></iframe>
Code: 
<iframe data-s9e-mediaembed="twitter" allow="autoplay *" allowfullscreen="" data-s9e-livepreview-ignore-attrs="style" onload="var a=Math.random();window.addEventListener('message',function(b){if(b.data.id==a)style.height=b.data.height+'px'});contentWindow.postMessage('s9e:'+a,'https://s9e.github.io')" scrolling="no" src="https://s9e.github.io/twitter2.min.html#{$id}" style="background:url(https://abs.twimg.com/favicons/favicon.ico) no-repeat 50% 50%;border:0;height:186px;max-width:500px;width:100%"></iframe>
Code: 
<iframe data-s9e-mediaembed="twitter" allow="autoplay *" allowfullscreen="" data-s9e-livepreview-ignore-attrs="style" onload="var a=Math.random();window.addEventListener('message',function(b){if(b.data.id==a)style.height=b.data.height+'px'});contentWindow.postMessage('s9e:'+a,'https://s9e.github.io')" scrolling="no" src="https://s9e.github.io/twitter3.min.html#{$id}" style="background:url(https://abs.twimg.com/favicons/favicon.ico) no-repeat 50% 50%;border:0;height:186px;max-width:500px;width:100%"></iframe>
 
Hi @JoshyPHP not sure if this has been mentioned but when I have "Defer loading embedded content" checked, quite often only the top half of Tweets will display, and I'm not 100% sure but I think this issue is related to Chrome.

I think that the page is loading, the thread replies are loading and then the embedded tweets are loading after that but the space the tweets are supposed to occupy has already been set by the browser, so the bottom part of the tweet gets cut off.

I've unchecked "Defer loading embedded content" for now but it's a much less pleasant experience for the user, having the page bounce around while all the tweets load simultaneously so I'd like to have it checked if possible.
 
You must log in or register to reply here.

Similar threads

JoshyPHP
s9e Media Sites
108 109 110
Replies
2K
Views
140K
Goldie22
G
Saeed
  • Question Question
Embedding Scribd Documents
Replies
5
Views
3K
Saeed
Saeed
Top Bottom