What’s New with GravityKit Developer Docs
GravityKit has launched a centralized developer documentation site at gravitykit.dev. It brings together hook and filter references for all GravityKit products into a single, searchable place. Instead of hunting through multiple plugin repositories, you can now explore what hooks exist, what data they pass, and where they live in the code.
This is not a tutorial site and it’s not trying to teach you how to build a plugin from scratch. Its value is much more practical: it makes the extensibility surface of GravityKit visible. You can see, at a glance, what you can hook into and what kind of control you have.
For anyone building on top of GravityKit—whether you write plugins, maintain advanced customizations, or just want to understand what’s possible—this is a meaningful shift.
Why Hook Documentation Is Valuable
Hooks and filters are a core concept in WordPress. They are how plugins expose extensibility so behavior can be modified or extended without touching core code. GravityKit plugins follow this same pattern and expose a large and consistent set of hooks across products.
The problem historically was not a lack of hooks. It was discoverability.
Without a central reference, developers and builders had to dig through source code, set breakpoints, log values, or rely on AI-assisted deep dives just to figure out what hooks existed and where they fired. That work is time‑consuming even for experienced developers.
Having a single, searchable list of hooks changes that. It lets you see what’s available before you start building. You can evaluate whether an idea is feasible, identify where to intervene in the lifecycle, and understand what data you’ll have access to—without reverse‑engineering the plugin.
This visibility matters for developers and technical non‑developers alike. It reduces guesswork and makes more ambitious extensions realistic.
Real‑World Value of Hooks
Hooks are not an abstract concept. They are what make it possible to extend existing functionality, add automation, and integrate GravityKit products into larger systems.
When hooks are well designed and consistently exposed, they allow you to:
- Extend behavior instead of replacing it
- Add new features without forking plugins
- Integrate with third‑party systems cleanly
- Build functionality that survives updates
That’s not theoretical. It’s how much of our own work on top of GravityKit has been possible.
Case Study: Global Variables (for GravityMath)
One recurring problem when working with GravityMath was repetition. Complex formulas often had to be written in multiple places. That made setups harder to maintain and more prone to human error.
Global Variables solved this by introducing a simple abstraction: define a slug once and map it to a formula. Anywhere you need that calculation, you reference the slug instead of rewriting the logic.
This works because of a GravityMath hook that runs before shortcode evaluation. At that point, the plugin can check whether a slug corresponds to a registered variable and replace it with the actual formula.
An important side effect is how this replacement happens. Variables are resolved one level at a time, starting with the deepest reference. That avoids WordPress’s normal shortcode nesting limitations, where identical shortcodes cannot safely contain themselves. As a result, formulas can reference other formulas recursively, with no practical nesting limit.
What started as a way to reduce repetition ended up enabling capabilities that were previously impractical. That entire approach depends on having a reliable, documented hook at the right point in the processing flow.
Case Study: Native Kanban View for GravityView
GravityView is built as a framework, not just a display tool. It exposes hooks for registering view types, controlling data queries, and handling rendering.
Those hooks made it possible for a third party to build a native Kanban view for GravityView. This wasn’t a workaround or a front‑end overlay. It was a real view type that integrates into GravityView’s system and behaves like a first‑class citizen.
To make that work, the plugin needed to:
- Register a new view type
- Control how entries are grouped and displayed
- Integrate with GravityView’s existing filtering and permissions logic
All of that was achievable because GravityView exposes the necessary extension points. Without those hooks, building a new view type would require modifying core code or relying on fragile hacks—neither of which is maintainable.
This is a good example of how GravityKit’s architecture enables features that go well beyond configuration and into true platform‑level extension.
Other Snippets and Extensions
Hooks don’t only enable large plugins. Many smaller but high‑impact enhancements rely on them as well. A number of examples live in the BrightLeaf Digital snippet library.
Some representative examples include:
- Restart workflow on GravityView approval and subscription payment: Coordinates GravityView events and Gravity Flow workflows by delaying or restarting automation until specific conditions are met.
- Correct GravityView links to work with tabs: Adjusts how links are generated so navigation behaves correctly inside tabbed interfaces.
Each of these relies on hooks to intercept data, modify output, or respond to events at the right moment. Without knowing what hooks are available and what they provide, these kinds of enhancements are hard to build safely.
What This Means Going Forward
The new GravityKit developer docs don’t change how hooks work. They change how accessible they are.
By making hooks visible, searchable, and easy to reference, gravitykit.dev lowers the cost of exploration. You spend less time finding the right entry point and more time building on top of a solid foundation.
For developers, that means faster iteration and fewer dead ends. For technical non‑developers, it means you can better understand what’s possible, ask more precise questions, and plan extensions with confidence.
If you build on top of GravityKit in any serious way, this documentation is now part of the toolkit.