Feature/add frontend tracking filter

[anthonythorne]

Summary by CodeRabbit

Release Notes

• New Features

  • Added new functionality enabling developers to programmatically control when frontend tracking scripts are loaded on the site, providing enhanced customisation options beyond the standard path-based configuration rules available through the admin interface

• Chores

  • Version updated to 0.1.1 with documentation changes

[coderabbitai]

Walkthrough

Added CHANGELOG.md documentation with version 0.1.1 release notes. Updated admin-session-recording.php to version 0.1.1, introducing a new admin_session_recording_should_load_frontend filter hook that enables programmatic control over frontend tracking script loading after UI-configured path checks.

Changes

Cohort / File(s)	Summary
Documentation CHANGELOG.md	New changelog documenting releases 0.1.0 and 0.1.1. Version 0.1.1 (2025-11-19) introduces the new admin_session_recording_should_load_frontend filter.
Plugin Core admin-session-recording.php	Version bumped to 0.1.1. Added new filter hook admin_session_recording_should_load_frontend in maybe_add_frontend_tracking_scripts to allow programmatic frontend tracking control after path-based checks.

Sequence Diagram(s)

sequenceDiagram
    participant Admin as WordPress Admin
    participant Plugin as Frontend Tracking Check
    participant Filter as New Filter Hook
    participant Scripts as Tracking Scripts

    Admin->>Plugin: Trigger page load (admin area)
    Plugin->>Plugin: Check UI-configured paths
    alt Path matches
        Plugin->>Filter: Call admin_session_recording_should_load_frontend filter
        Filter-->>Plugin: Return boolean (allow/deny)
        alt Filter returns true
            Plugin->>Scripts: Emit tracking scripts
            Scripts-->>Admin: Load frontend tracking
        else Filter returns false
            Plugin->>Admin: Skip tracking
        end
    else Path doesn't match
        Plugin->>Admin: Skip tracking
    end

Loading

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Straightforward version increment across two files
• Single, well-defined filter hook addition with documented purpose
• No complex logic changes; purely an extension point
• Changes are homogeneous and cosmetic in nature

Poem

🐰 A filter springs forth in the autumn light,
Where tracking decisions find their might,
Version bumps climb like carrots grow,
Hooks guide the plugins' gentle flow,
Changelog whispers what code will show! 📝✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately summarises the main change: adding a new filter (admin_session_recording_should_load_frontend) to enable frontend tracking.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/add-frontend-tracking-filter

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

admin-session-recording.php (1)

317-343: Excellent filter implementation with comprehensive documentation.

The new admin_session_recording_should_load_frontend filter is well-designed and positioned correctly after UI-configured path checks. The inline documentation is thorough, providing clear examples of use cases. The logic flow is efficient, only invoking the filter when UI paths don't match, and the default value of false is appropriately safe.

One optional consideration: the $options parameter contains API keys (hotjar_id, clarity_id). While this follows common WordPress patterns and provides useful context for filter callbacks, you may want to add a note in the documentation reminding developers not to log or expose these values inadvertently.

If you'd like to add the security note, consider this addition to the docblock:

  * @param bool   $should_load Whether to load tracking scripts for this path (default: false).
  * @param string $current_path The current URL path.
  * @param array  $options The plugin options.
+ *                         Note: Contains sensitive data (API keys); avoid logging or exposing.
  *
  * @return bool True to load tracking scripts, false otherwise.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 7ebe1cb and 8c33da1.

📒 Files selected for processing (2)

• CHANGELOG.md (1 hunks)
• admin-session-recording.php (3 hunks)

🔇 Additional comments (2)

CHANGELOG.md (1)

1-15: LGTM! Well-documented changelog.

The changelog follows standard formatting conventions and accurately documents both the new 0.1.1 release with the filter addition and the previous 0.1.0 release features. The description clearly explains the purpose and timing of the new filter hook.

admin-session-recording.php (1)

6-6: LGTM! Version bumps are consistent.

The version has been correctly updated to 0.1.1 in both the plugin header and the constant definition, matching the CHANGELOG entry.

Also applies to: 23-23