Developers
Build on it without forking it
W3Bullhorn is built to be extended from outside. There is a published, versioned PHP contract surface, a module system for add-ons, a documented template override path and a set of WP-CLI commands. Everything on these pages is part of that published surface; anything not on them is internal and may change in any release.
Public API
The rule that matters most
Read this before anything else on these pages.
Everything under the PHP namespace W3RP\Core\Contracts\ is public API and changes only under semantic versioning. Every other namespace — the kernel, the Bullhorn client, the sync engine, the presentation layer — is internal, and may change in any release, including a patch release. If your code reaches into one of those, it will break, and that break is not a regression.
The contract surface carries its own version, independent of the plugin version. An add-on declares the range it works against, and the plugin refuses to load it outside that range rather than failing later in a way nobody can diagnose.
| Public API | W3RP\Core\Contracts\ only |
|---|---|
| Contract version | ContractVersion::VERSION — 1.20.0 at the time of writing |
| Checking it | ContractVersion::current() and ContractVersion::satisfies( $constraint ) |
| Declaring a range | An add-on module returns ^MAJOR.MINOR from contract_constraint() |
| Compatibility enforcement | By the build, not by convention: a static gate fails the build on a breach |
| Deprecation | W3RP\Core\Contracts\Deprecation\Deprecation |
Reference
Five places to start
-
Hooks and filters
The four registrars, and 25 filters and actions.
Read more: Hooks and filters -
REST API
The w3rp/v1 namespace, and how an add-on gets a route served.
Read more: REST API -
Template overrides
Fourteen templates, overridable from a child theme.
Read more: Template overrides -
WP-CLI
Fifteen commands for sync, applications and diagnostics.
Read more: WP-CLI
The shape of it
What extending it looks like
Four registrars, each opened once per request and then closed.
- Modules. An add-on registers a module on w3rp/register_module and receives a context holding the service registry and the event bus.
- Admin REST routes. An add-on describes a route and the plugin registers it, so the capability and nonce checks cannot be omitted.
- Job fields. A contributor can add rows to what a job page shows. It cannot remove or reorder what is already there.
- Products. An add-on joins the licensing and update handling by registering a product descriptor.