Renamed "self" template variable to "page" in docs

docs/advanced_topics/i18n/duplicate_tree.rst

@@ -131,14 +131,14 @@ You can make use of these methods in your template by doing:
 
 .. code-block:: html+django
 
-    {% if self.english_page and self.get_language != 'en' %}
-        <a href="{{ self.english_page.url }}">{% trans "View in English" %}</a>
+    {% if page.english_page and page.get_language != 'en' %}
+        <a href="{{ page.english_page.url }}">{% trans "View in English" %}</a>
     {% endif %}
 
-    {% if self.french_page and self.get_language != 'fr' %}
-        <a href="{{ self.french_page.url }}">{% trans "View in French" %}</a>
+    {% if page.french_page and page.get_language != 'fr' %}
+        <a href="{{ page.french_page.url }}">{% trans "View in French" %}</a>
     {% endif %}
 
-    {% if self.spanish_page and self.get_language != 'es' %}
-        <a href="{{ self.spanish_page.url }}">{% trans "View in Spanish" %}</a>
+    {% if page.spanish_page and page.get_language != 'es' %}
+        <a href="{{ page.spanish_page.url }}">{% trans "View in Spanish" %}</a>
     {% endif %}

docs/advanced_topics/i18n/index.rst

@@ -198,9 +198,9 @@ Finally, in the template, reference the accessors instead of the underlying data
 
 .. code-block:: html+django
 
-    {{ self.translated_title }}
+    {{ page.translated_title }}
 
-    {{ self.body }}
+    {{ page.body }}
 
 
 Other approaches

docs/advanced_topics/privacy.rst

@@ -17,7 +17,7 @@ By setting ``PASSWORD_REQUIRED_TEMPLATE`` in your Django settings file, you can
 
   PASSWORD_REQUIRED_TEMPLATE = 'myapp/password_required.html'
 
-This template will receive the same set of context variables that the blocked page would pass to its own template via ``get_context()`` - including ``self`` to refer to the page object itself - plus the following additional variables (which override any of the page's own context variables of the same name):
+This template will receive the same set of context variables that the blocked page would pass to its own template via ``get_context()`` - including ``page`` to refer to the page object itself - plus the following additional variables (which override any of the page's own context variables of the same name):
 
  - **form** - A Django form object for the password prompt; this will contain a field named ``password`` as its only visible field. A number of hidden fields may also be present, so the page must loop over ``form.hidden_fields`` if not using one of Django's rendering helpers such as ``form.as_p``.
  - **action_url** - The URL that the password form should be submitted to, as a POST request.

docs/getting_started/tutorial.rst

@@ -97,7 +97,7 @@ home\_page.html). Edit
     {% block body_class %}template-homepage{% endblock %}
 
     {% block content %}
-        {{ self.body|richtext }}
+        {{ page.body|richtext }}
     {% endblock %}
 
 .. figure:: ../_static/images/tutorial/tutorial_3.png
@@ -118,7 +118,7 @@ of a ``RichTextField``:
 .. code-block:: html+django
 
     {% load wagtailcore_tags %}
-    {{ self.body|richtext }}
+    {{ page.body|richtext }}
 
 Produces:
 
@@ -182,12 +182,12 @@ Create a template at ``blog/templates/blog/blog_page.html``:
     {% block body_class %}template-blogpage{% endblock %}
 
     {% block content %}
-        <h1>{{ self.title }}</h1>
-        <p class="meta">{{ self.date }}</p>
+        <h1>{{ page.title }}</h1>
+        <p class="meta">{{ page.date }}</p>
 
-        <div class="intro">{{ self.intro }}</div>
+        <div class="intro">{{ page.intro }}</div>
 
-        {{ self.body|richtext }}
+        {{ page.body|richtext }}
     {% endblock %}
 
 Run ``python manage.py makemigrations`` and ``python manage.py migrate``.
@@ -252,16 +252,16 @@ Adjust your blog page template to include the image:
     {% block body_class %}template-blogpage{% endblock %}
 
     {% block content %}
-        <h1>{{ self.title }}</h1>
-        <p class="meta">{{ self.date }}</p>
+        <h1>{{ page.title }}</h1>
+        <p class="meta">{{ page.date }}</p>
 
-        {% if self.main_image %}
-          {% image self.main_image width-400 %}
+        {% if page.main_image %}
+          {% image page.main_image width-400 %}
         {% endif %}
 
-        <div class="intro">{{ self.intro }}</div>
+        <div class="intro">{{ page.intro }}</div>
 
-        {{ self.body|richtext }}
+        {{ page.body|richtext }}
     {% endblock %}
 
 .. figure:: ../_static/images/tutorial/tutorial_6.png
@@ -297,9 +297,9 @@ The above creates an index type to collect all our blog posts.
     {% block body_class %}template-blogindexpage{% endblock %}
 
     {% block content %}
-        <h1>{{ self.title }}</h1>
+        <h1>{{ page.title }}</h1>
 
-        <div class="intro">{{ self.intro|richtext }}</div>
+        <div class="intro">{{ page.intro|richtext }}</div>
     {% endblock %}
 
 Related items
@@ -390,13 +390,13 @@ Extend ``blog_index_page.html`` to show related items
     {% block body_class %}template-blogindexpage{% endblock %}
 
     {% block content %}
-        <h1>{{ self.title }}</h1>
+        <h1>{{ page.title }}</h1>
 
-        <div class="intro">{{ self.intro|richtext }}</div>
+        <div class="intro">{{ page.intro|richtext }}</div>
 
-        {% if self.related_links.all %}
+        {% if page.related_links.all %}
             <ul>
-                {% for item in self.related_links.all %}
+                {% for item in page.related_links.all %}
                     <li><a href="{{ item.link }}">{{ item.title }}</a></li>
                 {% endfor %}
             </ul>

docs/reference/contrib/forms.rst

@@ -53,19 +53,19 @@ Within the ``models.py`` of one of your apps, create a model that extends ``wagt
 
 If you do not want your form page type to offer form-to-email functionality, you can inherit from AbstractForm instead of ``AbstractEmailForm``, and omit the ``to_address``, ``from_address`` and ``subject`` fields from the ``content_panels`` definition.
 
-You now need to create two templates named ``form_page.html`` and ``form_page_landing.html`` (where ``form_page`` is the underscore-formatted version of the class name). ``form_page.html`` differs from a standard Wagtail template in that it is passed a variable ``form``, containing a Django ``Form`` object, in addition to the usual ``self`` variable. A very basic template for the form would thus be:
+You now need to create two templates named ``form_page.html`` and ``form_page_landing.html`` (where ``form_page`` is the underscore-formatted version of the class name). ``form_page.html`` differs from a standard Wagtail template in that it is passed a variable ``form``, containing a Django ``Form`` object, in addition to the usual ``page`` variable. A very basic template for the form would thus be:
 
 .. code-block:: html
 
     {% load wagtailcore_tags %}
     <html>
         <head>
-            <title>{{ self.title }}</title>
+            <title>{{ page.title }}</title>
         </head>
         <body>
-            <h1>{{ self.title }}</h1>
-            {{ self.intro|richtext }}
-            <form action="{% pageurl self %}" method="POST">
+            <h1>{{ page.title }}</h1>
+            {{ page.intro|richtext }}
+            <form action="{% pageurl page %}" method="POST">
                 {% csrf_token %}
                 {{ form.as_p }}
                 <input type="submit">

docs/reference/contrib/routablepage.rst

@@ -137,6 +137,6 @@ The ``routablepageurl`` template tag
 
         {% load wagtailroutablepage_tags %}
 
-        {% routablepageurl self "feed" %}
-        {% routablepageurl self "archive" 2014 08 14 %}
-        {% routablepageurl self "food" foo="bar" baz="quux" %}
+        {% routablepageurl page "feed" %}
+        {% routablepageurl page "archive" 2014 08 14 %}
+        {% routablepageurl page "food" foo="bar" baz="quux" %}

docs/reference/contrib/staticsitegen.rst

@@ -76,11 +76,11 @@ Then in the template, you can use the ``{% routablepageurl %}`` tag to link betw
     {% load wagtailroutablepage_tags %}
 
     {% if results.has_previous %}
-        <a href="{% routablepageurl self 'page' results.previous_page_number %}">Next page</a>
+        <a href="{% routablepageurl page 'page' results.previous_page_number %}">Next page</a>
     {% else %}
 
     {% if results.has_next %}
-        <a href="{% routablepageurl self 'page' results.next_page_number %}">Next page</a>
+        <a href="{% routablepageurl page 'page' results.next_page_number %}">Next page</a>
     {% else %}
 
 

docs/reference/pages/model_recipes.rst

@@ -7,7 +7,7 @@ Recipes
 Overriding the :meth:`~wagtail.wagtailcore.models.Page.serve` Method
 --------------------------------------------------------------------
 
-Wagtail defaults to serving :class:`~wagtail.wagtailcore.models.Page`-derived models by passing ``self`` to a Django HTML template matching the model's name, but suppose you wanted to serve something other than HTML? You can override the :meth:`~wagtail.wagtailcore.models.Page.serve` method provided by the :class:`~wagtail.wagtailcore.models.Page` class and handle the Django request and response more directly.
+Wagtail defaults to serving :class:`~wagtail.wagtailcore.models.Page`-derived models by passing a reference to the page object to a Django HTML template matching the model's name, but suppose you wanted to serve something other than HTML? You can override the :meth:`~wagtail.wagtailcore.models.Page.serve` method provided by the :class:`~wagtail.wagtailcore.models.Page` class and handle the Django request and response more directly.
 
 Consider this example from the Wagtail demo site's ``models.py``, which serves an ``EventPage`` object as an iCal file if the ``format`` variable is set in the request:
 
@@ -113,7 +113,7 @@ First, ``models.py``:
 
         def serve(self, path_components=[]):
             return render(request, self.template, {
-                'self': self,
+                'page': page,
                 'echo': ' '.join(path_components),
             })
 
@@ -187,7 +187,7 @@ Now that we have the many-to-many tag relationship in place, we can fit in a way
                 blogs = blogs.filter(tags__name=tag)
 
             return render(request, self.template, {
-                'self': self,
+                'page': page,
                 'blogs': blogs,
             })
 
@@ -195,10 +195,10 @@ Here, ``blogs.filter(tags__name=tag)`` invokes a reverse Django queryset filter
 
 .. code-block:: html+django
 
-    {% for tag in self.tags.all %}
-        <a href="{% pageurl self.blog_index %}?tag={{ tag }}">{{ tag }}</a>
+    {% for tag in page.tags.all %}
+        <a href="{% pageurl page.blog_index %}?tag={{ tag }}">{{ tag }}</a>
     {% endfor %}
 
-Iterating through ``self.tags.all`` will display each tag associated with ``self``, while the link(s) back to the index make use of the filter option added to the ``BlogIndexPage`` model. A Django query could also use the ``tagged_items`` related name field to get ``BlogPage`` objects associated with a tag.
+Iterating through ``page.tags.all`` will display each tag associated with ``page``, while the link(s) back to the index make use of the filter option added to the ``BlogIndexPage`` model. A Django query could also use the ``tagged_items`` related name field to get ``BlogPage`` objects associated with a tag.
 
 This is just one possible way of creating a taxonomy for Wagtail objects. With all of the components for a taxonomy available through Wagtail, you should be able to fulfill even the most exotic taxonomic schemes.

docs/topics/images/using_in_templates.rst

@@ -16,12 +16,12 @@ For example:
     {% load wagtailimages_tags %}
     ...
 
-    {% image self.photo width-400 %}
+    {% image page.photo width-400 %}
 
     <!-- or a square thumbnail: -->
-    {% image self.photo fill-80x80 %}
+    {% image page.photo fill-80x80 %}
 
-In the above syntax example ``[image]`` is the Django object refering to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``self.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page; various resizing methods are supported, to cater for different usage cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
+In the above syntax example ``[image]`` is the Django object refering to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``page.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page; various resizing methods are supported, to cater for different usage cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
 
 Note that a space separates ``[image]`` and ``[resize-rule]``, but the resize rule must not contain spaces.
 
@@ -36,7 +36,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo max-1000x500 %}
+            {% image page.photo max-1000x500 %}
 
         Fit **within** the given dimensions. 
 
@@ -47,7 +47,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo min-500x200 %}
+            {% image page.photo min-500x200 %}
 
         **Cover** the given dimensions.
 
@@ -58,7 +58,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo width-640 %}
+            {% image page.photo width-640 %}
 
         Reduces the width of the image to the dimension specified.
 
@@ -67,7 +67,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo height-480 %}
+            {% image page.photo height-480 %}
 
         Resize the height of the image to the dimension specified.. 
 
@@ -76,7 +76,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo fill-200x200 %}
+            {% image page.photo fill-200x200 %}
 
         Resize and **crop** to fill the **exact** dimensions. 
 
@@ -98,7 +98,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo fill-200x200-c100 %}
+            {% image page.photo fill-200x200-c100 %}
 
         This will crop the image as much as it can, but will never crop into the focal point.
 
@@ -109,7 +109,7 @@ The available resizing methods are:
 
         .. code-block:: html+django
 
-            {% image self.photo original %}
+            {% image page.photo original %}
 
         Leaves the image at its original size - no resizing is performed.
 
@@ -132,7 +132,7 @@ Extra attributes can be specified with the syntax ``attribute="value"``:
 
 .. code-block:: html+django
 
-    {% image self.photo width-400 class="foo" id="bar" %}
+    {% image page.photo width-400 class="foo" id="bar" %}
 
 No validation is performed on attributes added in this way so it's possible to add `src`, `width`, `height` and `alt` of your own that might conflict with those generated by the tag itself.
 
@@ -143,17 +143,17 @@ Wagtail can assign the image data to another variable using Django's ``as`` synt
 
 .. code-block:: html+django
 
-    {% image self.photo width-400 as tmp_photo %}
+    {% image page.photo width-400 as tmp_photo %}
 
     <img src="{{ tmp_photo.url }}" width="{{ tmp_photo.width }}" 
-        height="{{ tmp_photo.height }}" alt="{{ self.photo.title }}" class="my-custom-class" />
+        height="{{ tmp_photo.height }}" alt="{{ page.photo.title }}" class="my-custom-class" />
         
 
 This syntax exposes the underlying image "Rendition" (``tmp_photo``) to the developer. A "Rendition" contains just the information specific to the way you've requested to format the image i.e dimensions and source URL.
 
 If your site defines a custom image model using ``AbstractImage``, then any additional fields you add to an image e.g a copyright holder, are **not** part of the image *rendition*, they're part of the image *model*. 
 
-Therefore in the above example, if you'd added the field ``foo`` to your AbstractImage you'd access it using ``{{ self.photo.foo }}`` not ``{{ tmp_photo.foo }}``. 
+Therefore in the above example, if you'd added the field ``foo`` to your AbstractImage you'd access it using ``{{ page.photo.foo }}`` not ``{{ tmp_photo.foo }}``. 
 
 (Due to the links in the database between renditions and their parent image, you could also access it as ``{{ tmp_photo.image.foo }}`` but this is clearly confusing.)
 

docs/topics/pages.rst

@@ -212,7 +212,7 @@ You just need to create a template in a location where it can be accessed with t
 Template context
 ----------------
 
-Wagtail renders templates with the ``self`` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, do ``{{ self.title }}``. All variables provided by `context processors <https://docs.djangoproject.com/en/1.8/ref/templates/api/#subclassing-context-requestcontext>`_ are also available.
+Wagtail renders templates with the ``page`` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, do ``{{ page.title }}``. All variables provided by `context processors <https://docs.djangoproject.com/en/1.8/ref/templates/api/#subclassing-context-requestcontext>`_ are also available.
 
 
 Customising template context
@@ -239,7 +239,7 @@ The variables can then be used in the template:
 
 .. code-block:: HTML+Django
 
-    {{ self.title }}
+    {{ page.title }}
 
     {% for entry in blog_entries %}
         {{ entry.title }}

docs/topics/snippets.rst

@@ -117,7 +117,7 @@ In the above example, the list of adverts is a fixed list, displayed as part of
   ]
 
 
-The snippet could then be accessed within your template as ``self.advert``.
+The snippet could then be accessed within your template as ``page.advert``.
 
 To attach multiple adverts to a page, the ``SnippetChooserPanel`` can be placed on an inline child object of ``BookPage``, rather than on ``BookPage`` itself. Here this child model is named ``BookPageAdvertPlacement`` (so called because there is one such object for each time that an advert is placed on a BookPage):
 
@@ -164,7 +164,7 @@ These child objects are now accessible through the page's ``advert_placements``
 
 .. code-block:: html+django
 
-  {% for advert_placement in self.advert_placements.all %}
+  {% for advert_placement in page.advert_placements.all %}
     <p><a href="{{ advert_placement.advert.url }}">{{ advert_placement.advert.text }}</a></p>
   {% endfor %}
 

docs/topics/streamfield.rst

@@ -362,7 +362,7 @@ The simplest way to render the contents of a StreamField into your template is t
 
 .. code-block:: html+django
 
-    {{ self.body }}
+    {{ page.body }}
 
 
 This will render each block of the stream in turn, wrapped in a ``<div class="block-my_block_name">`` element (where ``my_block_name`` is the block name given in the StreamField definition). If you wish to provide your own HTML markup, you can instead iterate over the field's value to access each block in turn:
@@ -370,7 +370,7 @@ This will render each block of the stream in turn, wrapped in a ``<div class="bl
 .. code-block:: html+django
 
     <article>
-        {% for block in self.body %}
+        {% for block in page.body %}
             <section>{{ block }}</section>
         {% endfor %}
     </article>
@@ -381,7 +381,7 @@ For more control over the rendering of specific block types, each block object p
 .. code-block:: html+django
 
     <article>
-        {% for block in self.body %}
+        {% for block in page.body %}
             {% if block.block_type == 'heading' %}
                 <h1>{{ block.value }}</h1>
             {% else %}
@@ -426,20 +426,20 @@ Or, when defined as a subclass of StructBlock:
             icon = 'user'
 
 
-Within the template, the block value is accessible as the variable ``self``:
+Within the template, the block value is accessible as the variable ``value``:
 
 .. code-block:: html+django
 
     {% load wagtailimages_tags %}
 
     <div class="person">
-        {% image self.photo width-400 %}
-        <h2>{{ self.first_name }} {{ self.surname }}</h2>
-        {{ self.bound_blocks.biography.render }}
+        {% image value.photo width-400 %}
+        <h2>{{ value.first_name }} {{ value.surname }}</h2>
+        {{ value.bound_blocks.biography.render }}
     </div>
 
 
-The line ``self.bound_blocks.biography.render`` warrants further explanation. While blocks such as RichTextBlock are aware of their own rendering, the actual block *values* (as returned when accessing properties of a StructBlock, such as ``self.biography``), are just plain Python values such as strings. To access the block's proper HTML rendering, you must retrieve the 'bound block' - an object which has access to both the rendering method and the value - via the ``bound_blocks`` property.
+The line ``value.bound_blocks.biography.render`` warrants further explanation. While blocks such as RichTextBlock are aware of their own rendering, the actual block *values* (as returned when accessing properties of a StructBlock, such as ``value.biography``), are just plain Python values such as strings. To access the block's proper HTML rendering, you must retrieve the 'bound block' - an object which has access to both the rendering method and the value - via the ``bound_blocks`` property.
 
 
 Custom block types

docs/topics/writing_templates.rst

@@ -39,7 +39,7 @@ For more information, see the Django documentation for the `application director
 Page content
 ~~~~~~~~~~~~
 
-The data/content entered into each page is accessed/output through Django's ``{{ double-brace }}`` notation. Each field from the model must be accessed by prefixing ``self.``. e.g the page title ``{{ self.title }}`` or another field ``{{ self.author }}``.
+The data/content entered into each page is accessed/output through Django's ``{{ double-brace }}`` notation. Each field from the model must be accessed by prefixing ``page.``. e.g the page title ``{{ page.title }}`` or another field ``{{ page.author }}``.
 
 Additionally ``request.`` is available and contains Django's request object.
 
@@ -95,10 +95,10 @@ For example:
     {% load wagtailimages_tags %}
     ...
 
-    {% image self.photo width-400 %}
+    {% image page.photo width-400 %}
 
     <!-- or a square thumbnail: -->
-    {% image self.photo fill-80x80 %}
+    {% image page.photo fill-80x80 %}
 
 
 See :ref:`image_tag` for full documentation.
@@ -117,7 +117,7 @@ Only fields using ``RichTextField`` need this applied in the template.
 
     {% load wagtailcore_tags %}
     ...
-    {{ self.body|richtext }}
+    {{ page.body|richtext }}
 
 Responsive Embeds
 -----------------
@@ -159,7 +159,7 @@ Takes a Page object and returns a relative URL (``/foo/bar/``) if within the sam
 
     {% load wagtailcore_tags %}
     ...
-    <a href="{% pageurl self.blog_page %}">
+    <a href="{% pageurl page.blog_page %}">
 
 .. _slugurl_tag:
 
@@ -172,7 +172,7 @@ Takes any ``slug`` as defined in a page's "Promote" tab and returns the URL for
 
     {% load wagtailcore_tags %}
     ...
-    <a href="{% slugurl self.your_slug %}">
+    <a href="{% slugurl page.your_slug %}">
 
 
 .. _static_tag: