Locator Updates for Spring 2025

The Store Locator Plus® SaaS and WordPress plugins have been updated to lay the foundation for rapid updates over the next few months. Before we could begin our “quick sprint” series of updates to patch minor bugs and release smaller feature updates at a faster pace we needed to fix the “foundation” of Store Locator Plus®.

Some of the updates in this release include the stability of retaining locator settings, a new settings history feature for our SaaS clients, the removal of the “quick save” feature, and addressing a half dozen PHP warnings or errors for our WordPress plugin users.

Read more: Locator Updates for Spring 2025

Locator Settings Stability

The updates to the WordPress core engine since the 6.X release changed the order in which various pieces of the Store Locator Plus® code was running. Some of the changes were related to how WordPress language management worked via their load text domain calls. This functionality is related to the multilingual, or polyglot, capabilities in WordPress — and thus also the Store Locator Plus® system. Since WordPress 6, multiple warnings were being generated as a previously undocumented “feature” of WordPress would force the text translation code to be called earlier than instructed. This automatically-triggered, and unexpected, loading of the text translation module meant that Store Locator Plus® code was bringing various settings modules “online” earlier than anticipated.

This had the effect of prematurely loading various settings modules and triggered a series of “what is this setting? — ok, let’s set it to a default value” events in our code. That led to a string of complex inter-related events that appeared to our users as “hey, whenever the main Store Locator Plus® plugin is updated to a new major version some of our settings get reset”. This issue has been resolved.

But My Settings Didn’t Always Reset…

That is what made tracking down this issue so difficult. The problem was not easy to reproduce. We spent much of the past two months tracking down specific settings that were being reset to their default value, fixing bugs or timing issues with those settings only to find out other settings would then be reset.

It turns out that a very specific string of events has to occur, and it does not impact all users every time. The main trigger is the core of the code, the Store Locator Plus® base plugin had to be upgraded to a new version. In addition users of the SaaS had to be a Professional or Enterprise level user — or WordPress plugin users had to have Power, Experience, or Premier installed and active. In addition, at least one setting from those advanced features had to be changed from their default at some point in the past.

Settings that contained text values, such as labels, were especially vulnerable to being reset.

Settings Issue Resolved

After extensive testing during the past couple of weeks of the 2505.08 version of our SaaS platform as well as the standalone WordPress plugins, we believe this issue has been resolved. The resolution involved splitting apart several functions that setup the Store Locator Plus® environment and having those new functions connect to different points in the WordPress platform startup sequence.

These updates have stabilized the settings issues and should prevent these seemingly random resets from happening for both our plugin and our SaaS users during future platform updates.

Settings History

A new feature we are developing for the SaaS platform has been started as part of our settings reset research and investigation. A new menu entry “Settings History” is now available to all users. With the 2505.08 release on the SaaS platform, this is a simple read-only report of what settings have been changed and when. This is intended to provide a way to see what settings may have been changed, whether automatically triggered or specifically set by the administrator for your account. If your locator interface is not looking or behaving as you expect, this should provide a way to see what was changed so you can put it back to the prior settings.

Setting history noting a change we made from having the map centered in United States to Charleston SC

In the future this will evolve to provide an interface option to restore specific settings or even rewind your settings back to a specific point in time. This interface will also provide the foundation to allow for your account to store and save multiple setting configurations that can be deployed on your site with different embed codes. That makes it possible to have one set of locations that can drive several very different presentations of the location map and listings for directories. For example, you can have a settings group named “The Southeast” and another named “New England” each with a corresponding “center map at” location as well as a different default radius for each. Running a global company and want to use km for locations in Europe to miles for locations in the US? In the future you’ll be able to generate a different embed code for each using the “render map with the Europe settings” version for one and the “render with US settings” for another.

“Quick Save” Removed

The “quick save” settings feature has been removed. In the past some settings that had a dark red label would “quick save”, a feature popular six-plus years ago that would automatically implement a setting as soon as you changed it on the user interface — no need to press the save button on the settings page. This feature is now gone as it was not implemented across all settings, thus making for a confusing “click save for these settings, but not these” user experience. Now nothing is saved or updated after you change a setting unless you intentionally click the Save button on the settings page.

Other PHP Specific Updates

The following updates primarily impact our WordPress plugin users that are running different versions of PHP, MySQL and other baseline technologies for their installations. Our SaaS platform is built on stable standardized versions of PHP and MySQL in addition to having the PHP configuration files on the platform tailored to meet the latest best practices for that platform. Non-standard PHP configurations, outdated versions of PHP, or bleeding edge releases of PHP can cause a number of issues that manifest in error messages appearing on a website when installing Store Locator Plus®. Some of those messages can cause a fatal error, shutting down an entire site due to how PHP and WordPress handle the severity of different errors.

Errors that appear for PHP 8.X releases that were brought to our attention have been resolved including:

  • Call to update_wp_option() on null
  • _load_textdomain_just_in_time() warnings
  • DSRA null reference error

Post Image by Lance Cleveland from Pixabay

New Locator Updates Coming Soon

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.

The updated SaaS menus.

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.

February 2025 Locator Update : New Styles selector and preview
February 2025 Locator Updates: some new styles and style descriptions

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.

The Store Locator Plus® code repository stats.

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.

featured image from pixabay.

Google Maps for JavaScript Update

Store Locator Plus® was recently updated to accommodate the latest Google Maps for JavaScript update which now requires a callback parameter. Third party hosted scripts such as the Google Maps for JavaScript library, a foundational component of Store Locator Plus®, can change how they operate at any time and without warning to the developers that employ these scripts. Thankfully the recent Google Maps change that makes a new callback parameter required only generates a warning. If this follows in the footsteps of prior Google Maps updates, it will one day suddenly be required and many sites that do not update the script deployment will fail.

For our clients using the WordPress plugins, this means you will need to update the Store Locator Plus® plugin before Google “flips the switch”. For our SaaS users, you do not have to do anything — we’ve already updated the library for you.