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. read more »
As the release of WordPress 5.0 comes closer, I was curious about performance of sites running Gutenberg (the proposed replacement for the WordPress post editor). To answer the question, I wrote a lightweight benchmarking mu-plugin, that I’ll write more about in a future post, once I’ve given it a little more polish.
As a test, I generated two identical pages, one with the Gutenberg editor, and the other with the Gutenberg plugin disabled, and ran my benchmarking script on each.
read more »
read more »
I get a lot of client requests for “Store Locators” or “Location Finders”. There are some plugins like MapPress and WP Store Locator that work well for simple Location Searches, but as soon as the client has requests for specific functionality or designs, these pre-made options start to fall short, and you end up spending more time fighting their code than writing your own. read more »
For the most part, the file-structure of WordPress themes is pretty logical, however, there are aspects which keep bothering me about the Template Hierarchy:
- home.php – I understand the historic reason why the blog’s main archive is named
home.php, but every time I make a new theme, I wonder why such an illogical naming convention still persists. It’s confusing to new users, and simply serves to continue the flawed narrative that the blog is the core of the WordPress experience.
- front-page.php overrides page templates – This is particularly frustrating when a parent theme includes a front-page.php file, as there is no way to offer template file choices in the child theme, without modifying the parent.
- Custom URL routing is complicated – Sometimes I need a specific url to run my own code, outside of a traditional template file. Often, I’m stuck defining custom rewrite rules and template redirects, or jamming my code into shortcodes and custom templates.
Being a developer. I decided to fix these perceived flaws.
read more »