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.
Selenium IDE was a great way to handle automated web app testing like the Store Locator Plus plugins for WordPress. Selenium IDE is a simple script recorder and playback too that runs on Firefox. Or, I should say, it used to run on Firefox. That broke in 2017 when Firefox 52 came out.
After a lot of research I finally found a viable alternative to Selenium IDE that will work with modern browsers. It is also free, locally installed, and open source. All winning attributes. Paying for services is not much of an issue so the free part is not a requirement just a “that’s nice” feature.
Web app testing services
I tried several paid alternatives including Browserstack — a paid monthly service that runs virtual desktops and mobile device simulations hosting various browsers. Having to connect to a remote server via proxies or tunnels is a pain. It also means no testing when offline or when the network is unreliable. Having multiple browsers is great but 90% of the testing that needs to happen is base functionality which is the same across browsers. Modern browser are also very good at testing mobile with browser like Safari going beyond simple screen sizing in their mimic of IOS, for example.
Other alternatives included several locally installed proprietary test frameworks. Nearly every one of them ranges from mediocre to downright horrid. This is clearly an industry stuck in the 1990s mindset of application development — from the start where you have to fill out a form with all your contact info to be “allowed” to demo the product (and be later harassed by sales people) to the 1980s desktop-centric interfaces. Many did not work on MacOS. Those that worked were heavy, bloated, and had a steep learning curve. Does nobody integrate with my phpStorm, my web app IDE?
It just so happens that the best local testing suite today happens to be free.
The winner? Selenium Webdriver with a few libraries like WebDriverIO + Mocha + Chai to make things easy.