Help

Re: Airtable CMS - article body formatting?

3538 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Robert_Andrews
6 - Interface Innovator
6 - Interface Innovator

I’m contemplating moving from WordPress to Airtable, where I would spit out posts via the API (not with Webflow on the end of it). Of the many things I’m trying to wrap my head around…

How would article bodies function, from a formatting perspective?

Unlike highly field-driven CMS work, articles are not discretely formatted. That is, article bodies contain a variety of text formatting originally created at the user discretion, inside WordPress’ TinyMCE editor - ie. crossheads of different h-tag sizes, links, images etc. WordPress stores the post body as HTML in MySQL. These elements should be retained on the Airtable side.

What are my options… ?

  • Long Text field that just contains a load of HTML tags and becomes burdensome to actually write/edit into?
  • I see the Long Text field accepts formatting, with some reference to Markdown. How is this actually stored? As Markdown/HTML/something else? If Markdown, maybe there’s a risk I will lose any non-MD-trasnslatable HTML elements, ie. iframes?
7 Replies 7
JudoHacker
6 - Interface Innovator
6 - Interface Innovator

Hi Robert,

I’m currently working on an imported for Airtable that will take Google Docs and convert them into clean HTML that is imported into an Airtable Long test field.

The goal is to serve all my customers who are blogging with Airtable as their backend for their Webflow sites. However, it will work for you even if you don’t use Webflow.

If you’re interested, signup for PowerImporter and I’ll email you when it’s ready for early access (in a week or two).

I would likely already have the HTML in a Long Text field, by dint of doing the import from WordPress/MySQL. (WordPress stores posts in MySQL as plain-text HTML).

Are you still using WordPress, but just moving the content to Airtable?

This is more or less what I did (before I broke my website trying to go in the other direction). This was also the basis for my “post to WordPress” block that I wrote for the blocks contest a couple of years ago. (I never cleaned it up enough to publish it, but it worked.)

I do not recommend using Airtable’s rich text field. It has a very limited form of markdown. Instead I used a plain text field with markdown and a script to convert the markdown to html. (And I also used a bunch of formula fields and some linked records/roll ups.)

The great thing about regular markdown is that markdown includes html. If something needs to be html, include the html. It will be preserved in the conversion from markdown to html.

This also makes migrating from html easier. You don’t have to do it all upfront, you can just do it as you go.

Still on WordPress and thinking through various options. I thought I wanted to just move to using Airtable/Nocodb as a headless CMS DB, and spit out content to pages via API…

But, this weekend, I’m mulling two challenges:

  1. Body-field formatting
  2. Image storage (likely too big for a cost-effective Airtable - 11,000 posts, with images).

So you’d go with a Long Text (is that Rich Text, or just plain?)?
“Script to convert Markdown to HTML” - do you mean, on output to the page, as opposed to inside Airtable? So, if I’m using PHP to output my pages, there’s surely a PHP Markdown parser which would render Markdown content as HTML. That what you’re thinking?

Great point. So, I’d pull over the WordPress post content, it’s HTML… I could author new posts inside an Airtable record, and a Markdown renderer on the front end would display either type as HTML?

TBH, my head is also having thoughts about whether I can/should keep everything as Markdown anyway, for posterity - something for the grandkids! Maybe I’d use a HTML-to-Markdown converter.

Tell me more. It am also considering the “what if?” of going back to WordPress. If I somehow ended up with a lighter site, shorn of inefficiency, maybe I would move it back at some point.

I guess I need to settle on what the main objective is.

I may yet start by offloading WordPress media to S3/Cloudinary - a) just to get it off-site, b) in case that would be a useful start to hosting the post data in Airtable/Nocodb.

If you’re still using WordPress, you can probably still use WordPress theme/css styling.

Sounds like you are using Cloudinary or S3 for images, so you would need to figure out how to include the images. Markdown images don’t include size information, which leaves with you html img tags, which are a pain to hand write in bulk. In one of my websites, I only had images in very specific places and used formula fields to create the image tags.

I with with a long text field field without rich text formatting. Just plain text.

I ran a script/custom app inside Airtable to convert the markdown to html and store the html in a different long text field. Then I used a script/custom app to push the content to WordPress using WordPress’s API.

This is totally unrelated to the process. Since I am no longer taking on new clients and doing appointments, I needed to revamp my website. I was doing this late at night and accidentally messed up a bunch of stuff on the home page in WordPress itself and got fed up and left it a mess. I need to fix it, but fixing it is no fun.

This could be a good idea. I hate the WordPress media library.

Joe_Hewes
7 - App Architect
7 - App Architect

Don’t forget the Airpress plugin for Wordpress is still a thing! Not much in the way of documentation bar a few YouTube videos, but it can do some of the heavy lifting for you. We use it on a catalogue site and it performs well for us.

Yes! I use AirPress as well, but typically for more dynamic info than posts.
Sometimes I use virtual fields, but other times I find it easier to build the entire html page in Airtable formula fields and do virtual posts.