Docs: Enabling Syntax Highlighting (#1890)

doc/development/api/customview.rst

@@ -14,7 +14,9 @@ Control panel views
 -------------------
 
 If you want to add a custom view to the control area of an event, just register an URL in your
-``urls.py`` that lives in the ``/control/`` subpath::
+``urls.py`` that lives in the ``/control/`` subpath:
+
+.. code-block:: python
 
     from django.conf.urls import url
 
@@ -44,7 +46,9 @@ If only the ``organizer`` parameter is present, it will be ensured that:
 * The user has permission to access view the current organizer
 
 If you want to require specific permission types, we provide you with a decorator or a mixin for
-your views::
+your views:
+
+.. code-block:: python
 
     from pretix.control.permissions import (
         event_permission_required, EventPermissionRequiredMixin
@@ -61,8 +65,9 @@ your views::
         ...
 
 Similarly, there is ``organizer_permission_required`` and ``OrganizerPermissionRequiredMixin``. In case of
-event-related views, there is also a signal that allows you to add the view to the event navigation like this::
+event-related views, there is also a signal that allows you to add the view to the event navigation like this:
 
+.. code-block:: python
 
     from django.urls import resolve, reverse
     from django.dispatch import receiver
@@ -90,7 +95,9 @@ Event settings view
 -------------------
 
 A special case of a control panel view is a view hooked into the event settings page. For this case, there is a
-special navigation signal::
+special navigation signal:
+
+.. code-block:: python
 
     @receiver(nav_event_settings, dispatch_uid='friends_tickets_nav_settings')
     def navbar_settings(sender, request, **kwargs):
@@ -105,7 +112,9 @@ special navigation signal::
         }]
 
 Also, your view should inherit from ``EventSettingsViewMixin`` and your template from ``pretixcontrol/event/settings_base.html``
-for good integration. If you just want to display a form, you could do it like the following::
+for good integration. If you just want to display a form, you could do it like the following:
+
+.. code-block:: python
 
     class MySettingsView(EventSettingsViewMixin, EventSettingsFormView):
         model = Event
@@ -147,7 +156,9 @@ Including a custom view into the participant-facing frontend is a little bit dif
 no path prefix like ``control/``.
 
 First, define your URL in your ``urls.py``, but this time in the ``event_patterns`` section and wrapped by
-``event_url``::
+``event_url``:
+
+.. code-block:: python
 
     from pretix.multidomain import event_url
 
@@ -182,8 +193,9 @@ standard Django request handling: There are `ViewSets`_ to group related views i
 automatically build URL configurations from them.
 
 To integrate a custom viewset with pretix' REST API, you can just register with one of our routers within the
-``urls.py`` module of your plugin::
+``urls.py`` module of your plugin:
 
+.. code-block:: python
 
     from pretix.api.urls import event_router, router, orga_router
 
@@ -200,7 +212,9 @@ in the control panel. However, you need to make sure on your own only to return
 .event`` and ``request.organizer`` are available as usual.
 
 To require a special permission like ``can_view_orders``, you do not need to inherit from a special ViewSet base
-class, you can just set the ``permission`` attribute on your viewset::
+class, you can just set the ``permission`` attribute on your viewset:
+
+.. code-block:: python
 
     class MyViewSet(ModelViewSet):
         permission = 'can_view_orders'
@@ -208,8 +222,9 @@ class, you can just set the ``permission`` attribute on your viewset::
 
 If you want to check the permission only for some methods of your viewset, you have to do it yourself. Note here that
 API authentications can be done via user sessions or API tokens and you should therefore check something like the
-following::
+following:
 
+.. code-block:: python
 
     perm_holder = (request.auth if isinstance(request.auth, TeamAPIToken) else request.user)
     if perm_holder.has_event_permission(request.event.organizer, request.event, 'can_view_orders'):

doc/development/api/email.rst

@@ -15,7 +15,9 @@ Output registration
 The email HTML renderer API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available email renderers. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.email.BaseHTMLMailRenderer``
-that we'll provide in this plugin::
+that we'll provide in this plugin:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 
@@ -72,7 +74,9 @@ class ``TemplateBasedMailRenderer`` that you can re-use to perform the following
 * Call `inlinestyler`_ to convert all ``<style>`` style sheets to inline ``style=""``
   attributes for better compatibility
 
-To use it, you just need to implement some variables::
+To use it, you just need to implement some variables:
+
+.. code-block:: python
 
     class ClassicMailRenderer(TemplateBasedMailRenderer):
         verbose_name = _('pretix default')

doc/development/api/exporter.rst

@@ -17,7 +17,9 @@ Exporter registration
 The exporter API does not make a lot of usage from signals, however, it does use a signal to get a list of
 all available exporters. Your plugin should listen for this signal and return the subclass of
 ``pretix.base.exporter.BaseExporter``
-that we'll provide in this plugin::
+that we'll provide in this plugin:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 
@@ -31,7 +33,9 @@ that we'll provide in this plugin::
 
 Some exporters might also prove to be useful, when provided on an organizer-level. In order to declare your
 exporter as capable of providing exports spanning multiple events, your plugin should listen for this signal
-and return the subclass of ``pretix.base.exporter.BaseExporter`` that we'll provide in this plugin::
+and return the subclass of ``pretix.base.exporter.BaseExporter`` that we'll provide in this plugin:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 

doc/development/api/invoice.rst

@@ -15,7 +15,9 @@ Output registration
 The invoice renderer API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available invoice renderers. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.invoice.BaseInvoiceRenderer``
-that we'll provide in this plugin::
+that we'll provide in this plugin:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 

doc/development/api/payment.rst

@@ -19,7 +19,9 @@ Provider registration
 The payment provider API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available payment providers. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.payment.BasePaymentProvider``
-that the plugin will provide::
+that the plugin will provide:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 
@@ -140,7 +142,9 @@ it is necessary to introduce additional views. One example is the PayPal
 provider. It redirects the user to a PayPal website in the
 :py:meth:`BasePaymentProvider.checkout_prepare` step of the checkout process
 and provides PayPal with a URL to redirect back to. This URL points to a
-view which looks roughly like this::
+view which looks roughly like this:
+
+.. code-block:: python
 
     @login_required
     def success(request):

doc/development/api/placeholder.rst

@@ -13,7 +13,9 @@ Placeholder registration
 
 The placeholder API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available email placeholders. Your plugin
-should listen for this signal and return an instance of a subclass of ``pretix.base.email.BaseMailTextPlaceholder``::
+should listen for this signal and return an instance of a subclass of ``pretix.base.email.BaseMailTextPlaceholder``:
+
+.. code-block:: python
 
     from django.dispatch import receiver
 
@@ -71,7 +73,9 @@ Helper class for simple placeholders
 ------------------------------------
 
 pretix ships with a helper class that makes it easy to provide placeholders based on simple
-functions::
+functions:
+
+.. code-block:: python
 
      placeholder = SimpleFunctionalMailTextPlaceholder(
          'code', ['order'], lambda order: order.code, sample='F8VVL'

doc/development/api/plugins.rst

@@ -55,7 +55,9 @@ restricted         boolean (optional)   ``False`` by default, restricts a plugin
 compatibility      string               Specifier for compatible pretix versions.
 ================== ==================== ===========================================================
 
-A working example would be::
+A working example would be:
+
+.. code-block:: python
 
     try:
         from pretix.base.plugins import PluginConfig
@@ -81,7 +83,7 @@ A working example would be::
 
     default_app_config = 'pretix_paypal.PaypalApp'
 
-The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks
+The ``AppConfig`` class may implement a property ``compatibility_errors``, that checks
 whether the pretix installation meets all requirements of the plugin. If so,
 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``
@@ -96,7 +98,9 @@ Plugin registration
 
 Somehow, pretix needs to know that your plugin exists at all. For this purpose, we
 make use of the `entry point`_ feature of setuptools. To register a plugin that lives
-in a separate python package, your ``setup.py`` should contain something like this::
+in a separate python package, your ``setup.py`` should contain something like this:
+
+.. code-block:: python
 
     setup(
         args...,
@@ -118,7 +122,9 @@ The various components of pretix define a number of signals which your plugin ca
 listen for. We will go into the details of the different signals in the following
 pages. We suggest that you put your signal receivers into a ``signals`` submodule
 of your plugin. You should extend your ``AppConfig`` (see above) by the following
-method to make your receivers available::
+method to make your receivers available:
+
+.. code-block:: python
 
     class PaypalApp(AppConfig):
         …
@@ -127,7 +133,9 @@ method to make your receivers available::
             from . import signals  # NOQA
 
 You can optionally specify code that is executed when your plugin is activated for an event
-in the ``installed`` method::
+in the ``installed`` method:
+
+.. code-block:: python
 
     class PaypalApp(AppConfig):
         …

doc/development/api/shredder.rst

@@ -74,7 +74,7 @@ looks like this:
 
         def generate_files(self) -> List[Tuple[str, str, str]]:
             yield 'invoice-addresses.json', 'application/json', json.dumps({
-                ia.order.code: InvoiceAdddressSerializer(ia).data
+                ia.order.code: InvoiceAddressSerializer(ia).data
                 for ia in InvoiceAddress.objects.filter(order__event=self.event)
             }, indent=4)
 

doc/development/api/ticketoutput.rst

@@ -17,7 +17,9 @@ Output registration
 The ticket output API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available ticket outputs. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.ticketoutput.BaseTicketOutput``
-that we'll provide in this plugin::
+that we'll provide in this plugin:
+
+.. code-block:: python
 
     from django.dispatch import receiver