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.  

Leave a Reply