While updating an inherited web project, I’ve been slowly introducing some well-defined libraries to the mix. My current favorite being Vuetify — designed to add some decent style standards to reactive Vue components. This happens to be what I’ve chosen for the overwhelming task of modernizing the Store Locator Plus plugin UX (you’ll see the first hints on the forthcoming Add Locations interface in the next release) as well as for several other “clean slate” projects.
If you are writing web apps and are not familiar with CSS standard libraries or haven’t heard of the “12-point Grid System” you should start learning it. It will save a lot of time building web and mobile apps that are responsive. Libraries like Vuetify and Foundation for Sites with only the CSS components are well-tested with pre-defined rules that not only you will learn and be able to re-use but you’ll likely find many other web developers are already familiar with this configuration.
Digging into Cypress.IO in a sprint to replace my almost-completely-useless stack of Selenium IDE tests for Store Locator Plus, I’ve run into some issues that seem to go beyond my lack of knowledge with the tool.
Yes, it is a great step in the right direction and it can be man-handled to do what I need. For now. But tools should not be forcing you to do things a specific way. That are supposed to make you more efficient, no re-train you or add extra steps.
Cypress.IO has shortcomings when it comes to doing real-world end-to-end testing of web apps. Order of tests is one of them.
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.
I’ve written articles on Jetpack Autoupdate before — you’ll find some of them in the Jetpack blog. For many neglected sites autoupdate of plugins is a good idea. Plugins often have security patches that you should not ignore. Sometimes they have compatibility updates to allow them to work with the latest update to WordPress.
However autoupdate of ANY software, whether on your phone, desktop computer, or mobile device is only as good as the software doing the update. Over the years I have yet to find a single software company that can publish a 100% never-fails update to their software stack. Of all the companies that are pushing software, Apple seems to be the least prone to fatal crashes — the kind that take your business or personal productivity offline for hours or days. They are not infallible by any means and introduce plenty of “oh, that’s a pain in my ass” bugs on a regular basis.
Even season veterans such as Till cannot escape the millions of combinations of site installs that may create corner cases that break software. Something in the latest 1.3.6/1.3.7 updates to his plugin, or possibly changes to WordPress, or changes to the underlying operating systems or PHP have broken the Redis Object Cache plugin.
This will manifest itself as a non-responsive website , usually with a basic 500 (Internal Server Error) reply.
The quick fix is to disable REDIS by adding this line to your wp-config.php file:
define( 'WP_REDIS_DISABLED' , true );
This will force the object-cache.php file that the plugin has you move into the WordPress root directory to not run any of the code within.
Wait for a future Redis Object Cache plugin update before turning it back on.