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.
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.
When using a private update service for premium WordPress plugins, some version tests get left behind leaving users with a half-updated plugin stack. When operating a freemium model, like Store Locator Plus, where the free base plugin may be updated and impact how the premium add ons work having all update notifications arrive at once is critical. There are times when version 3 of the main plugin will ONLY work with version 2 of a premium add on. Within Store Locator Plus there are “pre-flight” checks built into both the base plugin and the premium add ons to ensure the entire WordPress site stays running if there is a conflict.
WordPress LOVES backwards compatibility as can be witnessed by the minimum-allowed WordPress PHP version remaining at 5.2.4 a decade after its end-of-life date. It may be one of the reasons they have continued to garner market share. Don’t require people to do anything to improve their site and they’ll wallow in complacency. It makes sense. Inertia is a big thing to overcome. If you are a business focused on writing content, selling widgets, or doing just about anything else other than managing websites, upgrading software is way at the bottom of the priority list.
This backwards compatibility is one of the reasons why WordPress continues to RECOMMEND PHP 7 for performance and security reasons but allows the minimum WordPress PHP version to remain 5.2.4 without breaking the core application. It is the reason why so many plugins, including Store Locator Plus, continue to do some convoluted things to reach that PHP 5.2 audience and keep their potential market as big as possible.