What happens after a tweak is enabled
Saving an enabled switch makes a tweak eligible to run; it does not guarantee that the tweak will affect every request. The feature still depends on where WordPress is running, which integrations are available, and whether the current content matches its configuration.
The modern request lifecycle
For a modern module, the sequence is:
- An authorized administrator enables the module and saves its values under Settings → POM Tweaks.
- POM Tweaks reads the effective settings on a later request.
- The enabled module’s runtime is loaded.
- The module checks any required plugin, function, user, screen, content, or request context.
- It registers the hooks needed for the eligible context.
- WordPress or WooCommerce reaches the matching event.
- The module changes the response, performs an action, or stores an outcome according to that feature’s contract.
An enabled module can therefore remain quiet on unrelated requests. For example, upload processing belongs to media operations, cart calculations belong to commerce requests, and administration appearance belongs to the relevant WordPress administration or toolbar context.
Runtime effects and durable effects
An enabled tweak can produce either kind of result:
| Effect type | Examples | What disabling normally does |
|---|---|---|
| Request-time | Adjusted toolbar styling, filtered output, redirects, cart messages | Stops the tweak from changing later eligible requests |
| Persistent | Optimized files, renamed media, generated documents, changed metadata, cleanup results, order evidence | Stops future processing but retains completed results |
Some features combine both. A generated file may remain available after its generator is disabled, while automatic regeneration and related administration actions stop.
Prove the lifecycle
Test the entire chain rather than checking only the saved switch:
- Reload the settings page and confirm the value remained saved.
- Open one request where the feature should apply.
- Open a negative case where it should not apply.
- Repeat with the relevant role or login state.
- Confirm the optional dependency and required content exist.
- Check whether the result disappears on the next request or remains as stored data.
- Disable the tweak and repeat both cases.
If the positive case remains unchanged, review optional dependencies before treating the setting as broken.