MySLP_REST_API – Store Locator Plus® Internal Docs

AI Summary

Here’s what “map view” (a.k.a. Map Views / mapview_count) covers on internal.storelocatorplus.com, plus where it shows up in the SaaS code paths you’re working with.

What “Map Views” means in MySLP

Map Views = $myslp->User->mapview_count, stored as user meta under the key mapview_count and exposed via the \MySLP_User magic getter/setter.
It’s treated as a subscription/billing usage counter (separate from geocoding usage and referer tracking).

How map views are counted (increment)

The docs state map views are incremented whenever \MySLP_REST_API::get_map_options() is called — “theoretically/assumed to be whenever the map is rendered.”
- Practically: anything that triggers the “map options” REST call is part of the map-view counting surface area (including unexpected extra calls).
- \MySLP_REST_API::get_map_options() is only called via the REST API endpoint:
  myslp/v2/locations-map
  - This REST endpoint lives in the rest_path JavaScript encoded variable.
    This fires from:
    - SLP style/LocatorPreview.js script
    - MySLP front-end/location.js
      - Where this is called via jQuery.ajax GET with properties…
        
        url: … + rest_path (myslp/v2/locations-map)
        
        data.action: get_myslp_data
        
        data._jsonp: ‘initMySLP’

When map views reset

Map views reset to 0 via \myslp_extend_plan() (in the myslp-dashboard-helpers module), and internal docs list these callers:

\MySLP_Dashboard_Controller::check_subscription() (when a subscription was expired and is renewed automatically)
\MySLP_Recurring_Payments::initialize() PayPal-only path → get_paypal_checkout_details() → myslp_extend_plan()
Profile update hooks (personal_options_update / edit_user_profile_update) via \MySLP_Customer_Maintenance::update_myslp_profile_management()

Where “map views” appear in user-facing subscription messaging

In plan-change logging/messaging: when a subscription changes, the message explicitly calls out map view limits and overage billing (“Each map view over this limit is billed at $X per N views.”). This is in the SaaS logging code you shared (log_subscription_changed()), and it references MySLP_User::VIEW_OVERAGE_PRICE and MySLP_User::VIEW_OVERAGE_BLOCKSIZE.
In renewal/extension logging: the History Logger includes “Prior month map views: %d” when extending a plan (if mapview_count is present). (That’s in the plugin code shown in your editor.)

Related “don’t confuse these with map views” items

Referer logging is not “map views.” Internal docs tie referer tracking to geocoding validation (slp_rest_geocode_invalid_referer) and note it’s called during geocoding requests, not every map render.
- So: map views ≈ map options endpoint calls; referer tracking ≈ geocode request path.
Referer tracking is stored in myslp->User->referer_urls
- Extended via \MySLP_User::log_referer
  - Called via hook firing on slp_rest_geocode_invalid_referer via \MySLP::log_and_validate_referer
- This is stored in the blog_option ‘user_subscription_status’

Operational/performance note: map renders can trigger multiple REST option reads

There’s an internal debugging write-up about excess option lookups during a “single map render,” discovered around SLP 5.13.8—specifically repeated lookups of option values (like label_directions). That’s relevant because map view counting is tied to a REST “options” call, and repeated calls can inflate usage and load if not controlled.
A separate internal post shows how map-related REST responses can differ (e.g., inline styles returned in the “locations-map” call), reinforcing that map rendering often involves REST payloads that can change between environments.

Map Views