Server-Side Tracking: Switching SlimStat's Tracking Mode
Applies to SlimStat 6.0.0 · checked
SlimStat’s Tracking Mode setting (javascript_mode) switches the tracker between Client and Server. Server mode records eligible requests that reach PHP, including eligible visitors whose browser has JavaScript disabled, because the pageview row is inserted during page render. Client mode is the fresh-install default, is the appropriate mode for recording visits to pages served from a full-page cache.
What Tracking Mode changes
Tracking Mode changes when PHP writes the row in wp_slim_stats. In Server mode SlimStat hooks its slimtrack() callback onto wp at priority 5, so the insert happens before HTML reaches the browser. In Client mode the JavaScript tracker posts the pageview after load, and PHP inserts no row at render time.
| Dimension | Server (javascript_mode is not on) | Client (javascript_mode = on) |
|---|---|---|
| Writes the pageview row | PHP, during page render | PHP, after the browser sends a request |
| Visitor with JavaScript disabled | Eligible requests that reach WordPress can be recorded | No browser pageview request |
| Site behind a full-page cache | Undercounts | Correct setting |
| Screen resolution, outbound links | Added later by the JS tracker | Added by the JS tracker |
| Tracking Request Method row | Hidden in Settings | Shown in Settings |
| Fresh-install default | Not selected | Selected (javascript_mode = on) |
In Server mode SlimStat also hooks slimtrack() onto login_init, when WP Users exclusion is off. When that exclusion is on, the login hook is not registered; all tracking and consent checks still apply.
When to choose Server mode
Server mode suits a site with no page cache. The help text on the setting states the rule directly: choose Server when no caching tool is active and eligible PHP requests should be recorded, and choose Client when a caching plugin such as W3 Total Cache, WP SuperCache or HyperCache is installed. Nothing here is a Pro feature.
SlimStat prints a warning when a cache and Server mode are combined: if wp-content/advanced-cache.php exists and Tracking Mode is set to Server, the reports screen says a caching plugin might be enabled and links to the configuration guide. A full-page cache runs PHP once per cache build rather than once per visitor, so Server mode undercounts on those sites. Excluding a tracker script from optimization does not make Server mode see cached page requests. Use Client mode for those pages and review caching exclusions.
How to switch Tracking Mode
Switching Tracking Mode takes five steps under SlimStat > Settings > General, in the Tracker section. The toggle is labelled Client on one side and Server on the other, where Client corresponds to javascript_mode set to on and Server uses the inactive value. Saving the tab writes the value into the slimstat_options WordPress option.
- Open SlimStat > Settings in the WordPress admin (
admin.php?page=slimconfig). - Stay on the General tab and scroll to the Tracker section header.
- Set Tracking Mode to Server, or back to Client.
- Click Save Changes at the bottom of the tab.
- Load a page while logged out, then confirm a new row appears in the Access Log.
If step 5 produces nothing, work through the tracker diagnostic checklist before changing the mode back. Note that self-visits are filtered separately, so check your own exclusion rules too.
Tracking Request Method is a separate setting
Tracking Request Method (tracking_request_method) controls the transport the JavaScript tracker uses, not whether PHP records the visit. Three values exist: rest, ajax and adblock_bypass, with ajax as the shipped default. The row is hidden in Settings while Tracking Mode is Server, and reappears when the toggle goes back to Client.
Network or protocol failures can trigger fallback to an available transport; explicit tracking rejections stop the request. The selected setting supplies the initial preference, and subsequent requests can prefer a transport that already worked. With rest selected the tracker tries the pretty REST route, then the rest_route query fallback, then admin-ajax.php. With ajax selected admin-ajax.php goes first, followed by the two REST routes. The bypass endpoint is not a fallback for either of them: SlimStat only hands its URL to the tracker script when adblock_bypass is the selected value, and any transport without a URL is dropped from the chain. With adblock_bypass selected the bypass endpoint goes first, ahead of admin-ajax.php and the REST routes. Choosing adblock_bypass also registers a rewrite rule matching request/ plus a 32-character hex hash, and changing the value flags WordPress rewrite rules to be flushed on the next request.
What the JavaScript tracker still adds in Server mode
Screen resolution reaches the database from the browser in both modes. In Server mode SlimStat passes the freshly inserted row ID to the tracker script, and the browser posts back bw/bh for resolution, sw/sh for screen width and height, and sl for server latency, updating the existing row rather than duplicating it.
An eligible PHP request in Server mode can leave a row without browser-supplied resolution, screen_width, screen_height and server_latency. The same visitor in Client mode leaves no row at all, which is exactly what the Tracking Mode help text means when it says visitors whose browser does not support JavaScript will be ignored. The parameters handed to the tracker script can be filtered through slimstat_js_params.