Clarify plugin signal docstrings (#5397)

This commit is contained in:
luelista
2025-09-05 18:27:04 +02:00
committed by GitHub
parent 4148cc4664
commit e5301dcdc5
6 changed files with 60 additions and 54 deletions

View File

@@ -74,7 +74,7 @@ This signal allows you to put code inside the HTML ``<head>`` tag
of every page in the frontend. You will get the request as the keyword argument
``request`` and are expected to return plain HTML.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
**Note:** If PCI DSS compliance is important to you and you keep an inventory according to
rule 6.4.3 of PCI DSS, all plugins that are not required to load on a payment page should
@@ -91,7 +91,7 @@ This signal allows you to put code inside the HTML ``<head>`` tag
of the seatingframe page in the frontend. You will get the request as the keyword argument
``request`` and are expected to return plain HTML.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
html_page_header = EventPluginSignal()
@@ -102,7 +102,7 @@ This signal allows you to put code right in the beginning of the HTML ``<body>``
of every page in the frontend. You will get the request as the keyword argument
``request`` and are expected to return plain HTML.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
html_footer = EventPluginSignal()
@@ -113,7 +113,7 @@ This signal allows you to put code before the end of the HTML ``<body>`` tag
of every page in the frontend. You will get the request as the keyword argument
``request`` and are expected to return plain HTML.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
**Note:** If PCI DSS compliance is important to you and you keep an inventory according to
rule 6.4.3 of PCI DSS, all plugins that are not required to load on a payment page should
@@ -128,7 +128,7 @@ Arguments: ``request``
The signal ``pretix.presale.signals.footer_link`` allows you to add links to the footer of an event page. You
are expected to return a dictionary containing the keys ``label`` and ``url``.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
global_footer_link = GlobalSignal()
@@ -146,7 +146,7 @@ order can be completed. This is typically used for something like "accept the te
Receivers are expected to return a dictionary where the keys are globally unique identifiers for the
message and the values can be arbitrary HTML.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
checkout_flow_steps = EventPluginSignal()
@@ -154,7 +154,7 @@ checkout_flow_steps = EventPluginSignal()
This signal is sent out to retrieve pages for the checkout flow. Receivers are expected to return
a subclass of ``pretix.presale.checkoutflow.BaseCheckoutFlowStep``.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
voucher_redeem_info = EventPluginSignal()
@@ -163,7 +163,7 @@ Arguments: ``voucher``
This signal is sent out to display additional information on the "redeem a voucher" page
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
order_meta_from_request = EventPluginSignal()
@@ -195,7 +195,7 @@ Arguments: ``request``
This signals allows you to add HTML content to the confirmation page that is presented at the
end of the checkout process, just before the order is being created.
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object.
"""
@@ -206,7 +206,7 @@ Arguments: ``request``, ``invoice_address``, ``total``, ``positions``, ``payment
This signals allows you to add fees to a cart. You are expected to return a list of ``OrderFee``
objects that are not yet saved to the database (because there is no order yet).
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object and ``invoice_address`` the invoice address (useful for
tax calculation). The ``total`` keyword argument will contain the total cart sum without any fees.
You should not rely on this ``total`` value for fee calculations as other fees might interfere.
@@ -220,7 +220,7 @@ and by default only asks for the email address. You are supposed to return a dic
form fields with globally unique keys. The validated form results will be saved into the
``contact_form_data`` entry of the order's meta_info dictionary.
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object.
"""
@@ -234,7 +234,7 @@ form. You are supposed to return a dictionary of dictionaries with globally uniq
value-dictionary should contain one or more of the following keys: ``initial``, ``disabled``,
``validators``. The key of the dictionary should be the name of the form field.
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object. The ``order`` argument is ``None`` during the checkout
process and contains an order if the customer is trying to change an existing order.
"""
@@ -252,7 +252,7 @@ The ``position`` keyword argument will contain either a ``CartPosition`` object
object, depending on whether the form is called as part of the order checkout or for changing an order
later.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
question_form_fields_overrides = EventPluginSignal()
@@ -268,7 +268,7 @@ for user-defined questions.
The ``position`` keyword argument will contain a ``CartPosition`` or ``OrderPosition`` object.
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object.
"""
@@ -278,7 +278,7 @@ Arguments: ``order``, ``request``
This signal is sent out to display additional information on the order detail page
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
position_info = EventPluginSignal()
@@ -287,7 +287,7 @@ Arguments: ``order``, ``position``, ``request``
This signal is sent out to display additional information on the position detail page
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
order_info_top = EventPluginSignal()
@@ -296,7 +296,7 @@ Arguments: ``order``, ``request``
This signal is sent out to display additional information on top of the order detail page
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
position_info_top = EventPluginSignal()
@@ -305,7 +305,7 @@ Arguments: ``order``, ``position``, ``request``
This signal is sent out to display additional information on top of the position detail page
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
process_request = EventPluginSignal()
@@ -321,7 +321,7 @@ won't be processed any further down the stack.
WARNING: Be very careful about using this signal as listening to it makes it really
easy to cause serious performance problems.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
process_response = EventPluginSignal()
@@ -338,7 +338,7 @@ return the ``response`` parameter.
WARNING: Be very careful about using this signal as listening to it makes it really
easy to cause serious performance problems.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
"""
front_page_top = EventPluginSignal()
@@ -348,7 +348,7 @@ Arguments: ``request``, ``subevent``
This signal is sent out to display additional information on the frontpage above the list
of products and but below a custom frontpage text.
As with all plugin signals, the ``sender`` keyword argument will contain the event. The
As with all event plugin signals, the ``sender`` keyword argument will contain the event. The
receivers are expected to return HTML.
"""
@@ -360,7 +360,7 @@ This signal is sent out to render a seating plan, if one is configured for the s
You will be passed the ``request`` as a keyword argument. If applicable, a ``subevent`` or
``voucher`` argument might be given.
As with all plugin signals, the ``sender`` keyword argument will contain the event. The
As with all event plugin signals, the ``sender`` keyword argument will contain the event. The
receivers are expected to return HTML.
"""
@@ -371,7 +371,7 @@ Arguments: ``request``, ``subevent``
This signal is sent out to display additional information on the frontpage below the list
of products.
As with all plugin signals, the ``sender`` keyword argument will contain the event. The
As with all event plugin signals, the ``sender`` keyword argument will contain the event. The
receivers are expected to return HTML.
"""
@@ -382,7 +382,7 @@ Arguments: ``request``, ``subevent``
This signal is sent out to display additional information on the frontpage below the list
of products if the front page is shown in the widget.
As with all plugin signals, the ``sender`` keyword argument will contain the event. The
As with all event plugin signals, the ``sender`` keyword argument will contain the event. The
receivers are expected to return HTML.
"""
@@ -393,7 +393,7 @@ Arguments: 'request'
If any receiver of this signal returns ``True``, all input fields during checkout (contact data,
invoice address, confirmations) will be optional, except for questions. Use with care!
As with all plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
As with all event plugin signals, the ``sender`` keyword argument will contain the event. A ``request``
argument will contain the request object.
"""

View File

@@ -67,7 +67,7 @@ register_event_fonts = EventPluginSignal()
"""
Return a dictionaries of the following structure. Paths should be relative to static root or an absolute URL. In the
latter case, the fonts won't be available for PDF-rendering.
As with all plugin signals, the ``sender`` keyword argument will contain the event.
As with all event plugin signals, the ``sender`` keyword argument will contain the event.
{
"font name": {