How optional dependencies affect a tweak
Some POM Tweaks features extend another plugin or rely on a WordPress capability that is not present on every installation. Enablement and dependency readiness are separate conditions: a saved switch cannot provide the missing integration.
Dependency checks occur at different stages
POM Tweaks uses several safe patterns according to the feature:
- Conditional visibility: a control may appear only while its required plugin is active. The WooCommerce Bookings availability feature follows this pattern.
- Runtime guard: an enabled module can stop before registering its behavior when a required plugin or WooCommerce API is unavailable.
- Conditional branch: the base module can run, while an optional part is used only when a supporting function exists.
- Environment fallback: media optimization can use the image-processing library available on the server.
Do not infer one universal behavior from a single module. The individual feature guide defines its actual requirement.
Common dependency groups
| Feature area | Dependency to confirm | Representative example |
|---|---|---|
| Commerce | WooCommerce classes, cart or checkout context, configured shipping data | Free-shipping progress and product policy controls |
| Bookings | WooCommerce Bookings and eligible booking products/resources | Enhanced availability |
| Languages and SEO | Polylang Pro language functions and a valid default language | x-default alternate link |
| Media | A supported server image library and writable uploads | Image optimization |
| Theme and presentation | The expected WordPress hook, menu, toolbar, or template context | Administration appearance and hook content |
A plugin being active is only the first check. Its data, configuration, and current request must also match.
If a dependency is removed
When a required plugin is deactivated or its API becomes unavailable:
- a guarded modern feature should stop registering the dependent behavior;
- its setting can remain saved for a later request or reactivation;
- controls that were conditional may disappear from the current settings definition;
- previously stored or generated results are not automatically removed;
- another active integration may continue to display those retained results.
Treat dependency removal as a compatibility change, not as a cleanup operation.
Validate before enabling
- Open the current guide for the exact feature.
- Confirm the required plugin and minimum site configuration.
- Prepare representative content: a booking product, shipping zone, language, attachment, product, or order as appropriate.
- Enable the tweak alone.
- Test the matching request and a request where the dependency should not apply.
- Temporarily test the approved dependency-off scenario on staging.
- Re-enable the dependency and confirm the saved configuration still produces the intended result.
If two components can provide the same outcome, continue to Resolve overlapping tweaks before production.