Vue is running on several projects to create a better admin user experience. Vuetify is layered on top and baked into WordPress themes and plugins.
You will need to add a little custom CSS to stop WordPress from stomping on the UX. You’ll also add a small localize script to seed Vue with relevant data from WordPress. A little REST applet to serve Vue requests and you get a fast good looking responsive app with far less effort than custom code, WordPress skeleton apps, React, or Angular.
Vue + Vuetify is my new go-to tool for plugins and themes. I am happier with my choice knowing that was created and is supported by small independent developers.
As PHP continues its march into the future with improved support for objects, better memory management, and notable performance boosts WordPress seems to be dead-set in sticking to the “must support old technology no matter how bad it is”. As of this writing, on the verge of the much-anticipated WordPress 5.0 release with the almost-modern reactive components interface — the past continues to hamper the technology by insisting on clinging to PHP 5.2 as the baseline version that plugins and themes should support.
PHP 5.2 Is Dead
Not recently dead. Long deceased. PHP 5.2 support officially ended OVER SEVEN YEARS AGO in January of 2011. That is about 3,000 years ago in human-time.
Businesses have been hiring programmers for decades now. Back in the 70s it was something only Fortune 100 companies did. Today everyone from your local cafe to full-fledged software companies do it. Unfortunately few now how to hire a programmer.
Nearly every-single business outside of the tech sector gets screwed when paying an outside agency to write their apps. If you’ve hired a programmer recently it is very likely you are on that list. If you don’t think you’ve been screwed, you are likely just wallowing in a pool of naivety as your coder-for-hire laughs all the way to the bank.
First things first -let’s get setup.
One of the common processes that runs in Store Locator Plus is deleting locations. For sites with a few dozen locations the process runs smoothly. For sites with thousands of locations but deleting one or two at a time, not a big deal. But for sites that are deleting tens-of-thousands of locations at a time the process becomes painfully slow. A mere 2,500 locations can take up to a full minute to be removed on a fairly decent performance server. That’s not the type of performance I like to see from our product.
After digging into the performance of the PHP stack initial indicators point to the custom post types as the primary culprit. It turns out that deleting a single custom post type in the WP_Posts table runs through a dozen gyrations to delete the post. Multiple filters are called, associated taxonomies are delete, taxonomy meta is deleted. It is a TON of extra overhead. But even with removing records from a half-dozen tables the data queries seem out-of-control.
Removing just 9 locations generates over 190 data queries. If there is one thing that has not changed in decades of writing software it is that data queries are costly. They may run on solid-state drives with advanced memory caching but doing 190 data queries is still far slower than nearly any other part of the application.