mirror of
https://github.com/Hopiu/wagtail.git
synced 2026-05-01 20:14:55 +00:00
Recommend signals rather than hooks for model-level customisations
As per #5620 - signals are often overlooked as a way of customising model-level behaviour. We should recommend them over admin hooks where possible, as they aren't reliant on users taking one particular path through the admin - for example, an 'add document' signal will be triggered regardless of whether a document is created through the single uploader, multiple uploader, chooser model or a scripted task, whereas a hook would not catch all of these cases.
This commit is contained in:
parent
03cd4056df
commit
34b3f0c0fc
1 changed files with 5 additions and 1 deletions
|
|
@ -4,7 +4,11 @@
|
|||
Hooks
|
||||
=====
|
||||
|
||||
On loading, Wagtail will search for any app with the file ``wagtail_hooks.py`` and execute the contents. This provides a way to register your own functions to execute at certain points in Wagtail's execution, such as when a ``Page`` object is saved or when the main menu is constructed.
|
||||
On loading, Wagtail will search for any app with the file ``wagtail_hooks.py`` and execute the contents. This provides a way to register your own functions to execute at certain points in Wagtail's execution, such as when a page is saved or when the main menu is constructed.
|
||||
|
||||
.. note::
|
||||
Hooks are typically used to customise the view-level behaviour of the Wagtail admin and front-end. For customisations that only deal with model-level behaviour - such as calling an external service when a page or document is added - it is often better to use :doc:`Django's signal mechanism <django:topics/signals>` (see also: :ref:`Wagtail signals <signals>`), as these are not dependent on a user taking a particular path through the admin interface.
|
||||
|
||||
|
||||
Registering functions with a Wagtail hook is done through the ``@hooks.register`` decorator:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue