The first version of Kanban for WordPress was built using custom post types. I’d always been taught that WordPress developers should work hard to conform to the WordPress database schemas and “best practices”. I wrote a lot of extra code to accommodate attributes, but it always felt like forcing a square peg into a round hole.

I’ve been developing web apps for more than 10 years. This is one of those situations where I should’ve listened to my gut. The code works, but it’s pretty hacky.

Then I started listening to the Apply Filters podcast with Brad Touesnard and Pippin Williamson. I admire Pipin’s work a lot. The man is a force when it comes to development. And in an episode about using custom tables, he actually says one of his biggest regrets with his Easy Digital Download plugin (which is massive, and boasts more than 40,000 installs) is not using custom tables from the beginning.

There are two big advantages to custom tables.

The first is efficiency. The WordPress database model works for posts and metadata, but isn’t great for tasks, projects, and everything the kanban board needs. Custom tables for custom data are faster and cleaner. Also the code for the plugin becomes a lot faster and cleaner. It’s easier to maintain, upgrade, and even uninstall.

The other reason is privacy and security. When talking about the plugin, I was emphasizing the transparency of the board – how it integrates into a site you might be working on, but the data will never be seen by the public. And then I realized that’s not true. If the kanban board’s data is sitting in the same posts table as everything else, it’s easily accessible by plugins, and the WordPress core. It’s too easy to access that data, and it’s too messy to remove if you don’t want to keep using the board.

So we’ve re-written Kanban for WordPress from the ground up using custom tables. We’re already seeing a huge improvement in performance, a smaller codebase, and now we’re truly keeping our promise that your project data is private and secure.