Skip to documentation content

Developer Reference

Use hooks, filters and versioning

Subscribe to documented actions and filters with stable signatures, explicit ownership and semantic-version compatibility rules.

Hooks are extension points only when their name, arguments, lifecycle and ownership are documented. Theme action callbacks receive a context array and a contract version. Filters receive canonical data and may return normalized presentation extensions; they cannot replace prices, availability, validation, payment, policy or booking state.

Compatibility discipline

  1. Depend on the same major contract and never claim a newer contract than the active provider. Validate the version before registration.
  2. Treat a minor release as additive: new hooks, surfaces, data keys or optional components may appear. Existing names, argument order and envelope keys remain stable.
  3. Treat removal, rename, reordered arguments or lifecycle changes as a major release and keep deprecated hooks for at least one major cycle.
  4. Use priorities only as documented. Registration is atomic; an invalid declaration must not replace the last valid one.
  5. Make callbacks no-op safely when Hotel Booking or Pro is absent. Never load a Pro class to answer a presentation question.

Record the contract version, callback purpose and test fixture in the extension README. If a public surface is missing, request a contract instead of copying private wiring from the current release.

Next: protect schema migrations and data integrity.

Was this article helpful?

Your feedback helps us improve the documentation.