You install HQ for the customer intelligence, not for the returns system. In most plugin ecosystems, that would mean paying the page-weight tax for returns anyway: the CSS still loads, the hooks still fire, the database queries still run. Tracksies doesn’t work like that. If Returns is off in your toggles, the code path doesn’t activate. At all.
That’s the whole point of feature toggles in Tracksies: off actually means off, not “hidden from the UI while still running in the background.”
What “off” actually does
When you disable a feature in Tracksies > Features:
- Assets don’t enqueue. No CSS or JS for that feature on the frontend or in wp-admin.
- Hooks don’t register. The action and filter callbacks that would otherwise fire on every request aren’t attached.
- Shortcodes don’t register. A disabled feature’s shortcode renders as its literal text on any page using it, instead of firing a handler.
- Settings UI disappears. The feature’s admin tab or settings section doesn’t render. Less clutter for staff.
- Existing data stays put. Tag data, interaction history, review records: none of it is deleted when you turn the feature off. Turn the feature back on later and the preserved data surfaces unchanged.
This matters because “off = hidden UI with code still loaded” is the pattern most WordPress plugins use. Tracksies’ pattern is the stronger one: off is a quiet, uninstalled-feeling state.
Hierarchical toggles
Features are organised in parent / child hierarchies. Turn off a parent and every child goes with it. Turn it on and each child’s own toggle controls whether it runs.
Some examples from the real config:
- HQ > Tags is the parent. Children: Tags > Commitment, Tags > Tenure, Tags > Value, Tags > Price sensitivity, Tags > Engagement, Tags > Returns, Tags > Flags. Turn off the whole tags system in one click, or keep it on and selectively disable the channels you don’t use.
- HQ > Interactions with a child Interactions > Customer notes.
- HQ > PDF with children PDF > Invoices, PDF > Packing slips, PDF > Email attachment, PDF > Frontend download, PDF > Sequential numbers.
- HQ > Aliases, HQ > Audit log, HQ > Intel panel: each independently toggleable.
Cross-plugin toggles work the same way. Trustie, Perkie, Packsie, Squizzie, Pipesie features appear in the same Features page when those plugins are active, each with their own hierarchy.
Shop-aware requirements
Some features depend on conditions. A feature marked requires: woocommerce can’t be enabled on a non-WC site. A Pro-only feature doesn’t appear on the Free tier. The features page shows why a toggle is disabled when that’s the case, instead of silently ignoring the click.
What’s stored where
Toggles are stored as WordPress options, so they travel with your site’s database. A staging-to-production database copy brings the toggle states along. A REST API endpoint exposes the feature configuration for programmatic reads, useful if you want to check toggle state from outside the admin.
If you’re weighing this up against plugin-per-feature or a monolithic suite
Plugin-per-feature: one plugin for reviews, another for PDF invoices, another for returns, another for the loyalty program. Each feature is its own install with its own update cycle, its own settings UI, its own support channel. You pay for features separately; disable ones you stop using by deactivating the whole plugin. Clean separation; lots of plugin install-and-update cycles.
Monolithic suites (some larger WC plugin ecosystems) bundle dozens of features into one install. Features are usually enabled by default; “disable” settings tend to hide UI without stopping the code from running. You get everything the plugin does whether or not you use it.
Tracksies sits between the two: one plugin ecosystem, fine-grained toggles, off-means-off architecture. The architectural benefits of plugin-per-feature (unused code doesn’t run) with the ergonomic benefits of an integrated suite (one settings page, consistent branding, shared configuration).
If you like clear separation between features at the WordPress plugin level, plugin-per-feature might suit you. If you want fine-grained control without N install-and-update cycles, Tracksies toggles give you that.
Why shops use them
Feature toggles let you buy into a plugin ecosystem without buying into every feature it ships with. Your shop stops paying the performance tax for code it never runs. New staff aren’t staring at a settings page full of things they don’t use. And if you later need that returns system, it’s one toggle away rather than another plugin install.