kopia lustrzana https://github.com/wagtail/wagtail
Merge pull request #1319 from kaedroho/more-pages-docs-tweaks
Various improvements to pages docspull/1312/merge
Karl Hobley
commit
f2012bcde0
|
|
@ -4,6 +4,8 @@
|
|||
``RoutablePageMixin``
|
||||
=====================
|
||||
|
||||
.. module:: wagtail.contrib.wagtailroutablepage
|
||||
|
||||
The ``RoutablePageMixin`` mixin provides a convenient way for a page to respond on multiple sub-URLs with different views. For example, a blog section on a site might provide several different types of index page at URLs like ``/blog/2013/06/``, ``/blog/authors/bob/``, ``/blog/tagged/python/``, all served by the same page instance.
|
||||
|
||||
A ``Page`` using ``RoutablePageMixin`` exists within the page tree like any other page, but URL paths underneath it are checked against a list of patterns. If none of the patterns match, control is passed to subpages as usual (or failing that, a 404 error is thrown).
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
Creating page models
|
||||
====================
|
||||
|
||||
Each page type (a.k.a Content type) in Wagtail is represented by a Django model. All page models must inherit from the ``wagtail.wagtailcore.models.Page`` class.
|
||||
Each page type (a.k.a Content type) in Wagtail is represented by a Django model. All page models must inherit from the :class:`wagtail.wagtailcore.models.Page` class.
|
||||
|
||||
As all page types are Django models, you can use any field type that Django provides. See `Model field reference <https://docs.djangoproject.com/en/1.7/ref/models/fields/>`_ for a complete list of field types you can use. Wagtail also provides ``RichTextField`` which provides a WYSIWYG editor for editing rich-text content.
|
||||
As all page types are Django models, you can use any field type that Django provides. See `Model field reference <https://docs.djangoproject.com/en/1.7/ref/models/fields/>`_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.wagtailcore.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content.
|
||||
|
||||
|
||||
.. topic:: Django models
|
||||
|
|
@ -53,36 +53,13 @@ This example represents a typical blog post:
|
|||
.. tip::
|
||||
To keep track of ``Page`` models and avoid class name clashes, it can be helpful to suffix model class names with "Page" e.g BlogPage, ListingIndexPage.
|
||||
|
||||
In the example above the ``BlogPage`` class defines three properties: ``body``, ``date``, and ``feed_image``. These are a mix of basic Django models (``DateField``), Wagtail fields (``RichTextField``), and a pointer to a Wagtail model (``Image``).
|
||||
In the example above the ``BlogPage`` class defines three properties: ``body``, ``date``, and ``feed_image``. These are a mix of basic Django models (``DateField``), Wagtail fields (:class:`~wagtail.wagtailcore.fields.RichTextField`), and a pointer to a Wagtail model (:class:`~wagtail.wagtailimages.models.Image`).
|
||||
|
||||
Below that the ``content_panels`` and ``promote_panels`` lists define the capabilities and layout of the page editing interface in the Wagtail admin. The lists are filled with "panels" and "choosers", which will provide a fine-grain interface for inputting the model's content. The ``ImageChooserPanel``, for instance, lets one browse the image library, upload new images and input image metadata. The ``RichTextField`` is the basic field for creating web-ready website rich text, including text formatting and embedded media like images and video. The Wagtail admin offers other choices for fields, Panels, and Choosers, with the option of creating your own to precisely fit your content without workarounds or other compromises.
|
||||
Below that the ``content_panels`` and ``promote_panels`` lists define the capabilities and layout of the page editing interface in the Wagtail admin. The lists are filled with "panels" and "choosers", which will provide a fine-grain interface for inputting the model's content. The :class:`~wagtail.wagtailimages.edit_handlers.ImageChooserPanel`, for instance, lets one browse the image library, upload new images and input image metadata. The :class:`~wagtail.wagtailcore.fields.RichTextField` is the basic field for creating web-ready website rich text, including text formatting and embedded media like images and video. The Wagtail admin offers other choices for fields, Panels, and Choosers, with the option of creating your own to precisely fit your content without workarounds or other compromises.
|
||||
|
||||
Your models may be even more complex, with methods overriding the built-in functionality of the ``Page`` to achieve webdev magic. Or, you can keep your models simple and let Wagtail's built-in functionality do the work.
|
||||
Your models may be even more complex, with methods overriding the built-in functionality of the :class:`~wagtail.wagtailcore.models.Page` to achieve webdev magic. Or, you can keep your models simple and let Wagtail's built-in functionality do the work.
|
||||
|
||||
|
||||
``Page`` Class Reference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Default fields
|
||||
--------------
|
||||
|
||||
Wagtail provides some fields for the ``Page`` class by default, which will be common to all your pages. You don't need to add these fields to your own page models however you do need to allocate them to ``content_panels``, ``promote_panels`` or ``settings_panels``. See above example and for further information on the panels see :ref:`editing-api`.
|
||||
|
||||
``title`` (string, required)
|
||||
Human-readable title of the page - what you'd probably use as your ``<h1>`` tag.
|
||||
|
||||
``slug`` (string, required)
|
||||
Machine-readable URL component for this page. The name of the page as it will appear in URLs e.g ``http://domain.com/blog/[my-slug]/``
|
||||
|
||||
``seo_title`` (string)
|
||||
Alternate SEO-crafted title, mainly for use in the page ``<title>`` tag.
|
||||
|
||||
``search_description`` (string)
|
||||
SEO-crafted description of the content, used for internal search indexing, suitable for your page's ``<meta name="description">`` tag.
|
||||
|
||||
``show_in_menus`` (boolean)
|
||||
Toggles whether the page should be considered for inclusion in any site-wide menus you create.
|
||||
|
||||
Tips
|
||||
~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Let's look at an example of a panel definition:
|
|||
MultiFieldPanel(Page.promote_panels, "Common page configuration"),
|
||||
]
|
||||
|
||||
After the ``Page``-derived class definition, just add lists of panel definitions to order and organise the Wagtail page editing interface for your model.
|
||||
After the :class:`~wagtail.wagtailcore.models.Page`-derived class definition, just add lists of panel definitions to order and organise the Wagtail page editing interface for your model.
|
||||
|
||||
Available panel types
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -84,7 +84,7 @@ MultiFieldPanel
|
|||
|
||||
.. class:: MultiFieldPanel(children, heading="", classname=None)
|
||||
|
||||
This panel condenses several ``FieldPanel`` s or choosers, from a ``list`` or ``tuple``, under a single ``heading`` string.
|
||||
This panel condenses several :class:`~wagtail.wagtailadmin.edit_handlers.FieldPanel`` s or choosers, from a ``list`` or ``tuple``, under a single ``heading`` string.
|
||||
|
||||
.. attribute:: MultiFieldPanel.children
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ PageChooserPanel
|
|||
|
||||
.. class:: PageChooserPanel(field_name, model=None)
|
||||
|
||||
You can explicitly link ``Page``-derived models together using the ``Page`` model and ``PageChooserPanel``.
|
||||
You can explicitly link :class:`~wagtail.wagtailcore.models.Page`-derived models together using the :class:`~wagtail.wagtailcore.models.Page` model and ``PageChooserPanel``.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ ImageChooserPanel
|
|||
|
||||
.. class:: ImageChooserPanel(field_name)
|
||||
|
||||
Wagtail includes a unified image library, which you can access in your models through the ``Image`` model and the ``ImageChooserPanel`` chooser. Here's how:
|
||||
Wagtail includes a unified image library, which you can access in your models through the :class:`~wagtail.wagtailimages.models.Image` model and the ``ImageChooserPanel`` chooser. Here's how:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ DocumentChooserPanel
|
|||
|
||||
.. class:: DocumentChooserPanel(field_name)
|
||||
|
||||
For files in other formats, Wagtail provides a generic file store through the ``Document`` model:
|
||||
For files in other formats, Wagtail provides a generic file store through the :class:`~wagtail.wagtaildocs.models.Document` model:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ SnippetChooserPanel
|
|||
Built-in Fields and Choosers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Django's field types are automatically recognised and provided with an appropriate widget for input. Just define that field the normal Django way and pass the field name into ``FieldPanel()`` when defining your panels. Wagtail will take care of the rest.
|
||||
Django's field types are automatically recognised and provided with an appropriate widget for input. Just define that field the normal Django way and pass the field name into :class:`~wagtail.wagtailadmin.edit_handlers.FieldPanel` when defining your panels. Wagtail will take care of the rest.
|
||||
|
||||
Here are some Wagtail-specific types that you might include as fields in your models.
|
||||
|
||||
|
|
@ -273,7 +273,7 @@ By adding CSS classes to your panel definitions or adding extra parameters to yo
|
|||
Full-Width Input
|
||||
----------------
|
||||
|
||||
Use ``classname="full"`` to make a field (input element) stretch the full width of the Wagtail page editor. This will not work if the field is encapsulated in a ``MultiFieldPanel``, which places its child fields into a formset.
|
||||
Use ``classname="full"`` to make a field (input element) stretch the full width of the Wagtail page editor. This will not work if the field is encapsulated in a :class:`~wagtail.wagtailadmin.edit_handlers.MultiFieldPanel`, which places its child fields into a formset.
|
||||
|
||||
|
||||
Titles
|
||||
|
|
@ -305,7 +305,7 @@ Inline Panels and Model Clusters
|
|||
|
||||
The ``django-modelcluster`` module allows for streamlined relation of extra models to a Wagtail page. For instance, you can create objects related through a ``ForeignKey`` relationship on the fly and save them to a draft revision of a ``Page`` object. Normally, your related objects "cluster" would need to be created beforehand (or asynchronously) before linking them to a Page.
|
||||
|
||||
Let's look at the example of adding related links to a ``Page``-derived model. We want to be able to add as many as we like, assign an order, and do all of this without leaving the page editing screen.
|
||||
Let's look at the example of adding related links to a :class:`~wagtail.wagtailcore.models.Page`-derived model. We want to be able to add as many as we like, assign an order, and do all of this without leaving the page editing screen.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -338,7 +338,7 @@ Let's look at the example of adding related links to a ``Page``-derived model. W
|
|||
InlinePanel('related_links', label="Related Links"),
|
||||
]
|
||||
|
||||
The ``RelatedLink`` class is a vanilla Django abstract model. The ``BookPageRelatedLinks`` model extends it with capability for being ordered in the Wagtail interface via the ``Orderable`` class as well as adding a ``page`` property which links the model to the ``BookPage`` model we're adding the related links objects to. Finally, in the panel definitions for ``BookPage``, we'll add an ``InlinePanel`` to provide an interface for it all. Let's look again at the parameters that ``InlinePanel`` accepts:
|
||||
The ``RelatedLink`` class is a vanilla Django abstract model. The ``BookPageRelatedLinks`` model extends it with capability for being ordered in the Wagtail interface via the ``Orderable`` class as well as adding a ``page`` property which links the model to the ``BookPage`` model we're adding the related links objects to. Finally, in the panel definitions for ``BookPage``, we'll add an :class:`~wagtail.wagtailadmin.edit_handlers.InlinePanel` to provide an interface for it all. Let's look again at the parameters that :class:`~wagtail.wagtailadmin.edit_handlers.InlinePanel` accepts:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -348,7 +348,7 @@ The ``relation_name`` is the ``related_name`` label given to the cluster's ``Par
|
|||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
In previous versions, it was necessary to pass the base model as the first parameter to ``InlinePanel``; this is no longer required.
|
||||
In previous versions, it was necessary to pass the base model as the first parameter to :class:`~wagtail.wagtailadmin.edit_handlers.InlinePanel`; this is no longer required.
|
||||
|
||||
For another example of using model clusters, see :ref:`tagging`
|
||||
|
||||
|
|
@ -394,7 +394,7 @@ As standard, Wagtail organises panels into three tabs: 'Content', 'Promote' and
|
|||
Rich Text (HTML)
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Wagtail provides a general-purpose WYSIWYG editor for creating rich text content (HTML) and embedding media such as images, video, and documents. To include this in your models, use the ``RichTextField()`` function when defining a model field:
|
||||
Wagtail provides a general-purpose WYSIWYG editor for creating rich text content (HTML) and embedding media such as images, video, and documents. To include this in your models, use the :class:`~wagtail.wagtailcore.fields.RichTextField` function when defining a model field:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -409,9 +409,9 @@ Wagtail provides a general-purpose WYSIWYG editor for creating rich text content
|
|||
FieldPanel('body', classname="full"),
|
||||
]
|
||||
|
||||
``RichTextField`` inherits from Django's basic ``TextField`` field, so you can pass any field parameters into ``RichTextField`` as if using a normal Django field. This field does not need a special panel and can be defined with ``FieldPanel``.
|
||||
:class:`~wagtail.wagtailcore.fields.RichTextField` inherits from Django's basic ``TextField`` field, so you can pass any field parameters into :class:`~wagtail.wagtailcore.fields.RichTextField` as if using a normal Django field. This field does not need a special panel and can be defined with ``FieldPanel``.
|
||||
|
||||
However, template output from ``RichTextField`` is special and need to be filtered to preserve embedded content. See :ref:`rich-text-filter`.
|
||||
However, template output from :class:`~wagtail.wagtailcore.fields.RichTextField` is special and need to be filtered to preserve embedded content. See :ref:`rich-text-filter`.
|
||||
|
||||
If you're interested in extending the capabilities of the Wagtail WYSIWYG editor (``hallo.js``), See :ref:`extending_wysiwyg`.
|
||||
|
||||
|
|
@ -433,7 +433,7 @@ For information on developing custom ``hallo.js`` plugins, see the project's pag
|
|||
Image Formats in the Rich Text Editor
|
||||
-------------------------------------
|
||||
|
||||
On loading, Wagtail will search for any app with the file ``image_formats.py`` and execute the contents. This provides a way to customise the formatting options shown to the editor when inserting images in the ``RichTextField`` editor.
|
||||
On loading, Wagtail will search for any app with the file ``image_formats.py`` and execute the contents. This provides a way to customise the formatting options shown to the editor when inserting images in the :class:`~wagtail.wagtailcore.fields.RichTextField` editor.
|
||||
|
||||
As an example, add a "thumbnail" format:
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ To begin, import the the ``Format`` class, ``register_image_format`` function, a
|
|||
The unique key used to identify the format. To unregister this format, call ``unregister_image_format`` with this string as the only argument.
|
||||
|
||||
``label``
|
||||
The label used in the chooser form when inserting the image into the ``RichTextField``.
|
||||
The label used in the chooser form when inserting the image into the :class:`~wagtail.wagtailcore.fields.RichTextField`.
|
||||
|
||||
``classnames``
|
||||
The string to assign to the ``class`` attribute of the generated ``<img>`` tag.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Pages
|
||||
=====
|
||||
|
||||
Wagtail requires a little careful setup to define the types of content that you want to present through your website. The basic unit of content in Wagtail is the ``Page``, and all of your page-level content will inherit basic webpage-related properties from it. But for the most part, you will be defining content yourself, through the construction of Django models using Wagtail's ``Page`` as a base.
|
||||
Wagtail requires a little careful setup to define the types of content that you want to present through your website. The basic unit of content in Wagtail is the :class:`~wagtail.wagtailcore.models.Page`, and all of your page-level content will inherit basic webpage-related properties from it. But for the most part, you will be defining content yourself, through the construction of Django models using Wagtail's ``Page`` as a base.
|
||||
|
||||
Wagtail organizes content created from your models in a tree, which can have any structure and combination of model objects in it. Wagtail doesn't prescribe ways to organize and interrelate your content, but here we've sketched out some strategies for organizing your models.
|
||||
|
||||
|
|
@ -17,7 +17,6 @@ The presentation of your content, the actual webpages, includes the normal use o
|
|||
model_recipes
|
||||
editing_api
|
||||
streamfield
|
||||
sites
|
||||
advanced_topics/queryset_methods
|
||||
advanced_topics/private_pages
|
||||
model_reference
|
||||
queryset_reference
|
||||
advanced_topics/privacy
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@
|
|||
Recipes
|
||||
=======
|
||||
|
||||
Overriding the serve() Method
|
||||
-----------------------------
|
||||
Overriding the :meth:`~wagtail.wagtailcore.models.Page.serve` Method
|
||||
--------------------------------------------------------------------
|
||||
|
||||
Wagtail defaults to serving ``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 ``serve()`` method provided by the ``Page`` class and handle the Django request and response more directly.
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -33,15 +33,19 @@ Consider this example from the Wagtail demo site's ``models.py``, which serves a
|
|||
# Display event page as usual
|
||||
return super(EventPage, self).serve(request)
|
||||
|
||||
``serve()`` takes a Django request object and returns a Django response object. Wagtail returns a ``TemplateResponse`` object with the template and context which it generates, which allows middleware to function as intended, so keep in mind that a simpler response object like a ``HttpResponse`` will not receive these benefits.
|
||||
:meth:`~wagtail.wagtailcore.models.Page.serve` takes a Django request object and returns a Django response object. Wagtail returns a ``TemplateResponse`` object with the template and context which it generates, which allows middleware to function as intended, so keep in mind that a simpler response object like a ``HttpResponse`` will not receive these benefits.
|
||||
|
||||
With this strategy, you could use Django or Python utilities to render your model in JSON or XML or any other format you'd like.
|
||||
|
||||
|
||||
.. _overriding_route_method:
|
||||
|
||||
Adding Endpoints with Custom route() Methods
|
||||
--------------------------------------------
|
||||
Adding Endpoints with Custom :meth:`~wagtail.wagtailcore.models.Page.route` Methods
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
A much simpler way of adding more endpoints to pages is provided by the :mod:`~wagtail.contrib.wagtailroutablepage` module.
|
||||
|
||||
Wagtail routes requests by iterating over the path components (separated with a forward slash ``/``), finding matching objects based on their slug, and delegating further routing to that object's model class. The Wagtail source is very instructive in figuring out what's happening. This is the default ``route()`` method of the ``Page`` class:
|
||||
|
||||
|
|
@ -76,11 +80,11 @@ Wagtail routes requests by iterating over the path components (separated with a
|
|||
# the page matches the request, but isn't published, so 404
|
||||
raise Http404
|
||||
|
||||
``route()`` takes the current object (``self``), the ``request`` object, and a list of the remaining ``path_components`` from the request URL. It either continues delegating routing by calling ``route()`` again on one of its children in the Wagtail tree, or ends the routing process by returning a ``RouteResult`` object or raising a 404 error.
|
||||
:meth:`~wagtail.wagtailcore.models.Page.route` takes the current object (``self``), the ``request`` object, and a list of the remaining ``path_components`` from the request URL. It either continues delegating routing by calling :meth:`~wagtail.wagtailcore.models.Page.route` again on one of its children in the Wagtail tree, or ends the routing process by returning a ``RouteResult`` object or raising a 404 error.
|
||||
|
||||
The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's ``serve()`` method and return a final response: this information consists of the page object, and any additional ``args``/``kwargs`` to be passed to ``serve()``.
|
||||
The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's :meth:`~wagtail.wagtailcore.models.Page.serve` method and return a final response: this information consists of the page object, and any additional ``args``/``kwargs`` to be passed to :meth:`~wagtail.wagtailcore.models.Page.serve`.
|
||||
|
||||
By overriding the ``route()`` method, we could create custom endpoints for each object in the Wagtail tree. One use case might be using an alternate template when encountering the ``print/`` endpoint in the path. Another might be a REST API which interacts with the current object. Just to see what's involved, lets make a simple model which prints out all of its child path components.
|
||||
By overriding the :meth:`~wagtail.wagtailcore.models.Page.route` method, we could create custom endpoints for each object in the Wagtail tree. One use case might be using an alternate template when encountering the ``print/`` endpoint in the path. Another might be a REST API which interacts with the current object. Just to see what's involved, lets make a simple model which prints out all of its child path components.
|
||||
|
||||
First, ``models.py``:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,55 +1,82 @@
|
|||
Page model Reference
|
||||
====================
|
||||
|
||||
|
||||
``Page`` Class Reference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: wagtail.wagtailcore.models
|
||||
.. autoclass:: Page
|
||||
|
||||
The following Django model fields are provided for all pages and are queryable from ``Page.objects``.
|
||||
|
||||
Fields
|
||||
------
|
||||
.. attribute:: title
|
||||
|
||||
.. glossary::
|
||||
(text)
|
||||
|
||||
``title`` (text)
|
||||
Human-readable title of the page.
|
||||
|
||||
The title of the page (set in the admin).
|
||||
.. attribute:: slug
|
||||
|
||||
``slug`` (text)
|
||||
(text)
|
||||
|
||||
The slug of the page (set in the admin). This is used for constructing the page's URL.
|
||||
The slug of the page. This is used for constructing the page's URL.
|
||||
|
||||
``content_type`` (foreign key)
|
||||
For example: ``http://domain.com/blog/[my-slug]/``
|
||||
|
||||
.. attribute:: content_type
|
||||
|
||||
(foreign key to ``django.contrib.contenttypes.models.ContentType``)
|
||||
|
||||
A foreign key to the :class:`~django.contrib.contenttypes.models.ContentType` object that represents the specific model of this page.
|
||||
|
||||
``live`` (boolean)
|
||||
.. attribute:: live
|
||||
|
||||
(boolean)
|
||||
|
||||
A boolean that is set to ``True`` if the page is published.
|
||||
|
||||
Note: this field defaults to ``True`` meaning that any pages that are created programmatically will be published by default.
|
||||
|
||||
``has_unpublished_changes`` (boolean)
|
||||
.. attribute:: has_unpublished_changes
|
||||
|
||||
(boolean)
|
||||
|
||||
A boolean that is set to ``True`` when the page is either in draft or published with draft changes.
|
||||
|
||||
``owner`` (foreign key)
|
||||
.. attribute:: owner
|
||||
|
||||
(foreign key to user model)
|
||||
|
||||
A foreign key to the user that created the page.
|
||||
|
||||
``first_published_at`` (date/time)
|
||||
.. attribute:: first_published_at
|
||||
|
||||
(date/time)
|
||||
|
||||
The date/time when the page was first published.
|
||||
|
||||
.. ``seo_title`` (text)
|
||||
.. ``show_in_menus`` (boolean)
|
||||
.. ``search_description`` (text)
|
||||
.. attribute:: seo_title
|
||||
|
||||
(text)
|
||||
|
||||
Other methods, attributes and properties
|
||||
----------------------------------------
|
||||
Alternate SEO-crafted title, for use in the page's ``<title>`` HTML tag.
|
||||
|
||||
In addition to the model fields provided, ``Page`` has many properties and methods that you may wish to reference, use, or override in creating your own models. Those listed here are relatively straightforward to use, but consult the Wagtail source code for a full view of what's possible.
|
||||
.. attribute:: search_description
|
||||
|
||||
.. autoclass:: Page
|
||||
(text)
|
||||
|
||||
SEO-crafted description of the content, used for search indexing. This is also suitable for the page's ``<meta name="description">`` HTML tag.
|
||||
|
||||
.. attribute:: show_in_menus
|
||||
|
||||
(boolean)
|
||||
|
||||
Toggles whether the page should be included in site-wide menus.
|
||||
|
||||
This is used by the :meth:`~wagtail.wagtailcore.query.PageQuerySet.in_menu` QuerySet filter.
|
||||
|
||||
In addition to the model fields provided, ``Page`` has many properties and methods that you may wish to reference, use, or override in creating your own models. Those listed here are relatively straightforward to use, but consult the Wagtail source code for a full view of what's possible.
|
||||
|
||||
.. autoattribute:: specific
|
||||
|
||||
|
|
@ -126,46 +153,194 @@ In addition to the model fields provided, ``Page`` has many properties and metho
|
|||
Defines which template file should be used to render the login form for Protected pages using this model. This overrides the default, defined using ``PASSWORD_REQUIRED_TEMPLATE`` in your settings. See :ref:`private_pages`
|
||||
|
||||
|
||||
Other models
|
||||
------------
|
||||
Other core models
|
||||
-----------------
|
||||
|
||||
``Site``
|
||||
~~~~~~~~
|
||||
|
||||
The ``Site`` model is useful for multi-site installations as it allows an administrator to configure which part of the tree to use for each hostname that the server responds on.
|
||||
|
||||
This configuration is used by the :class:`~wagtail.wagtailcore.middleware.SiteMiddleware` middleware class which checks each request against this configuration and appends the Site object to the Django request object.
|
||||
|
||||
.. autoclass:: Site
|
||||
|
||||
**Database fields:**
|
||||
|
||||
.. attribute:: hostname
|
||||
|
||||
(text)
|
||||
|
||||
This is the hostname of the site, excluding the scheme, port and path.
|
||||
|
||||
For example: ``www.mysite.com``
|
||||
|
||||
.. note::
|
||||
|
||||
If you're looking for how to get the root url of a site, use the :attr:`~Site.root_url` attribute.
|
||||
|
||||
.. attribute:: port
|
||||
|
||||
(number)
|
||||
|
||||
This is the port number that the site responds on.
|
||||
|
||||
.. attribute:: root_page
|
||||
|
||||
(foreign key to :class:`~wagtail.wagtailcore.models.Page`)
|
||||
|
||||
This is a link to the root page of the site. This page will be what appears at the ``/`` URL on the site and would usually be a homepage.
|
||||
|
||||
.. attribute:: is_default_site
|
||||
|
||||
(boolean)
|
||||
|
||||
This is set to ``True`` if the site is the default. Only one site can be the default.
|
||||
|
||||
The default site is used as a fallback in situations where a site with the required hostname/port couldn't be found.
|
||||
|
||||
**Methods and attributes:**
|
||||
|
||||
.. automethod:: find_for_request
|
||||
|
||||
.. autoattribute:: root_url
|
||||
|
||||
This returns the URL of the site. It is calculated from the :attr:`~Site.hostname` and the :attr:`~Site.port` fields.
|
||||
|
||||
The scheme part of the URL is calculated based on value of the :attr:`~Site.port` field:
|
||||
|
||||
- 80 = ``http://``
|
||||
- 443 = ``https://``
|
||||
- Everything else will use the ``http://`` scheme and the port will be appended to the end of the hostname (eg. ``http://mysite.com:8000/``)
|
||||
|
||||
.. automethod:: get_site_root_paths
|
||||
|
||||
``PageRevision``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``PageRevision`` model contains all the past revisions of a page. Every time a page is created or updated, a new revision is created. Revisions can be created manually by calling the :meth:`~Page.create_revision` method.
|
||||
|
||||
Revisions are used by Wagtail for keeping draft changes out of the live database. Every revision has the content of the page serialised and stored in the :attr:`~PageRevision.content_json` field.
|
||||
|
||||
It is possible to retrieve a ``PageRevision`` as a :class:`~wagtail.wagtailcore.models.Page` object by calling the :meth:`~PageRevision.as_page_object` method.
|
||||
|
||||
.. autoclass:: PageRevision
|
||||
|
||||
**Database fields:**
|
||||
|
||||
.. attribute:: page
|
||||
|
||||
(foreign key to :class:`~wagtail.wagtailcore.models.Page`)
|
||||
|
||||
.. attribute:: submitted_for_moderation
|
||||
|
||||
(boolean)
|
||||
|
||||
.. attribute:: created_at
|
||||
|
||||
(date/time)
|
||||
|
||||
This is the time the revision was created
|
||||
|
||||
.. attribute:: user
|
||||
|
||||
(foreign key to user model)
|
||||
|
||||
This is the user that created the revision
|
||||
|
||||
.. attribute:: content_json
|
||||
|
||||
(text)
|
||||
|
||||
This field contains the JSON content for the page at the time the revision was created
|
||||
|
||||
**Methods and attributes:**
|
||||
|
||||
.. attribute:: objects
|
||||
|
||||
(manager)
|
||||
|
||||
This manager is used to retrieve all of the ``PageRevision`` objects in the database
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
PageRevision.objects.all()
|
||||
|
||||
.. attribute:: submitted_revisions
|
||||
|
||||
(manager)
|
||||
|
||||
This manager is used to retrieve all of the ``PageRevision`` objects that are awaiting moderator approval
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
PageRevision.submitted_revisions.all()
|
||||
|
||||
.. automethod:: as_page_object
|
||||
|
||||
This method retrieves this revision as an instance of its :class:`~wagtail.wagtailcore.models.Page` subclass.
|
||||
|
||||
.. automethod:: approve_moderation
|
||||
|
||||
Calling this on a revision that's in moderation will mark it as approved and publish it
|
||||
|
||||
.. automethod:: reject_moderation
|
||||
|
||||
Calling this on a revision that's in moderation will mark it as rejected
|
||||
|
||||
.. automethod:: is_latest_revision
|
||||
|
||||
Returns ``True`` if this revision is its page's latest revision
|
||||
|
||||
.. automethod:: publish
|
||||
|
||||
Calling this will copy the content of this revision into the live page object. If the page is in draft, it will be published.
|
||||
|
||||
``GroupPagePermission``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. autoclass:: GroupPagePermission
|
||||
|
||||
**Database fields:**
|
||||
|
||||
.. attribute:: group
|
||||
|
||||
(foreign key to ``django.contrib.auth.models.Group``)
|
||||
|
||||
.. attribute:: page
|
||||
|
||||
(foreign key to :class:`~wagtail.wagtailcore.models.Page`)
|
||||
|
||||
.. attribute:: permission_type
|
||||
|
||||
(choice list)
|
||||
|
||||
``PageViewRestriction``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. autoclass:: PageViewRestriction
|
||||
|
||||
**Database fields:**
|
||||
|
||||
.. attribute:: page
|
||||
|
||||
(foreign key to :class:`~wagtail.wagtailcore.models.Page`)
|
||||
|
||||
.. attribute:: password
|
||||
|
||||
(text)
|
||||
|
||||
``Orderable`` (abstract)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. autoclass:: Orderable
|
||||
|
||||
**Database fields:**
|
||||
|
||||
.. attribute:: sort_order
|
||||
|
||||
(number)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
=====================
|
||||
Page QuerySet Methods
|
||||
=====================
|
||||
=======================
|
||||
Page QuerySet reference
|
||||
=======================
|
||||
|
||||
All models that inherit from ``Page`` are given some extra QuerySet methods accessible from their ``.objects`` attribute.
|
||||
All models that inherit from :class:`~wagtail.wagtailcore.models.Page` are given some extra QuerySet methods accessible from their ``.objects`` attribute.
|
||||
|
||||
|
||||
Examples
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
.. _wagtail_site_admin:
|
||||
|
||||
Sites
|
||||
=====
|
||||
|
||||
Wagtail allows mapping a "site" (hostname or domain) to any node in the tree, using that node as the site's root. See :ref:`pages-theory`.
|
||||
|
||||
Access this by going to "Settings" and then "Sites". To try out a development site, add a single site with the hostname ``localhost`` at port ``8000`` and map it to one of the pieces of content you have created.
|
||||
Ładowanie…
Reference in New Issue