Over the last few years, I’ve run into a few situations where the standard database structure of WordPress causes some real frustration. There are two specific examples that come to mind immediately.
In one case, a client wanted to be able to make their edits to posts and pages on a staging site, but also had a massive amount of data that needed to be uploaded nightly from an ORM system. They needed all the trappings of the standard WordPress post structure, but for efficiency, the imported posts needed to be deleted and recreated nightly, in a slow import that ran on the staging site. We ended up building them a custom data structure, but that meant re-implementing many of the features that WordPress provides automatically.
In the other, another client also needed to import a massive amount of data, but nightly modifications were able to be incremental. We chose to store their data in a custom post type, since it could be handled incrementally, but after the fact, we ran into performance issues, caused by the size of their data (over 20,000 posts, with 100+ metafields each), and discovered flaws in the structure that required us to perform several full reimports to solve. We saved time by being able to use the functions that WordPress provides, but lost time dealing with re-importing data and syncing up post ids with metafields.
The biggest frustration in these examples was the ID system that WordPress uses, which relies on consecutive IDs as a primary key for the Posts table, and matches these IDs to terms and metafields. it makes extricating a specific post type’s data from one database and moving it to another very complicated and slow, since all the various post types’ IDs are interleaved.
I thought it would be an interesting project to try to manipulate WordPress’s database prefix to isolate a specific post type (along with its post-meta and taxonomy terms) to a dedicated set of database tables. It seemed like a fun way to mess with some of the rarely seen parts of WordPress, and to test the limits of how far the platform can be abused.
So, I spent the last couple days digging through the bowels of the WPDB class and the finer points of the wp-admin interface to create a functioning proof of concept.
I thought I was just satisfying my own morbid curiosity, but it turns out there are at least two tickets on WordPress.org about this specific change, and over the years they have had a fair number of supporters. Maybe this will be useful to someone else… or maybe this was just a fun exercise in digging into the deepest parts of WordPress.