This block is part of a larger project of using Airtable to tame a sprawling amount of content published in a blog over the course of several years. The first part of the project involved extracting the content from the blog and into Airtable, making it easier to see trends and identify gaps in the content. Then Airtable's formula and rollup fields made re-assembling the data straightforward and automatic.

However, returning the re-assembled content back to an actual website was more challenging. Zapier integrations could only create new posts, not update and delete posts. I also didn't want to wait several minutes for a third party integration before I could see the results. Other workflows were too cumbersome, running the risk of the Airtable content and the website content becoming out of sync with each other.

This block reduces that final gap of publishing content from Airtable to a couple of button clicks. I can now preview my post as I draft changes, then view those changes on my website in a matter of seconds.

What it does

The block will publish, update, or delete a post on a WordPress website based on information in an Airtable record. The block can publish the following data to a post:

  • title
  • content
  • slug
  • date
  • sticky
  • category numbers
  • tag numbers

It also stores the WordPress post id back to the Airtable record.

The block can also store a username and password to be shared across all users, streamlining logging in.

The WordPress website must be configured for Json Web Token authorization.

How I built it

I built this block starting from the "Hello World" example.

From there, I spent a lot of time reading and googling:

  • Custom Blocks API reference
  • WordPress API reference
  • many web pages discussing authentication
  • many web pages discussing CORS errors
  • documentation from my web host
  • various web pages about how to use the WordPress API

Challenges I ran into

Authenticating into the WordPress API was extremely challenging. I needed to find the right combination of WordPress plugin, server settings, and code to get all the pieces talking to each other.

Even after I was able to get my block to communicate with WordPress, I had to figure out where to store credentials securely between sessions, and how much to store (just the user name, or both username and password). I also had to look at tradeoffs between storing the credentials for all users of the block in globalConfig or just the current user in local store. I ultimately decided that local storage wasn't secure enough.

An additional security issue for authentication was figuring out how to hide the password as it was typed, as the built-in UI components did not provide immediate support password entry.

I actually spent more time working on the login code than the code that interacts with WordPress API endpoints.

I also had to find a way to communicate with the Airtable user to wait while authentication was processing and what to do if authentication or authorization failed.

Accomplishments that I'm proud of

I'm proud that I found a login workflow that is flexible yet secure.

  • Once an Airtable user is authenticated into WordPress, all future requests during that session use the same Json Web Token, limiting the number of times the actual username and password sent over the internet.

  • An Airtable user can choose to save the WordPress username and password for other users of the base, without ever revealing the password to them. Or the Airtable user can choose to save just the WordPress username by leaving the password blank when clicking the save button.

  • An Airtable user can easily see which WordPress user account is being used, and change it it quickly.

  • An Airtable user can choose to authenticate into WordPress as the saved user, or enter a different one-time username and password without affecting the credentials saved for all users.

  • The WordPress plugin that I use is completely free to use, unlike other plugins that have ongoing subscription fees.

What I learned

I learned that a single API can have many different methods for authentication, and that each method has its own individual quirks.

There are at least three methods of authenticating into the WordPress API, and none of them work with a basic WordPress install. All of them require at least installing a WordPress plugin.

What's next for Post to WordPress

I'd like to do more user testing to see how I can improve the user experience.

Share this project: