Decided to upgrade my long-term VVV setup that I use for daily client consulting work in preparation for a new gig as head of R&D and CTO for a super cool tech startup. As usual I should have left things alone as it was working fine; I only wanted to play with the newer VVV toys. You’d think I’d learn by now.
What I ended up doing was cloning a working baseline VVV install I had created a few weeks ago for the WordPress Plugin Development class I’ve been teaching at The Blockyard this year as part of the CodeBlock initiative.
Turns out this will be super useful for those nights when we have a dozen students all trying to initialize a new VVV install and we don’t have the bandwidth for 12 simultaneous 500MB box image downloads.
Here are the notes for a MacOS install. Windows will be slightly different but the same concepts apply.Read More
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.
WordPress REST performance sucks. There, I said it. Not because I dislike WordPress — in fact I think it is the best open source web application we have seen thus far. It is a great piece of technology. It even has the potential to be a great web application framework — in fact I use it for the Store Locator Plus managed service, MySLP.
However, unless you are in 100% complete control of every component in the system you are going to very likely end up with an underperforming over-burdened web service if you build your tech on typical WordPress components. Even the highly customized MySLP service is 5-10x slower than it would be if it was build on a completely customized application stack outside of WordPress.
WordPress is NOT built around performance. WordPress is built on two core tenets – ALWAYS support legacy users at all costs. Be extensible.
Testing Store Locator Plus with lots of locations is a chore. Thankfully Cypress.IO data list processing makes this a lot easier.
It turns out that the old-school Selenium IDE scripts that we’ve been using to test Store Locator Plus for years will no longer work. We already knew Firefox versions beyond 54 broke things — but we kept an old install on hand so while we port 500+ test scripts to a new system. What finally broke the old-school Firefox bandaid was moving Store Locator Plus towards a reactive application using Vue.
An unusually short article, for me, on basic WordPress plugin loader tricks.
Name the “loader” php file the same as the plugin directory.
Text Domain must match the directory name.
Avoid leading * on header lines = less bytes to process by the header processor in WordPress.
Ensure it runs from within WordPress
Use function_exists( ‘add_action’ ) instead of defined( ‘ABSPATH’). It is more likely to be specific to WordPress. It is also a better test as the loader calls the add_action function and will break if it is AWOL.
Not doing heartbeat processing
Short circuit to avoid loading the main plugin code if your plugin has zero influence on heartbeat operations. WordPress heartbeats fire up AJAX requests every minute or two when a user is on the site.
Load on plugins_loaded
The plugins_loaded action loads early enough to be able to latch onto actions that have to happen in init or admin_menu. If your plugin requires others to be loaded this ensures that has happened, just make sure you set the action priority higher than the plugin you rely.