Yes, it has been a while. Some would say too long since our last updates to Store Locator Plus® rolled out over a year ago. We hoped to bring much needed changes online this past fall, but a combination of technical and life challenges kept that from happening. Now that we’ve moved past those issues, we are getting close to launching notable updates in 2025.
Let’s start with what we have on the agenda for this month, February 2025 — which will begin with a major update to the SaaS platform. This update should happen in the next couple of weeks and includes changes that lay the foundation for more frequent updates going forward.
Cloud Infrastructure Updates
We are in final testing of a new SaaS cloud architecture which will pave the way for more frequent updates going forward. While most of the updates are infrastructure related and thus mostly invisible to users, our new container-based cloud service allows for rapid updates in a continuous integration and deployment environment. The new infrastructure is based on elastic compute services and allows for zero or near-zero downtime every time we upgrade Store Locator Plus®. These updates are built on an automated build, test, and deploy system using standard continuous integration techniques (CI/CD). That means fewer chances for human error and less “heavy lifting” as much of the process is automated from build to test to deployment.
We can now provide patches and updates on a regular basis without a 5-10 minute downtime window. The patches can be smaller, allowing us to introduce quick fixes or minor feature changes without having to schedule maintenance windows. Longer maintenance windows on the current SaaS platform forces us to package many small updates into a larger update that warrants downtime. Going forward, system updates will simply switch over to the new application when it is ready. Users will be served up the new version of Store Locator Plus® at their next login.
A New Menu Experience
One of the visible updates that users will notice is a revised menu on our Software as a Service (SaaS) platform. All the features are there, however we have decided to start moving away from the confines of the WordPress user experience. Doing so allows us to develop better user interfaces starting with the administrative side of Store Locator Plus®. This leads the way to publishing modern user experiences based on the React JavaScript framework. You’ll see the first of those designs in the new Style gallery.
You can read about the menu items that have changed and what you will find under each menu entry at the Menu Changes For The February 2025 Update article on our documentation site.
Revised Styles Interface
Part of the new locator updates includes a replacement for the “Locator Styles” setting that was found under the Store Locator Plus® | Settings | View menu. The idea behind this setting is to preload your locator setup with a combination of CSS, HTML, and Store Locator Plus® settings to create a new style of map or directory displays.
The February 2025 locator update has moved this to a top-level menu item as we feel it is one of the first stops a new user should make when setting up their site. Starting from a pre-defined template that is close to your vision for the locator app makes it easier and faster to get a final result you are happy with. Many web designers start with one of our pre-defined locator styles and then tweak some CSS and Store Locator Plus® settings to dial in the look-and-feel to be exactly what they envision.
The revised interface is one of our first administrative components to use the React framework. It provides a similar “card stack” of styles running down the left side of the page. On the right is a new “Map Preview” panel that works exactly like the “Generate Embed” preview page. The preview is updated as soon as a newly-selected style is activated. This allows you to see what the new interface will look like without having to click multiple pages to see the changes.
This is just the start of our revised Style system. We are working on updating many of the styles that are on our servers to clean up outdated interfaces, add new color schemes, and provide more pre-defined settings.
As we get this dialed in we will be working toward allowing web designers to publish their own Store Locator Plus® designs and have them listed in the styles directory. This will make it easier for web design agencies to share their carefully crafted configurations between multiple accounts on Store Locator Plus®.
We are also working on an option to save various settings to a private repository of styles. This will allow you to easily rotate through each group of settings you’ve created allowing designers to try out new ideas and revert to a prior setup with the click of a button.
This new style system will also pave the way to updating our map interface from a jQuery-based JavaScript implementation to one that uses a more modern UX-centric frameworks like React.
Updated Payment Processing
While the latest locator updates to the payment processing system may not be readily noticeable to our existing users, new users will find they can not only sign up directly from our new on-platform sign up page but can now use Apple Pay as a payment method.
This update will allow us to update the subscription management system under My Profile to a modern interface that will make it easier to switch between various subscription plans, change payment details, or switch to a new payment provider. Once we have the profile page integrated with the new Stripe features we will be able to provide more payment options including some of the more readily used options for our non-US based customers. Our goal is to have these updates in place later this year.
New Core Technologies
Believe it or not, Store Locator Plus® was initially developed over 15 years ago starting as a WordPress plugin. The SaaS offering was launched nearly a decade ago in early 2017. There have been over 10,000 commits by over two dozen coders.
Along the way there have been multiple updates to the core technologies, primarily PHP, JavaScript and MySQL. As part of our cloud infrastructure locator updates we decided it was time to update those core technologies again.
PHP will now be running the latest 8.X stable release. This new version of PHP uses less memory and operates faster than the previous 7.X generation. That means faster load times for many operations. It also means we were able to leverage some newer PHP constructs and simplify the code, which led to several notable bug fixes along the way where errant non-reproducible bugs were finally put to rest.
The database engine continues to run in a fault-tolerant multi-zone cloud configuration but has been updated from the long outdated MySQL 5.7 release to a newer Aurora MySQL compatible 8.X release of the database. That means it is now running on newer faster cloud services reducing query latency which speeds up location processing.
More To Come
As we begin 2025, our hope is that our updated platform allows for more frequent updates to the SStore Locator Plus® SaaS platform. 2025 starts with a push to modernize both the administrative interface as well as the map and directory user experience for your site visitors.
If all goes to plan we have a long list of new features that go beyond the fancy new look-and-feel stuff. We will continue to work toward making our map and directory platform a better tool for web development agencies. We hope to make it easier for those agencies to replicate and manage their work between multiple client sites.
As we spin up our 2025 locator updates we will be looking for your input and feedback on what features to investigate and implement as we move forward. You can always reach out to us via the support email or via the Contact Us form from your Store Locator Plus® dashboard login.
What About the WordPress Plugin?
As you may have noticed, we talk a lot about the SaaS platform here. Going into 2025 we have decided to focus our efforts on the SaaS platform. Much of this has to do with the struggle to maintain healthy communication with the WordPress Plugin Directory team. This has made it difficult to keep our WordPress plugins and the related automatic updates online in the official WordPress directory. While we initially had a good relationship with the members of the plugin team at WordPress, changes over the past few years have led to what we feel has been a lack of guidance and understanding on their behalf.
Our plugin was de-listed from the plugin directory several times over the past two years. Despite our ongoing efforts to address concerns, we found our feedback and insight was often ignored. Just over a year ago, our plugin was delisted for not conforming to their new “plugin check” automated code review app. Their automated app could not properly process the code logic in our complex, 500+ file / 100,000+ line plugin. As such it would incorrectly flag multiple code constructs as “not properly sanitized inputs” or “escaped outputs”. The flagged code never rendered interfaces that users could access directly or programatically and did not warrant the typical escape or sanitization calls. Despite our attempts to walk them through the logic they simply “did not have the time nor desire” to be educated on our design. As such we spent hundreds of hours rewriting code and adding extensive unnecessary overhead to literally publish a product that functioned 100% exactly the same as the prior release that was listed months prior. We dealt with it and chalked it up to the “tax” of being listed in a “free” directory.
Last fall our plugin was again delisted. This time for an issue that a third party designated as a security risk. When they didn’t like our reasons for our architecture decisions on why locations marked private needed to be accessible from the REST API, they reported it as a security issue to a third party WordPress plugin review agency. This was immediately picked up by the WordPress Plugin Directory team and our plugin was de-listed again. This time for an architecture decision that has very real ramifications for how the administrative interfaces work with the product. Again the plugin team refused to consider our explanation of why things worked the way they did. They insisted we change our architecture and get the plugin to pass a flawed security test created by a third party. Despite our explanation that the private locations could only be accessed from an REST API request made from a logged in user with “manage locations” privileges, they refused to allow us to remain listed in the directory. This time we refused to change our code. Doing so would require a significant rewrite of core location management technology that would have far reaching impacts on the functionality of our application for both SaaS and plugin users.
The final reason we opted to focus on SaaS came about this fall with the very public drama regarding WP Engine and their Advanced Custom Fields plugin. If you are not aware of that story look it up online. What concerned us about this story was the fact that Automattic then decide to take WP Engine’s Advanced Custom Fields plugin and commandeer it as their own. They changed a some code and changed the name to Secure Custom Fields and published a near-identical copy. In our view they essentially took years of hard work from a plugin developer and made it their own to “teach them a lesson”. While it may have been perfectly legal given the open source nature of all things WordPress (including plugins a developer publishes in the directory), in our opinion that was bad form. It was a punishment that Automattic enforced through the WordPress community’s plugin development team and platform. Sure, they claim it was “for security issues”, but we know the real reasons regardless of how it was justified.
Considering the way WordPress has not only managed our interactions but how they have handled the situation regarding the Advanced Custom Fields plugin, we feel we can no longer trust the WordPress Plugin Directory and its supporting cast to simply “do the right thing”. Over the past two years we wasted hundreds of hours re-coding our plugins, not to make them better, faster or more secure but to simply remain listed in the directory. Hours that could have gone toward new features or better performance. Instead our plugins got slower as we were forced to jump through bureaucratic hoops versus engaging in meaningful dialogue.
As such we have decided that we would focus on writing code to deploy on our SaaS platform. Doing so ensures we can simplify our code as we no longer are forced to support outdated legacy WordPress constructs at every turn. We can employ features to speed up our customer experience. In short we can build a better, faster, stronger product that works better across ALL platforms not just WordPress.
That does not mean we won’t ever update the WordPress plugins, it just means that we will first deploy on the SaaS Platform and when the underlying Store Locator Plus® WordPress plugins are stable, we will update those plugins on our WordPress store. The updates will be less frequent, but they will come eventually. Don’t be surprised if those updates start to look more like our modern SaaS interfaces versus conforming to the outdated WordPress administrative interfaces we’ve all dealt with for the past couple of decades.
