Is there any capability for a remotely-hosted attachment, ie. images hosted on a different server but which can display as attachment thumbnails in Airtable?
Let’s say, I have many images hosted on S3/Cloudinary…
If I have a URL field containing the URL of an image, is there any way to make that image display as thumbnail content within Airtable?
Or even to function at the same level as an attachment?
I think you’re looking for the functionality demonstrated here but I’m pretty sure there is no way to do this. You might be able to do it in the new Interfaces feature.
As @Bill.French mentioned above, this is not possible with Airtable’s native features.
If you switch to Google Drive, you might get some satisfaction from using Airtable’s URL Preview app, although it only displays one preview at a time, and it’s not within the main Airtable interface.
Similarly, Airtable’s Embed App will display any webpage in the app panel, but it has the same problem of not being within the main Airtable interface, and it will only display one webpage at a time.
However, I have at least 4 clients who are doing exactly what you are trying to do by using Make.com as their automation & integration tool.
Make.com has full support for Airtable, Amazon AWS S3, Cloudinary, and all the other major CDN services.
You can likely figure out Make.com all on your own, but if you have a budget & you’re looking to hire an expert Airtable consultant (and Make expert) to help you with this, feel free to contact me through my website:
I describe one method of seeing a preview of the actual image in a url field here. It involves using my my app Low Tech PDF with a premium license (a one time-flat fee per base) to preview an image url for the active record.
You can see the image for only one record at a time, and it is in the right sidebar, instead of the grid view. However, it displays the actual image at the URL, and currently works with Airtable, unlike the wonderful dream that Bill described. (There may be some caching issues if you update the url at the CDN, but Airtable’s cache still has the old image, in which you need to clear cache.)
The URL Preview app will not work with remotely hosted images. It only works with a very small set of urls for very specific services.
The Embed App will only display a single webpage and that webpage is not tied to any record info.
This creates an attachment from the URL, right? And it also updates the attachment when the url is updated? This could work, although there may be some issues if people manually update the attachment, manually type in the url field, or the automation fails to run for some reason.
There are also several other techniques that will create attachments from urls.
It says it works with Google Drive… does it not work with images that are publicly accessible via Google Drive?
Oh, that’s right! Forget that idea!
More specifically, the Url Preview app works with
Google Drive folder and file share link URLs
Google Docs , Sheets , and Slides URLs
I haven’t tried publicly sharing an image file from Google drive, and I don’t know if it would work in the Url Preview app. I believe share links are “viewer” links and not direct links to the raw file contents.
In any case, Google Drive is not designed to be a CDN the way Cloudinary or an S3 bucket are. And those are clearly not listed as supported urls.
I just tested this, and as the support article indicated, sharing an image from Google Drive works just fine in Airtable’s URL Preview App. Here’s a link you can use to test on your end:
Thanks for the replies, all.
Well, it’s not really a dream; it’s a reality in many systems, Coda specifically. As such, I tend to think of this as basic content hygiene.
All systems should be able to render content from any authoritative or accessible location. The entire point of HTTP is to effortlessly create loosely-coupled apps and this concept was well understood almost 25 years ago. Airtable was designed without deference to the nature of the hypertext protocol or the vast business and technical requirements that can be addressed using HTTP. This community has documented dozens of cases where the simple embrace of HTTP science would make the product a lot better.
The motivation behind my question was - I have a WordPress site with 11,000 (about 88Mb DB) posts, 9,000 images (about 3Gb) and very little traffic. I’m considering a lighter and cheaper option.
That could be moving off WordPress, moving to Airtable and spitting post content out through API. But that kind of image space requirement isn’t going to work with Airtable.
As a starting point, I’m now exploring simply off-loading my WordPress media library to Cloudinary or Amazon S3. This will reduce the actual site size, making it easier to simply move between host whilst the images would stay on the separate cloud. It may even also provide a pathway to also moving to Airtable or similar for just post hosting…
FYI, Nocodb supports storage of remote files against an Attachment field - App Store - NocoDB But then, that’s roll-your-sleeves-up, open-source territory.
If you really want to shake things up and be well ahead of the future of content hosting, consider moving everything to IPFS (Web3) - this will get you started and this is helpful as well.
This topic was solved and automatically closed 15 days after the last reply. New replies are no longer allowed.