CGM_Public/pretix_cgo
1
0
Fork 0
forked from CGM_Public/pretix_original
Code Pull Requests Actions Activity

Spelling corrections

Browse Source
This commit is contained in:
Alexander Brock
2015-07-18 00:47:18 +02:00
parent 2474104d63
commit e81bdbfd92
7 changed files with 26 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/development/api/general.rst
+1 -1
View File
@@ -11,7 +11,7 @@ HTML head injection
-------------------
These two signals allow you to put code inside the HTML ``<head>`` tag
of every page. One signal is for the frontend, one for the backend. You
of every page. One signal is for the front end, one for the back end. You
will get the request as a keyword argument ``request`` and can return plain
HTML. The ``request`` object will have an attribute ``event``.
doc/development/api/plugins.rst
+1 -1
View File
@@ -77,7 +77,7 @@ A working example would be::
The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks
whether the pretix installation meets all requirements of the plugin. If so,
it should contian ``None`` or an empty list, otherwise a list of strings containing
it should contain ``None`` or an empty list, otherwise a list of strings containing
human-readable error messages. We recommend using the ``django.utils.functional.cached_property``
decorator, as it might get called a lot. You can also implement ``compatibility_warnings``,
those will be displayed but not block the plugin execution.
doc/development/api/restriction.rst
+2 -2
View File
@@ -67,7 +67,7 @@ It is sent out with several keyword arguments:
exists, it is available in the dictionary via the special key ``'variation'``. If
the item does not have any properties, the list will contain exactly one empty
dictionary. Please note: this is *not* the list of all possible variations, this is
only the list of all variations the frontend likes to determine the status for.
only the list of all variations the front end likes to determine the status for.
Technically, you won't get ``dict`` objects but ``pretix.base.types.VariationDict``
objects, which behave exactly the same but add some extra methods.
``context``
@@ -217,7 +217,7 @@ Control interface formsets
To make it possible for the event organizer to configure your restriction, there is a
'Restrictions' page in the item configuration. This page is able to show a formset for
each restriction plugin, but *you* are required to create this formset. This is why you
should listen to the the ``pretix.control.signals.restriction_formset`` signal.
should listen to the ``pretix.control.signals.restriction_formset`` signal.
Currently, the signal comes with only one keyword argument: