Category: Development

---

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.