POM Tweaks concepts

POM Tweaks is a catalog of optional changes, not one all-or-nothing optimization. Each enabled feature has its own trigger, request context, dependencies, persistent effects, and rollback boundary. This chapter provides the model needed to evaluate those differences before following an individual tweak guide.

Start with the correct scope

All current tweaks use POM Framework. Their runtime loads only while the saved enabled status is on. Configure site features under Settings → POM Tweaks. On multisite, configure network appearance and the Updates and Themes policies under Network Admin → Settings → POM Tweaks.

The former classic interface has been removed. Its catalog links older names to the current feature guides.

Four boundaries to review

For every tweak, answer four separate questions:

  1. Loading: does its runtime participate in this request?
  2. Eligibility: are its required plugin, theme, user, content, and request conditions present?
  3. Effect: does it change only the current response, or does it write files or data?
  4. Recovery: is switching it off sufficient, or must a backup or feature-specific recovery action restore earlier state?

These questions explain why two enabled tweaks can have very different operational risk. A presentation filter can disappear on the next request, while a completed media rename or database cleanup cannot.

Read this chapter in order

  1. Why modern modules are isolated defines the loading boundary and the work that remains shared.
  2. What happens after a tweak is enabled follows a saved setting into the request where its behavior runs.
  3. What happens when a tweak is disabled separates stopped runtime work from retained results.
  4. How tweak settings persist explains site, network, transfer, and license scopes.
  5. How optional dependencies affect a tweak covers visible controls, runtime guards, and lost integrations.
  6. Resolve overlapping tweaks provides a controlled method for competing changes.
  7. Review security-sensitive tweaks identifies features that require role, data, and negative-case review.
  8. Measure an enabled tweak builds a benchmark around the feature’s real trigger.
  9. Plan and perform a rollback chooses recovery according to the kind of effect produced.

After these concepts, use the modern tweak catalog or classic tweak catalog for the exact feature.