

If there are more records available, the response will have a top level key of offset. AirTable (like WordPress) sends a max of 100 records per request. The first step in accomplishing this new workflow is making sure all the data is retrieved from AirTable. Any IDs that only exist in the AirTable dataset will have their rows removed from AirTable (maybe we decided to delete a post that didn't make sense anymore). Any IDs that exist only in the WordPress dataset will be added to AirTable as new rows. Any IDs that exist in both sets will be updated in AirTable (because maybe we changed a blog post's name to improve the SEO). Instead, I want to compare the WordPress post IDs from two whole sets of data. Unfortunately, WordPress authors can change their publish date, meaning we might end up with holes in our data. We could just request the WordPress API to only send us the posts published after a certain date.

So we would have to request all of the posts anyway. To fetch the next page of records, include offset in the next requests parameters. Unfortunately, we wouldn't be able to tailor our request for conditional IDs (meaning, we can't ask the WordPress API for only posts with IDs great than 772). If there are more records, the response will contain an offset. We could just check and see what the highest ID was in AirTable and retrieve any WordPress posts with an ID greater than that ID. Instead of accepting flags for the sync method, the gem should get all the data from WordPress, all the data from AirTable and compare those two sets of data. After some deliberation, I decided to scrap that idea. It doesn't take into account the rows of data already in the table, meaning we could have duplicate content.Īt first, I considered having the gem's sync() method accept flags, so that the user could specify how the data was synced: just adding new rows or deleting all the table data first before adding all the WordPress data wholesale. Last week, I talked about how the gem can only add all the blog post data wholesale to AirTable. It uses the WordPress API to collect a blog's title, date published, ID and URL, formats the data, and then uses the AirTable API to create new rows in a specified table. If you've been following along you know I've been working on a Ruby CLI gem that will automate adding WordPress blog data to AirTable.
