kopia lustrzana https://github.com/wagtail/wagtail
Merge pull request #256 from jeffrey-hearn/docs
[RFC] Core feature documentation (Search, Snippets, Wagtail Tree, Editing API, etc.)pull/173/merge
Tom Dyson
commit
01d059eedf
|
|
@ -0,0 +1,17 @@
|
|||
Advanced Topics
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. note::
|
||||
This documentation is currently being written.
|
||||
|
||||
replacing image processing backend
|
||||
|
||||
custom image processing tags?
|
||||
|
||||
wagtail user bar custom CSS option?
|
||||
|
||||
extending hallo editor plugins with editor_js()
|
||||
|
||||
injecting any JS into page edit with editor_js()
|
||||
|
||||
Custom content module (same level as docs or images)
|
||||
|
|
@ -1,3 +1,189 @@
|
|||
For Django developers
|
||||
==================
|
||||
=====================
|
||||
|
||||
.. note::
|
||||
This documentation is currently being written.
|
||||
|
||||
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 contruction 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.
|
||||
|
||||
The presentation of your content, the actual webpages, includes the normal use of the Django template system. We'll cover additional functionality that Wagtail provides at the template level later on.
|
||||
|
||||
But first, we'll take a look at the ``Page`` class and model definitions.
|
||||
|
||||
|
||||
The Page Class
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
``Page`` uses Django's model interface, so you can include any field type and field options that Django allows. Wagtail provides some fields and editing handlers that simplify data entry in the Wagtail admin interface, so you may want to keep those in mind when deciding what properties to add to your models in addition to those already provided by ``Page``.
|
||||
|
||||
|
||||
Built-in Properties of the Page Class
|
||||
-------------------------------------
|
||||
|
||||
Wagtail provides some properties in the ``Page`` class which are common to most webpages. Since you'll be subclassing ``Page``, you don't have to worry about implementing them.
|
||||
|
||||
Public Properties
|
||||
`````````````````
|
||||
|
||||
``title`` (string, required)
|
||||
Human-readable title for the content
|
||||
|
||||
``slug`` (string, required)
|
||||
Machine-readable URL component for this piece of content. 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 which overrides the normal title for use in the ``<head>`` of a page
|
||||
|
||||
``search_description`` (string)
|
||||
A SEO-crafted description of the content, used in both internal search indexing and for the meta description read by search engines
|
||||
|
||||
The ``Page`` class actually has alot more to it, but these are probably the only built-in properties you'll need to worry about when creating templates for your models.
|
||||
|
||||
|
||||
Anatomy of a Wagtail Model
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
So what does a Wagtail model definition look like? Here's a model representing a typical blog post:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.db import models
|
||||
|
||||
from wagtail.wagtailcore.models import Page
|
||||
from wagtail.wagtailcore.fields import RichTextField
|
||||
from wagtail.wagtailadmin.edit_handlers import FieldPanel
|
||||
from wagtail.wagtailimages.edit_handlers import ImageChooserPanel
|
||||
from wagtail.wagtailimages.models import Image
|
||||
|
||||
class BlogPage(Page):
|
||||
body = RichTextField()
|
||||
date = models.DateField("Post date")
|
||||
feed_image = models.ForeignKey(
|
||||
'wagtailimages.Image',
|
||||
null=True,
|
||||
blank=True,
|
||||
on_delete=models.SET_NULL,
|
||||
related_name='+'
|
||||
)
|
||||
|
||||
BlogPage.content_panels = [
|
||||
FieldPanel('title', classname="full title"),
|
||||
FieldPanel('date'),
|
||||
FieldPanel('body', classname="full"),
|
||||
]
|
||||
|
||||
BlogPage.promote_panels = [
|
||||
FieldPanel('slug'),
|
||||
FieldPanel('seo_title'),
|
||||
FieldPanel('show_in_menus'),
|
||||
FieldPanel('search_description'),
|
||||
ImageChooserPanel('feed_image'),
|
||||
]
|
||||
|
||||
To keep track of your ``Page``-derived models, it might be helpful to include "Page" as the last part of your classname. ``BlogPage`` 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``).
|
||||
|
||||
Next, the ``content_panels`` and ``promote_panels`` lists define the capabilities and layout of the Wagtail admin page edit interface. 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.
|
||||
|
||||
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.
|
||||
|
||||
Now that we have a basic idea of how our content is defined, lets look at relationships between pieces of content.
|
||||
|
||||
|
||||
Introduction to Trees
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you're unfamiliar with trees as an abstract data type, you might want to `review the concepts involved. <http://en.wikipedia.org/wiki/Tree_(data_structure)>`_
|
||||
|
||||
As a web developer, though, you probably already have a good understanding of trees as filesystem directories or paths. Wagtail pages can create the same structure, as each page in the tree has its own URL path, like so::
|
||||
|
||||
/
|
||||
people/
|
||||
nien-nunb/
|
||||
laura-roslin/
|
||||
events/
|
||||
captain-picard-day/
|
||||
winter-wrap-up/
|
||||
|
||||
The Wagtail admin interface uses the tree to organize content for editing, letting you navigate up and down levels in the tree through its Explorer menu. This method of organization is a good place to start in thinking about your own Wagtail models.
|
||||
|
||||
|
||||
Nodes and Leaves
|
||||
----------------
|
||||
|
||||
It might be handy to think of the ``Page``-derived models you want to create as being one of two node types: parents and leaves. Wagtail isn't prescriptive in this approach, but it's a good place to start if you're not experienced in structuring your own content types.
|
||||
|
||||
|
||||
Nodes
|
||||
`````
|
||||
Parent nodes on the Wagtail tree probably want to organize and display a browsable index of their descendents. A blog, for instance, needs a way to show a list of individual posts.
|
||||
|
||||
A Parent node could provide its own function returning its descendant objects.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class EventPageIndex(Page):
|
||||
...
|
||||
def events(self):
|
||||
# Get list of event pages that are descendants of this page
|
||||
events = EventPage.objects.filter(
|
||||
live=True,
|
||||
path__startswith=self.path
|
||||
)
|
||||
return events
|
||||
|
||||
This example makes sure to limit the returned objects to pieces of content which make sense, specifically ones which have been published through Wagtail's admin interface (``live=True``) and are descendants of this node. Wagtail will allow the "illogical" placement of child nodes under a parent, so it's necessary for a parent model to index only those children which make sense.
|
||||
|
||||
|
||||
Leaves
|
||||
``````
|
||||
Leaves are the pieces of content itself, a page which is consumable, and might just consist of a bunch of properties. A blog page leaf might have some body text and an image. A person page leaf might have a photo, a name, and an address.
|
||||
|
||||
It might be helpful for a leaf to provide a way to back up along the tree to a parent, such as in the case of breadcrumbs navigation. The tree might also be deep enough that a leaf's parent won't be included in general site navigation.
|
||||
|
||||
The model for the leaf could provide a function that traverses the tree in the opposite direction and returns an appropriate ancestor:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class BlogPage(Page):
|
||||
...
|
||||
def blog_index(self):
|
||||
# Find blog index in ancestors
|
||||
for ancestor in reversed(self.get_ancestors()):
|
||||
if isinstance(ancestor.specific, BlogIndexPage):
|
||||
return ancestor
|
||||
|
||||
# No ancestors are blog indexes, just return first blog index in database
|
||||
return BlogIndexPage.objects.first()
|
||||
|
||||
Since Wagtail doesn't limit what Page-derived classes can be assigned as parents and children, the reverse tree traversal needs to accommodate cases which might not be expected, such as the lack of a "logical" parent to a leaf.
|
||||
|
||||
|
||||
Other Relationships
|
||||
```````````````````
|
||||
Your ``Page``-derived models might have other interrelationships which extend the basic Wagtail tree or depart from it entirely. You could provide functions to navigate between siblings, such as a "Next Post" link on a blog page (``post->post->post``). It might make sense for subtrees to interrelate, such as in a discussion forum (``forum->post->replies``) Skipping across the hierarchy might make sense, too, as all objects of a certain model class might interrelate regardless of their ancestors (``events = EventPage.objects.all``). Since there's no restriction on the combination of model classes that can be used at any point in the tree, and it's largely up to the models to define their interrelations, the possibilities are really endless.
|
||||
|
||||
|
||||
Anatomy of a Wagtail Request
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For going beyond the basics of model definition and interrelation, it might help to know how Wagtail handles requests and constructs responses. In short, it goes something like:
|
||||
|
||||
#. Django gets a request and routes through Wagtail's URL dispatcher definitions
|
||||
#. Starting from the root content piece, Wagtail traverses the page tree, letting the model for each piece of content along the path decide how to ``route()`` the next step in the path.
|
||||
#. A model class decides that routing is done and it's now time to ``serve()`` content.
|
||||
#. The model constructs a context, finds a template to pass it to, and renders the content.
|
||||
#. The templates are rendered and the response object is sent back to the requester.
|
||||
|
||||
You can apply custom behavior to this process by overriding the ``route()`` and ``serve()`` methods of the ``Page`` class in your own models.
|
||||
|
||||
|
||||
Site
|
||||
~~~~
|
||||
|
||||
Django's built-in admin interface provides the way to map a "site" (hostname or domain) to any node in the wagtail tree, using that node as the site's root.
|
||||
|
||||
Access this by going to ``/django-admin/`` and then "Home › Wagtailcore › 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.
|
||||
|
||||
Wagtail's developers plan to move the site settings into the Wagtail admin interface.
|
||||
|
|
|
|||
|
|
@ -14,10 +14,31 @@ https://docs.djangoproject.com/en/dev/topics/templates/
|
|||
Python programmers new to Django/Wagtail may prefer more technical documentation:
|
||||
https://docs.djangoproject.com/en/dev/ref/templates/api/
|
||||
|
||||
========================
|
||||
Page content and variables
|
||||
========================
|
||||
==========================
|
||||
Displaying Pages
|
||||
==========================
|
||||
|
||||
Template Location
|
||||
-----------------
|
||||
|
||||
For each of your ``Page``-derived models, Wagtail will look for a template in the following location, relative to your project root::
|
||||
|
||||
project/
|
||||
app/
|
||||
templates/
|
||||
app/
|
||||
blog_index_page.html
|
||||
models.py
|
||||
|
||||
Class names are converted from camel case to underscores. For example, the template for model class ``BlogIndexPage`` would be assumed to be ``blog_index_page.html``. For more information, see the Django documentation for the `application directories template loader`_.
|
||||
|
||||
.. _application directories template loader: https://docs.djangoproject.com/en/dev/ref/templates/api/
|
||||
|
||||
|
||||
Self
|
||||
----
|
||||
|
||||
By default, the context passed to a model's template consists of two properties: ``self`` and ``request``. ``self`` is the model object being displayed. ``request`` is the normal Django request object. So, to include the title of a ``Page``, use ``{{ self.title }}``.
|
||||
|
||||
========================
|
||||
Static files (css, js, images)
|
||||
|
|
@ -104,14 +125,42 @@ The available ``method`` s are:
|
|||
|
||||
To request the "original" version of an image, it is suggested you rely on the lack of upscalling support by requesting an image much larger than it's maximum dimensions. e.g to insert an image who's dimensions are uncertain/unknown, at it's maximum size, try: ``{% image self.image width-10000 %}``. This assumes the image is unlikely to be larger than 10000px wide.
|
||||
|
||||
|
||||
Rich text (filter)
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This filter is required for use with any ``RichTextField``. It will expand internal shorthand references to embeds and links made in the Wagtail editor into fully-baked HTML ready for display. **Note that the template tag loaded differs from the name of the filter.**
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% load rich_text %}
|
||||
...
|
||||
{{ body|richtext }}
|
||||
|
||||
Internal links (tag)
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**pageurl**
|
||||
|
||||
Takes a ``Page``-derived object and returns its URL as relative (``/foo/bar/``) if it's within the same site as the current page, or absolute (``http://example.com/foo/bar/``) if not.
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% load pageurl %}
|
||||
...
|
||||
<a href="{% pageurl blog %}">
|
||||
|
||||
**slugurl**
|
||||
|
||||
Takes a ``slug`` string and returns the URL for the ``Page``-derived object with that slug. Like ``pageurl``, will try to provide a relative link if possible, but will default to an absolute link if on a different site.
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% load slugurl %}
|
||||
...
|
||||
<a href="{% slugurl blogslug %}">
|
||||
|
||||
|
||||
|
||||
|
||||
Static files (tag)
|
||||
~~~~~~~~~~~~~~
|
||||
|
|
@ -121,7 +170,15 @@ Misc
|
|||
~~~~~~~~~~
|
||||
|
||||
|
||||
|
||||
========================
|
||||
Wagtail User Bar
|
||||
========================
|
||||
|
||||
This tag provides a Wagtail icon and flyout menu on the top-right of a page for a logged-in user with editing capabilities, with the option of editing the current Page-derived object or adding a new sibling object.
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% load wagtailuserbar %}
|
||||
...
|
||||
{% wagtailuserbar %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,202 @@
|
|||
|
||||
Editing API
|
||||
===========
|
||||
|
||||
.. note::
|
||||
This documentation is currently being written.
|
||||
|
||||
|
||||
Wagtail provides a highly-customizable editing interface consisting of several components:
|
||||
|
||||
* **Fields** — built-in content types to augment the basic types provided by Django.
|
||||
* **Panels** — the basic editing blocks for fields, groups of fields, and related object clusters
|
||||
* **Choosers** — interfaces for finding related objects in a ForeignKey relationship
|
||||
|
||||
Configuring your models to use these components will shape the Wagtail editor to your needs. Wagtail also provides an API for injecting custom CSS and Javascript for further customization, including extending the hallo.js rich text editor.
|
||||
|
||||
There is also an Edit Handler API for creating your own Wagtail editor components.
|
||||
|
||||
|
||||
Defining Panels
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
A "panel" is the basic editing block in Wagtail. Wagtail will automatically pick the appropriate editing widget for most Django field types, you just need to add a panel for each field you want to show in the Wagtail page editor, in the order you want them to appear.
|
||||
|
||||
There are three types of panels:
|
||||
|
||||
``FieldPanel( field_name, classname=None )``
|
||||
This is the panel used for basic Django field types. ``field_name`` is the name of the class property used in your model definition. ``classname`` is a string of optional CSS classes given to the panel which are used in formatting and scripted interactivity. By default, panels are formatted as inset fields. The CSS class ``full`` can be used to format the panel so it covers the full width of the Wagtail page editor. The CSS class ``title`` can be used to mark a field as the source for auto-generated slug strings.
|
||||
|
||||
``MultiFieldPanel( panel_list, heading )``
|
||||
This panel condenses several ``FieldPanel`` s or choosers, from a list or tuple, under a single ``heading`` string.
|
||||
|
||||
``InlinePanel( base_model, relation_name, panels=None, label='', help_text='' )``
|
||||
This panel allows for the creation of a "cluster" of related objects over a join to a separate model, such as a list of related links or slides to an image carousel. This is a very powerful, but tricky feature which will take some space to cover, so we'll skip over it for now. For a full explaination on the usage of ``InlinePanel``, see :ref:`inline_panels`.
|
||||
|
||||
Wagtail provides a tabbed interface to help organize panels. ``content_panels`` is the main tab, used for the meat of your model content. The other, ``promote_panels``, is suggested for organizing metadata about the content, such as SEO information and other machine-readable information. Since you're writing the panel definitions, you can organize them however you want.
|
||||
|
||||
Let's look at an example of a panel definition:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
COMMON_PANELS = (
|
||||
FieldPanel('slug'),
|
||||
FieldPanel('seo_title'),
|
||||
FieldPanel('show_in_menus'),
|
||||
FieldPanel('search_description'),
|
||||
)
|
||||
|
||||
...
|
||||
|
||||
class ExamplePage( Page ):
|
||||
# field definitions omitted
|
||||
...
|
||||
|
||||
ExamplePage.content_panels = [
|
||||
FieldPanel('title', classname="full title"),
|
||||
FieldPanel('body', classname="full"),
|
||||
FieldPanel('date'),
|
||||
ImageChooserPanel('splash_image'),
|
||||
DocumentChooserPanel('free_download'),
|
||||
PageChooserPanel('related_page'),
|
||||
]
|
||||
|
||||
ExamplePage.promote_panels = [
|
||||
MultiFieldPanel(COMMON_PANELS, "Common page configuration"),
|
||||
]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Built-in Fields and Choosers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Django's field types are automatically recognized 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.
|
||||
|
||||
Here are some Wagtail-specific types that you might include as fields in your models.
|
||||
|
||||
|
||||
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:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from wagtail.wagtailcore.fields import RichTextField
|
||||
...
|
||||
class BookPage(Page):
|
||||
book_text = RichTextField()
|
||||
|
||||
|
||||
|
||||
If you're interested in extending the capabilities of the Wagtail editor, See :ref:`extending_wysiwyg`.
|
||||
|
||||
|
||||
Images
|
||||
------
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from wagtail.wagtailimages.models import Image
|
||||
|
||||
feed_image = models.ForeignKey(
|
||||
'wagtailimages.Image',
|
||||
null=True,
|
||||
blank=True,
|
||||
on_delete=models.SET_NULL,
|
||||
related_name='+'
|
||||
)
|
||||
|
||||
|
||||
Documents
|
||||
---------
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from wagtail.wagtaildocs.models import Document
|
||||
|
||||
link_document = models.ForeignKey(
|
||||
'wagtaildocs.Document',
|
||||
null=True,
|
||||
blank=True,
|
||||
related_name='+'
|
||||
)
|
||||
|
||||
|
||||
Pages and Page-derived Models
|
||||
-----------------------------
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from wagtail.wagtailcore.models import Page
|
||||
|
||||
page = models.ForeignKey(
|
||||
'wagtailcore.Page',
|
||||
related_name='+',
|
||||
null=True,
|
||||
blank=True
|
||||
)
|
||||
|
||||
Can also use more specific models.
|
||||
|
||||
|
||||
Snippets (and Basic Django Models?)
|
||||
--------
|
||||
|
||||
Snippets are not not subclasses, so you must include the model class directly. A chooser is provided which takes the snippet class.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
advert = models.ForeignKey(
|
||||
'demo.Advert',
|
||||
related_name='+'
|
||||
)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
PageChooserPanel
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
ImageChooserPanel
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
DocumentChooserPanel
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
SnippetChooserPanel
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
.. _inline_panels:
|
||||
|
||||
Inline Panels and Model Clusters
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``django-modelcluster`` module allows for streamlined relation of extra models to a Wagtail page.
|
||||
|
||||
|
||||
.. _extending_wysiwyg:
|
||||
|
||||
Extending the WYSIWYG Editor (hallo.js)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
|
||||
Edit Handler API
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
|
||||
|
|
@ -10,10 +10,14 @@ It supports Django 1.6.2+ on Python 2.6 and 2.7. Django 1.7 and Python 3 support
|
|||
|
||||
gettingstarted
|
||||
building_your_site/index
|
||||
editing_api
|
||||
snippets
|
||||
wagtail_search
|
||||
form_builder
|
||||
model_recipes
|
||||
advanced_topics
|
||||
deploying
|
||||
performance
|
||||
form_builder
|
||||
static_site_generation
|
||||
contributing
|
||||
support
|
||||
|
|
|
|||
|
|
@ -0,0 +1,176 @@
|
|||
|
||||
Model Recipes
|
||||
=============
|
||||
|
||||
Overriding the 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.
|
||||
|
||||
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:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class EventPage(Page):
|
||||
...
|
||||
def serve(self, request):
|
||||
if "format" in request.GET:
|
||||
if request.GET['format'] == 'ical':
|
||||
# Export to ical format
|
||||
response = HttpResponse(
|
||||
export_event(self, 'ical'),
|
||||
content_type='text/calendar',
|
||||
)
|
||||
response['Content-Disposition'] = 'attachment; filename=' + self.slug + '.ics'
|
||||
return response
|
||||
else:
|
||||
# Unrecognised format error
|
||||
message = 'Could not export event\n\nUnrecognised format: ' + request.GET['format']
|
||||
return HttpResponse(message, content_type='text/plain')
|
||||
else:
|
||||
# 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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Adding Endpoints with Custom route() Methods
|
||||
--------------------------------------------
|
||||
|
||||
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:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class Page(...):
|
||||
|
||||
...
|
||||
|
||||
def route(self, request, path_components):
|
||||
if path_components:
|
||||
# request is for a child of this page
|
||||
child_slug = path_components[0]
|
||||
remaining_components = path_components[1:]
|
||||
|
||||
# find a matching child or 404
|
||||
try:
|
||||
subpage = self.get_children().get(slug=child_slug)
|
||||
except Page.DoesNotExist:
|
||||
raise Http404
|
||||
|
||||
# delegate further routing
|
||||
return subpage.specific.route(request, remaining_components)
|
||||
|
||||
else:
|
||||
# request is for this very page
|
||||
if self.live:
|
||||
# use the serve() method to render the request if the page is published
|
||||
return self.serve(request)
|
||||
else:
|
||||
# the page matches the request, but isn't published, so 404
|
||||
raise Http404
|
||||
|
||||
The contract is pretty simple. ``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 serving something -- either normally through the ``self.serve()`` method or by raising a 404 error.
|
||||
|
||||
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.
|
||||
|
||||
First, ``models.py``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.shortcuts import render
|
||||
|
||||
...
|
||||
|
||||
class Echoer(Page):
|
||||
|
||||
def route(self, request, path_components):
|
||||
if path_components:
|
||||
return render(request, self.template, {
|
||||
'self': self,
|
||||
'echo': ' '.join(path_components),
|
||||
})
|
||||
else:
|
||||
if self.live:
|
||||
return self.serve(request)
|
||||
else:
|
||||
raise Http404
|
||||
|
||||
Echoer.content_panels = [
|
||||
FieldPanel('title', classname="full title"),
|
||||
]
|
||||
|
||||
Echoer.promote_panels = [
|
||||
MultiFieldPanel(COMMON_PANELS, "Common page configuration"),
|
||||
]
|
||||
|
||||
This model, ``Echoer``, doesn't define any properties, but does subclass ``Page`` so objects will be able to have a custom title and slug. The template just has to display our ``{{ echo }}`` property. We're skipping the ``serve()`` method entirely, but you could include your render code there to stay consistent with Wagtail's conventions.
|
||||
|
||||
Now, once creating a new ``Echoer`` page in the Wagtail admin titled "Echo Base," requests such as::
|
||||
|
||||
http://127.0.0.1:8000/echo-base/tauntaun/kennel/bed/and/breakfast/
|
||||
|
||||
Will return::
|
||||
|
||||
tauntaun kennel bed and breakfast
|
||||
|
||||
|
||||
Tagging
|
||||
-------
|
||||
|
||||
Wagtail provides tagging capability through the combination of two django modules, ``taggit`` and ``modelcluster``. ``taggit`` provides a model for tags which is extended by ``modelcluster``, which in turn provides some magical database abstraction which makes drafts and revisions possible in Wagtail. It's a tricky recipe, but the net effect is a many-to-many relationship between your model and a tag class reserved for your model.
|
||||
|
||||
Using an example from the Wagtail demo site, here's what the tag model and the relationship field looks like in ``models.py``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from modelcluster.fields import ParentalKey
|
||||
from modelcluster.tags import ClusterTaggableManager
|
||||
from taggit.models import Tag, TaggedItemBase
|
||||
...
|
||||
class BlogPageTag(TaggedItemBase):
|
||||
content_object = ParentalKey('demo.BlogPage', related_name='tagged_items')
|
||||
...
|
||||
class BlogPage(Page):
|
||||
...
|
||||
tags = ClusterTaggableManager(through=BlogPageTag, blank=True)
|
||||
|
||||
BlogPage.promote_panels = [
|
||||
...
|
||||
FieldPanel('tags'),
|
||||
]
|
||||
|
||||
Wagtail's admin provides a nice interface for inputting tags into your content, with typeahead tag completion and friendly tag icons.
|
||||
|
||||
Now that we have the many-to-many tag relationship in place, we can fit in a way to render both sides of the relation. Here's more of the Wagtail demo site ``models.py``, where the index model for ``BlogPage`` is extended with logic for filtering the index by tag:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class BlogIndexPage(Page):
|
||||
...
|
||||
def serve(self, request):
|
||||
# Get blogs
|
||||
blogs = self.blogs
|
||||
|
||||
# Filter by tag
|
||||
tag = request.GET.get('tag')
|
||||
if tag:
|
||||
blogs = blogs.filter(tags__name=tag)
|
||||
|
||||
return render(request, self.template, {
|
||||
'self': self,
|
||||
'blogs': blogs,
|
||||
})
|
||||
|
||||
Here, ``blogs.filter(tags__name=tag)`` invokes a reverse Django queryset filter on the ``BlogPageTag`` model to optionally limit the ``BlogPage`` objects sent to the template for rendering. Now, lets render both sides of the relation by showing the tags associated with an object and a way of showing all of the objects associated with each tag. This could be added to the ``blog_page.html`` template:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% for tag in self.tags.all %}
|
||||
<a href="{% pageurl self.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.
|
||||
|
||||
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.
|
||||
|
|
@ -0,0 +1,140 @@
|
|||
Snippets
|
||||
========
|
||||
|
||||
Snippets are pieces of content which do not necessitate a full webpage to render. They could be used for making secondary content, such as headers, footers, and sidebars, editable in the Wagtail admin. Snippets are models which do not inherit the ``Page`` class and are thus not organized into the Wagtail tree, but can still be made editable by assigning panels and identifying the model as a snippet with ``register_snippet()``.
|
||||
|
||||
Snippets are not searchable or orderable in the Wagtail admin, so decide carefully if the content type you would want to build into a snippet might be more suited to a page.
|
||||
|
||||
Snippet Models
|
||||
--------------
|
||||
|
||||
Here's an example snippet from the Wagtail demo website:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.db import models
|
||||
|
||||
from wagtail.wagtailadmin.edit_handlers import FieldPanel
|
||||
from wagtail.wagtailsnippets.models import register_snippet
|
||||
|
||||
...
|
||||
|
||||
class Advert(models.Model):
|
||||
url = models.URLField(null=True, blank=True)
|
||||
text = models.CharField(max_length=255)
|
||||
|
||||
panels = [
|
||||
FieldPanel('url'),
|
||||
FieldPanel('text'),
|
||||
]
|
||||
|
||||
def __unicode__(self):
|
||||
return self.text
|
||||
|
||||
register_snippet(Advert)
|
||||
|
||||
The ``Advert`` model uses the basic Django model class and defines two properties: text and url. The editing interface is very close to that provided for ``Page``-derived models, with fields assigned in the panels property. Snippets do not use multiple tabs of fields, nor do they provide the "save as draft" or "submit for moderation" features.
|
||||
|
||||
``register_snippet(Advert)`` tells Wagtail to treat the model as a snippet. The ``panels`` list defines the fields to show on the snippet editing page. It's also important to provide a string representation of the class through ``def __unicode__(self):`` so that the snippet objects make sense when listed in the Wagtail admin.
|
||||
|
||||
Including Snippets in Template Tags
|
||||
-----------------------------------
|
||||
|
||||
The simplest way to make your snippets available to templates is with a template tag. This is mostly done with vanilla Django, so perhaps reviewing Django's documentation for `django custom template tags`_ will be more helpful. We'll go over the basics, though, and make note of any considerations to make for Wagtail.
|
||||
|
||||
First, add a new python file to a ``templatetags`` folder within your app. The demo website, for instance uses the path ``wagtaildemo/demo/templatetags/demo_tags.py``. We'll need to load some Django modules and our app's models and ready the ``register`` decorator:
|
||||
|
||||
.. _django custom template tags: https://docs.djangoproject.com/en/dev/howto/custom-template-tags/
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django import template
|
||||
from demo.models import *
|
||||
|
||||
register = template.Library()
|
||||
|
||||
...
|
||||
|
||||
# Advert snippets
|
||||
@register.inclusion_tag('demo/tags/adverts.html', takes_context=True)
|
||||
def adverts(context):
|
||||
return {
|
||||
'adverts': Advert.objects.all(),
|
||||
'request': context['request'],
|
||||
}
|
||||
|
||||
``@register.inclusion_tag()`` takes two variables: a template and a boolean on whether that template should be passed a request context. It's a good idea to include request contexts in your custom template tags, since some Wagtail-specific template tags like ``pageurl`` need the context to work properly. The template tag function could take arguments and filter the adverts to return a specific model, but for brevity we'll just use ``Advert.objects.all()``.
|
||||
|
||||
Here's what's in the template used by the template tag:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% for advert in adverts %}
|
||||
<p>
|
||||
<a href="{{ advert.url }}">
|
||||
{{ advert.text }}
|
||||
</a>
|
||||
</p>
|
||||
{% endfor %}
|
||||
|
||||
Then in your own page templates, you can include your snippet template tag with:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% block content %}
|
||||
|
||||
...
|
||||
|
||||
{% adverts %}
|
||||
|
||||
{% endblock %}
|
||||
|
||||
Binding Pages to Snippets
|
||||
-------------------------
|
||||
|
||||
An alternate strategy for including snippets might involve explicitly binding a specific page object to a specific snippet object. Lets add another snippet class to see how that might work:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.db import models
|
||||
|
||||
from wagtail.wagtailcore.models import Page
|
||||
from wagtail.wagtailadmin.edit_handlers import PageChooserPanel
|
||||
from wagtail.wagtailsnippets.models import register_snippet
|
||||
from wagtail.wagtailsnippets.edit_handlers import SnippetChooserPanel
|
||||
|
||||
from modelcluster.fields import ParentalKey
|
||||
|
||||
...
|
||||
|
||||
class AdvertPlacement(models.Model):
|
||||
page = ParentalKey('wagtailcore.Page', related_name='advert_placements')
|
||||
advert = models.ForeignKey('demo.Advert', related_name='+')
|
||||
|
||||
class Meta:
|
||||
verbose_name = "Advert Placement"
|
||||
verbose_name_plural = "Advert Placements"
|
||||
|
||||
panels = [
|
||||
PageChooserPanel('page'),
|
||||
SnippetChooserPanel('advert', Advert),
|
||||
]
|
||||
|
||||
def __unicode__(self):
|
||||
return self.page.title + " -> " + self.advert.text
|
||||
|
||||
register_snippet(AdvertPlacement)
|
||||
|
||||
The class ``AdvertPlacement`` has two properties, ``page`` and ``advert``, which point to other models. Wagtail provides a ``PageChooserPanel`` and ``SnippetChooserPanel`` to let us make painless selection of those properties in the Wagtail admin. Note also the ``Meta`` class, which you can stock with the ``verbose_name`` and ``verbose_name_plural`` properties to override the snippet labels in the Wagtail admin. The text representation of the class has also gotten fancy, using both properties to construct a compound label showing the relationship it forms between a page and an Advert.
|
||||
|
||||
With this snippet in place, we can use the reverse ``related_name`` lookup label ``advert_placements`` to iterate over any placements within our template files. In the template for a ``Page``-derived model, we could include the following:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% if self.advert_placements %}
|
||||
{% for advert_placement in self.advert_placements.all %}
|
||||
<p><a href="{{ advert_placement.advert.url }}">{{ advert_placement.advert.text }}</a></p>
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
||||
|
||||
|
|
@ -1,7 +1,226 @@
|
|||
Search
|
||||
======
|
||||
|
||||
Wagtail can degrade to a database-backed text search, but we strongly recommend `Elasticsearch`_. If you prefer not to run an Elasticsearch server in development or production, there are many hosted services available, including `Searchly`_, who offer a free account suitable for testing and development. To use Searchly:
|
||||
Wagtail provides a very comprehensive, extensible, and flexible search interface. In addition, it provides ways to promote search results through "Editor's Picks." Wagtail also collects simple statistics on queries made through the search interface.
|
||||
|
||||
Default Page Search
|
||||
-------------------
|
||||
|
||||
Wagtail provides a default frontend search interface which indexes the ``title`` field common to all ``Page``-derived models. Lets take a look at all the components of the search interface.
|
||||
|
||||
The most basic search functionality just needs a search box which submits a request. Since this will be reused throughout the site, lets put it in ``mysite/includes/search_box.html`` and then use ``{% include ... %}`` to weave it into templates:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
<form action="{% url 'wagtailsearch_search' %}" method="get">
|
||||
<input type="text" name="q"{% if query_string %} value="{{ query_string }}"{% endif %}>
|
||||
<input type="submit" value="Search">
|
||||
</form>
|
||||
|
||||
The form is submitted to the url of the ``wagtailsearch_search`` view, with the search terms variable ``q``. The view will use its own (very) basic search results template.
|
||||
|
||||
Lets use our own template for the results, though. First, in your project's ``settings.py``, define a path to your template:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
WAGTAILSEARCH_RESULTS_TEMPLATE = 'mysite/search_results.html'
|
||||
|
||||
Next, lets look at the template itself:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% extends "mysite/base.html" %}
|
||||
{% load pageurl %}
|
||||
|
||||
{% block title %}Search{% if search_results %} Results{% endif %}{% endblock %}
|
||||
|
||||
{% block search_box %}
|
||||
{% include "mysite/includes/search_box.html" with query_string=query_string only %}
|
||||
{% endblock %}
|
||||
|
||||
{% block content %}
|
||||
<h2>Search Results{% if request.GET.q %} for {{ request.GET.q }}{% endif %}</h2>
|
||||
<ul>
|
||||
{% for result in search_results %}
|
||||
<li>
|
||||
<h4><a href="{% pageurl result.specific %}">{{ result.specific }}</a></h4>
|
||||
{% if result.specific.search_description %}
|
||||
{{ result.specific.search_description|safe }}
|
||||
{% endif %}
|
||||
</li>
|
||||
{% empty %}
|
||||
<li>No results found</li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endblock %}
|
||||
|
||||
The search view provides a context with a few useful variables.
|
||||
|
||||
``query_string``
|
||||
The terms (string) used to make the search.
|
||||
|
||||
``search_results``
|
||||
A collection of Page objects matching the query. The ``specific`` property of ``Page`` will give the most-specific subclassed model object for the Wagtail page. For instance, if an ``Event`` model derived from the basic Wagtail ``Page`` were included in the search results, you could use ``specific`` to access the custom properties of the ``Event`` model (``result.specific.date_of_event``).
|
||||
|
||||
``is_ajax``
|
||||
Boolean. This returns Django's ``request.is_ajax()``.
|
||||
|
||||
``query``
|
||||
A Wagtail ``Query`` object matching the terms. The ``Query`` model provides several class methods for viewing the statistics of all queries, but exposes only one property for single objects, ``query.hits``, which tracks the number of time the search string has been used over the lifetime of the site. ``Query`` also joins to the Editor's Picks functionality though ``query.editors_picks``. See :ref:`editors-picks`.
|
||||
|
||||
Editor's Picks
|
||||
--------------
|
||||
|
||||
Editor's Picks are a way of explicitly linking relevant content to search terms, so results pages can contain curated content instead of being at the mercy of the search algorithm. In a template using the search results view, editor's picks can be accessed through the variable ``query.editors_picks``. To include editor's picks in your search results template, use the following properties.
|
||||
|
||||
``query.editors_picks.all``
|
||||
This gathers all of the editor's picks objects relating to the current query, in order according to their sort order in the Wagtail admin. You can then iterate through them using a ``{% for ... %}`` loop. Each editor's pick object provides these properties:
|
||||
|
||||
``editors_pick.page``
|
||||
The page object associated with the pick. Use ``{% pageurl editors_pick.page %}`` to generate a URL or provide other properties of the page object.
|
||||
|
||||
``editors_pick.description``
|
||||
The description entered when choosing the pick, perhaps explaining why the page is relevant to the search terms.
|
||||
|
||||
Putting this all together, a block of your search results template displaying Editor's Picks might look like this:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
{% with query.editors_picks.all as editors_picks %}
|
||||
{% if editors_picks %}
|
||||
<div class="well">
|
||||
<h3>Editors picks</h3>
|
||||
<ul>
|
||||
{% for editors_pick in editors_picks %}
|
||||
<li>
|
||||
<h4>
|
||||
<a href="{% pageurl editors_pick.page %}">
|
||||
{{ editors_pick.page.title }}
|
||||
</a>
|
||||
</h4>
|
||||
<p>{{ editors_pick.description|safe }}</p>
|
||||
</li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</div>
|
||||
{% endif %}
|
||||
{% endwith %}
|
||||
|
||||
Asyncronous Search with JSON and AJAX
|
||||
-------------------------------------
|
||||
|
||||
Wagtail's provides JSON search results when queries are made to the ``wagtailsearch_suggest`` view. To take advantage of it, we need a way to make that URL available to a static script. Instead of hard-coding it, lets set a global variable in our ``base.html``:
|
||||
|
||||
.. code-block:: django
|
||||
|
||||
<script>
|
||||
var wagtailJSONSearchURL = "{% url 'wagtailsearch_suggest' %}";
|
||||
</script>
|
||||
|
||||
Lets also add a simple interface for the search with a ``<input>`` element to gather search terms and a ``<div>`` to display the results:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<div>
|
||||
<h3>Search</h3>
|
||||
<input id="json-search" type="text">
|
||||
<div id="json-results"></div>
|
||||
</div>
|
||||
|
||||
Finally, we'll use JQuery to make the aynchronous requests and handle the interactivity:
|
||||
|
||||
.. code-block:: guess
|
||||
|
||||
$(function() {
|
||||
|
||||
// cache the elements
|
||||
var searchBox = $('#json-search'),
|
||||
resultsBox = $('#json-results');
|
||||
// when there's something in the input box, make the query
|
||||
searchBox.on('input', function() {
|
||||
if( searchBox.val() == ''){
|
||||
resultsBox.html('');
|
||||
return;
|
||||
}
|
||||
// make the request to the Wagtail JSON search view
|
||||
$.ajax({
|
||||
url: wagtailJSONSearchURL + "?q=" + searchBox.val(),
|
||||
dataType: "json"
|
||||
})
|
||||
.done(function(data) {
|
||||
console.log(data);
|
||||
if( data == undefined ){
|
||||
resultsBox.html('');
|
||||
return;
|
||||
}
|
||||
// we're in business! let's format the results
|
||||
var htmlOutput = '';
|
||||
data.forEach(function(element, index, array){
|
||||
htmlOutput += '<p><a href="' + element.url + '">' + element.title + '</a></p>';
|
||||
});
|
||||
// and display them
|
||||
resultsBox.html(htmlOutput);
|
||||
})
|
||||
.error(function(data){
|
||||
console.log(data);
|
||||
});
|
||||
});
|
||||
|
||||
});
|
||||
|
||||
Results are returned as a JSON object with this structure:
|
||||
|
||||
.. code-block:: guess
|
||||
|
||||
{
|
||||
[
|
||||
{
|
||||
title: "Lumpy Space Princess",
|
||||
url: "/oh-my-glob/"
|
||||
},
|
||||
{
|
||||
title: "Lumpy Space",
|
||||
url: "/no-smooth-posers/"
|
||||
},
|
||||
...
|
||||
]
|
||||
}
|
||||
|
||||
What if you wanted access to the rest of the results context or didn't feel like using JSON? Wagtail also provides a generalized AJAX interface where you can use your own template to serve results asyncronously.
|
||||
|
||||
The AJAX interface uses the same view as the normal HTML search, ``wagtailsearch_search``, but will serve different results if Django classifies the request as AJAX (``request.is_ajax()``). Another entry in your project settings will let you override the template used to serve this response:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
WAGTAILSEARCH_RESULTS_TEMPLATE_AJAX = 'myapp/includes/search_listing.html'
|
||||
|
||||
In this template, you'll have access to the same context variablies provided to the HTML template. You could provide a template in JSON format with extra properties, such as ``query.hits`` and editor's picks, or render an HTML snippet that can go directly into your results ``<div>``. If you need more flexibility, such as multiple formats/templates based on differing requests, you can set up a custom search view.
|
||||
|
||||
.. _editors-picks:
|
||||
|
||||
|
||||
Indexing Custom Fields & Custom Search Views
|
||||
--------------------------------------------
|
||||
|
||||
This functionality is still under active development to provide a streamlined interface, but take a look at ``wagtail/wagtail/wagtailsearch/views/frontend.py`` if you are interested in coding custom search views.
|
||||
|
||||
|
||||
Search Backends
|
||||
---------------
|
||||
|
||||
Wagtail can degrade to a database-backed text search, but we strongly recommend `Elasticsearch`_.
|
||||
|
||||
.. _Elasticsearch: http://www.elasticsearch.org/
|
||||
|
||||
|
||||
Default DB Backend
|
||||
``````````````````
|
||||
The default DB search backend uses Django's ``__icontains`` filter.
|
||||
|
||||
|
||||
Elasticsearch Backend
|
||||
`````````````````````
|
||||
If you prefer not to run an Elasticsearch server in development or production, there are many hosted services available, including `Searchly`_, who offer a free account suitable for testing and development. To use Searchly:
|
||||
|
||||
- Sign up for an account at `dashboard.searchly.com/users/sign\_up`_
|
||||
- Use your Searchly dashboard to create a new index, e.g. 'wagtaildemo'
|
||||
|
|
@ -10,6 +229,9 @@ Wagtail can degrade to a database-backed text search, but we strongly recommend
|
|||
your local settings
|
||||
- Run ``./manage.py update_index``
|
||||
|
||||
.. _Elasticsearch: http://www.elasticsearch.org/
|
||||
.. _Searchly: http://www.searchly.com/
|
||||
.. _dashboard.searchly.com/users/sign\_up: https://dashboard.searchly.com/users/sign_up
|
||||
.. _dashboard.searchly.com/users/sign\_up: https://dashboard.searchly.com/users/sign_up
|
||||
|
||||
Rolling Your Own
|
||||
````````````````
|
||||
Wagtail search backends implement the interface defined in ``wagtail/wagtail/wagtailsearch/backends/base.py``. At a minimum, the backend's ``search()`` method must return a collection of objects or ``model.objects.none()``. For a fully-featured search backend, examine the Elasticsearch backend code in ``elasticsearch.py``.
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue