Hooks
Using hooks, your plugin can exercise fine-grained control over various aspects of the build process. If your plugin defines any hooks, Bridgetown will call them at pre-defined points.
Hooks are registered to an owner and an event name. For example, if you want to execute some custom functionality every time Bridgetown renders a post, you could register a hook like this:
# Builder API:
def build
hook :posts, :post_render do |post|
# code to call after Bridgetown renders a post
end
end
# or using the hooks API directly:
Bridgetown::Hooks.register_one :posts, :post_render do |post|
# code to call after Bridgetown renders a post
end
Be aware that the build
method of the Builder API is called during the pre_read
site event, so you won’t be able to write a hook for any earlier events (after_init
for example). In those cases, you will still need to use the hooks API directly.
Bridgetown provides hooks for :site
, :resources
, :loader
, :clean
, and :[collection_label]
(aka every collection gets a unique hook, such as posts
or countries
or episodes
, etc.).
In all cases, Bridgetown calls your hooks with the owner object as the first callback parameter.
Post-Write Hook for Performing Special Operations #
The :site, :post_write
hook is particularly useful in that you can use it to
kick off additional operations which need to happen after the site has been
completely built and everything has been saved to the destination folder.
For example, there might be certain files you want to compress, or maybe you need to notify an external web service about new updates, or perhaps you’d like to run tests against the final output.
Priorities #
Hooks can be registered with a priority of high, normal, or low, and are run according to that order. The default priority is normal. To register with a different priority other than normal:
# Builder API
def build
hook :posts, :post_render, priority: :high do |post|
# High priority code to call after Bridgetown renders a post
end
end
Bridgetown::Hooks.register_one :posts, :post_render, priority: :low do |post|
# Low priority code to call after Bridgetown renders a post
end
Reloadable vs. Non-Reloadable Hooks #
All hooks are cleared during watch mode (aka bridgetown build -w
or bridgetown start
) whenever plugin or content files are updated. This makes sense for plugins that are part of the site repository and are therefore reloaded automatically.
However, for gem-based plugins, you will want to make sure you define your hooks as non-reloadable, otherwise your hooks will vanish any time the site is updated during watch mode.
def build
hook :site, :post_read, reloadable: false do |post|
# do something with site data after it's read from disk
end
end
Complete List of Hooks #
Owner | Event | Called |
---|---|---|
|
|
Right after the site initializes, but before setup & render. Good for modifying the configuration of the site. |
|
|
Right after site reset and all internal data structures are in a pristine state. Not run during SSR (see below). |
|
|
When a site is in SSR mode, any file changes result in a "soft" reset for performance reasons. Some state is persisted across resets. You can register a hook to perform additional cleanup/setup after a soft reset. |
|
|
After site reset/setup when all custom plugins, generators, etc. have loaded |
|
|
After site data has been read and loaded from disk |
|
|
Right before rendering the whole site |
|
|
After rendering the whole site, but before writing any files |
|
|
After writing the whole site to disk |
|
|
Right before reloading site plugins and Zeitwerk autoloaders during the watch process or in the console |
|
|
After reloading site plugins and Zeitwerk autoloaders during the watch process or in the console |
|
|
Whenever a resource is initialized |
|
|
Whenever a resource has read all of its data from the origin model, but before rendering/transformation |
|
|
Right before rendering a resource |
|
|
After rendering a resource, but before writing it to disk |
|
|
After writing a resource to disk |
|
|
Whenever a page is initialized |
|
|
Right before rendering a page |
|
|
After rendering a page, but before writing it to disk |
|
|
After writing a page to disk |
|
|
Before initial setup of a Zeitwerk autoloader. The `loader` object and `load_path` are provided as arguments. |
|
|
After initial setup of a Zeitwerk autoloader. The `loader` object and `load_path` are provided as arguments. |
|
|
Before a Zeitwerk autoloader reloads all code under its supervision. The `loader` object and `load_path` are provided as arguments. |
|
|
After a Zeitwerk autoloader reloads all code under its supervision. The `loader` object and `load_path` are provided as arguments. |
|
|
During the cleanup of a site's destination before it is built |