Many URLs require responding to a “Click to Enable” screen in Coda before being displayed as an EMBED.
Is there any workaround to this? If it is my own site I am trying to embed, is there something I can do so the Click to Embed is not needed?
Hey Richard, happy holidays! When loaded in “force=true”, mode, third-party embedded sites like yours may not load for other users properly depending on factors like the browser in use, whether they’re logged into the site, etc. Furthermore, these third-party sites can log some tracking information about users and slow the doc down, so that’s why we have this disclaimer in place.
Once you enable a site on your device, it should be remembered there and you shouldn’t have to click it again. We’ve had some discussions to let domain admins have a “whitelist” of sites that don’t need to be enabled, but had put off that work for now. Thanks for the feedback though, as that’s something we can look into in the future again.
Thanks @oleg
The site I would like to most enable is my own - thus I can test its performance in advance and therefore hopefully improve my Coda document’s design and usability by having the Embed displayed without any additional actions by my readers.
Is there something I can do on a site I create myself to make it embed-compliant in a Coda doc?
Makes sense. Until we build out support for an administrator embedding whitelist (which is pretty low priority at this time), you’ll have to click to enable.
I’m curious though if you’d ultimately be able to build out whatever you’re embedding directly with Coda? For instance, with a combination of buttons, formulas, and other controls.
@oleg - What I am trying to embed is a custom front-end to a MySQL database. I previously put in a substantial effort trying to do everything with Coda, but I realized that the database features of Coda seem to have a realistic upper end somewhere in the single-thousands of records. My database is considerably larger than that, so I decided to use MySQL.
I certainly could do the whole front end at this point with a typical HTML/CSS/Javascript website - but Coda has really nice potential as the primary user interface. So I was hoping to combine the best of both worlds and embed my database front end inside Coda.
It’s so close to being a win-win design - especially given your new option to create a public-facing document inside an iFrame. But “Click to Enable” at most works inside an organization; it is not very professional appearing to share with a client and certainly would not work for a public-facing document.
Ah, thanks for the context. Hopefully in the future we’d be able to support larger datasets (we have had some internal projects to support huge tables, but getting them fully supported is a fair bit of work).
Unfortunately, we can’t exactly get rid of the “Click to Enable” option. Besides the fact that some sites might not even display (i.e., sites setting the X-Frame-Options header can prevent being embedded, and just show up as a blank page without any error), external sites displayed without user consent can cause issues w/user privacy and unsafe content, so we’ve been treading carefully for now. We might be able to have some site-wide “whitelist” of trusted sites to embed, but that also isn’t super scalable.
One option I can suggest for now is to see if you can make your site compatible with http://iframely.com/debug, which we currently use for embeds without the force: true option.
1 Like
Thank you @oleg
Configuring my site to be compatible with the “iFramely protocol” works well - and it gives a variety of nice display options aside from just a straight embed.
Some more details are here for those interested:
One more gotcha…
It appears to me that no Embeds at all work when displaying a Coda doc in an iFrame; even “standard” Embeds that you support such as YouTube do not appear when I display the document in an iFrame as previously discussed in the thread referenced below… is this correct? Thus it seems that if I want to make a public-facing document, i.e. one which does not require that the reader have a Google account and login to Coda, then I cannot use Embeds in my public facing document - is that right?
Adding further to the EMBED mystery…
Officially supported URLs may be embedded in a regular Coda document as-is with no need for any other parameters:
=EMBED(“https://www.youtube.com/watch?v=36v9GSOFMFc”)
However, as mentioned in my post above, these URLs show up as blank if the Coda document is viewed in an iFrame.
OK but we know that the “Force” parameter works as a backup, right? Well not quite.
Let’s try Force on the same URL:
=EMBED(“https://www.youtube.com/watch?v=36v9GSOFMFc”,500,500,True)
This does NOT work in a regular Coda document, nor does it work in the Coda document viewed through an iFrame.
So it appears in summary that:
(1) Embedly-compliant URLs may be embedded in a regular Coda document, but cannot be viewed in an iFrame
(2) Non-Embedly-compliant URLs may be embedded in either a regular Coda document or via iFrame, but only using the Force parameter
Is this correct or am I doing something wrong?
Hey Richard - I think you’ve found a bug. Embeds are intended to still work even in embedded Coda docs. We’re reached out to our vendor (Iframely) to find a solution and will let you know as soon as possible (they’re usually pretty quick).
To give an update, getting embeds working in embedded Coda docs is technically a bit challenging and will take us some time to enable. Will post here when we have something to share.
Hello Oleg, experimenting with the benefits of CODA over Airtable I bumped into the same iframe issue as @Richard_Kaplan almost a year ago. Although I am a CODA newbie it seems all (security) settings are set correctly. I am very curious what the actual status is of this issue. Can you respond asap? Thank you!
Hello @oleg, I appreciate this thread. It’s been a couple of years since @Richard_Kaplan posted it. Have there been any updates since then? Thanks!