django1/docs/ref/contrib/comments/index.txt

370 lines
12 KiB
Plaintext

===========================
Django's comments framework
===========================
.. module:: django.contrib.comments
:synopsis: Django's comment framework
.. highlightlang:: html+django
.. warning::
Django's comment framework has been deprecated and is no longer supported.
Most users will be better served with a custom solution, or a hosted
product like Disqus__.
The code formerly known as ``django.contrib.comments`` is `still available
in an external repository`__.
__ https://disqus.com/
__ https://github.com/django/django-contrib-comments
Django includes a simple, yet customizable comments framework. The built-in
comments framework can be used to attach comments to any model, so you can use
it for comments on blog entries, photos, book chapters, or anything else.
Quick start guide
=================
To get started using the ``comments`` app, follow these steps:
#. Install the comments framework by adding ``'django.contrib.comments'`` to
:setting:`INSTALLED_APPS`.
#. Run ``manage.py syncdb`` so that Django will create the comment tables.
#. Add the comment app's URLs to your project's ``urls.py``:
.. code-block:: python
urlpatterns = patterns('',
...
(r'^comments/', include('django.contrib.comments.urls')),
...
)
#. Use the `comment template tags`_ below to embed comments in your
templates.
You might also want to examine :ref:`the available settings
<settings-comments>`.
Comment template tags
=====================
You'll primarily interact with the comment system through a series of template
tags that let you embed comments and generate forms for your users to post them.
Like all custom template tag libraries, you'll need to :ref:`load the custom
tags <loading-custom-template-libraries>` before you can use them::
{% load comments %}
Once loaded you can use the template tags below.
Specifying which object comments are attached to
------------------------------------------------
Django's comments are all "attached" to some parent object. This can be any
instance of a Django model. Each of the tags below gives you a couple of
different ways you can specify which object to attach to:
#. Refer to the object directly -- the more common method. Most of the
time, you'll have some object in the template's context you want
to attach the comment to; you can simply use that object.
For example, in a blog entry page that has a variable named ``entry``,
you could use the following to load the number of comments::
{% get_comment_count for entry as comment_count %}.
#. Refer to the object by content-type and object id. You'd use this method
if you, for some reason, don't actually have direct access to the object.
Following the above example, if you knew the object ID was ``14`` but
didn't have access to the actual object, you could do something like::
{% get_comment_count for blog.entry 14 as comment_count %}
In the above, ``blog.entry`` is the app label and (lower-cased) model
name of the model class.
Displaying comments
-------------------
To display a list of comments, you can use the template tags
:ttag:`render_comment_list` or :ttag:`get_comment_list`.
.. templatetag:: render_comment_list
Quickly rendering a comment list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The easiest way to display a list of comments for some object is by using
:ttag:`render_comment_list`::
{% render_comment_list for [object] %}
For example::
{% render_comment_list for event %}
This will render comments using a template named ``comments/list.html``, a
default version of which is included with Django.
.. templatetag:: get_comment_list
Rendering a custom comment list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the list of comments for some object, use :ttag:`get_comment_list`::
{% get_comment_list for [object] as [varname] %}
For example::
{% get_comment_list for event as comment_list %}
{% for comment in comment_list %}
...
{% endfor %}
This returns a list of :class:`~django.contrib.comments.models.Comment` objects;
see :doc:`the comment model documentation </ref/contrib/comments/models>` for
details.
.. templatetag:: get_comment_permalink
Linking to comments
-------------------
To provide a permalink to a specific comment, use :ttag:`get_comment_permalink`::
{% get_comment_permalink comment_obj [format_string] %}
By default, the named anchor that will be appended to the URL will be the letter
'c' followed by the comment id, for example 'c82'. You may specify a custom
format string if you wish to override this behavior::
{% get_comment_permalink comment "#c%(id)s-by-%(user_name)s"%}
The format string is a standard python format string. Valid mapping keys
include any attributes of the comment object.
Regardless of whether you specify a custom anchor pattern, you must supply a
matching named anchor at a suitable place in your template.
For example::
{% for comment in comment_list %}
<a name="c{{ comment.id }}"></a>
<a href="{% get_comment_permalink comment %}">
permalink for comment #{{ forloop.counter }}
</a>
...
{% endfor %}
.. warning::
There's a `known bug`_ in Safari/Webkit which causes the named anchor to be
forgotten following a redirect. The practical impact for comments is that
the Safari/webkit browsers will arrive at the correct page but will not
scroll to the named anchor.
.. _`known bug`: https://bugs.webkit.org/show_bug.cgi?id=24175
.. templatetag:: get_comment_count
Counting comments
-----------------
To count comments attached to an object, use :ttag:`get_comment_count`::
{% get_comment_count for [object] as [varname] %}
For example::
{% get_comment_count for event as comment_count %}
<p>This event has {{ comment_count }} comments.</p>
Displaying the comment post form
--------------------------------
To show the form that users will use to post a comment, you can use
:ttag:`render_comment_form` or :ttag:`get_comment_form`
.. templatetag:: render_comment_form
Quickly rendering the comment form
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The easiest way to display a comment form is by using
:ttag:`render_comment_form`::
{% render_comment_form for [object] %}
For example::
{% render_comment_form for event %}
This will render comments using a template named ``comments/form.html``, a
default version of which is included with Django.
.. templatetag:: get_comment_form
Rendering a custom comment form
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want more control over the look and feel of the comment form, you may use
:ttag:`get_comment_form` to get a :doc:`form object </topics/forms/index>` that
you can use in the template::
{% get_comment_form for [object] as [varname] %}
A complete form might look like::
{% get_comment_form for event as form %}
<table>
<form action="{% comment_form_target %}" method="post">
{% csrf_token %}
{{ form }}
<tr>
<td colspan="2">
<input type="submit" name="submit" value="Post">
<input type="submit" name="preview" value="Preview">
</td>
</tr>
</form>
</table>
Be sure to read the `notes on the comment form`_, below, for some special
considerations you'll need to make if you're using this approach.
.. templatetag:: comment_form_target
Getting the comment form target
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may have noticed that the above example uses another template tag --
:ttag:`comment_form_target` -- to actually get the ``action`` attribute of the
form. This will always return the correct URL that comments should be posted to;
you'll always want to use it like above::
<form action="{% comment_form_target %}" method="post">
Redirecting after the comment post
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To specify the URL you want to redirect to after the comment has been posted,
you can include a hidden form input called ``next`` in your comment form. For example::
<input type="hidden" name="next" value="{% url 'my_comment_was_posted' %}" />
Providing a comment form for authenticated users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a user is already authenticated, it makes little sense to display the name,
email, and URL fields, since these can already be retrieved from their login
data and profile. In addition, some sites will only accept comments from
authenticated users.
To provide a comment form for authenticated users, you can manually provide the
additional fields expected by the Django comments framework. For example,
assuming comments are attached to the model "object"::
{% if user.is_authenticated %}
{% get_comment_form for object as form %}
<form action="{% comment_form_target %}" method="POST">
{% csrf_token %}
{{ form.comment }}
{{ form.honeypot }}
{{ form.content_type }}
{{ form.object_pk }}
{{ form.timestamp }}
{{ form.security_hash }}
<input type="hidden" name="next" value="{% url 'object_detail_view' object.id %}" />
<input type="submit" value="Add comment" id="id_submit" />
</form>
{% else %}
<p>Please <a href="{% url 'auth_login' %}">log in</a> to leave a comment.</p>
{% endif %}
The honeypot, content_type, object_pk, timestamp, and security_hash fields are
fields that would have been created automatically if you had simply used
``{{ form }}`` in your template, and are referred to in `Notes on the comment
form`_ below.
Note that we do not need to specify the user to be associated with comments
submitted by authenticated users. This is possible because the :doc:`Built-in
Comment Models</ref/contrib/comments/models>` that come with Django associate
comments with authenticated users by default.
In this example, the honeypot field will still be visible to the user; you'll
need to hide that field in your CSS::
#id_honeypot {
display: none;
}
If you want to accept either anonymous or authenticated comments, replace the
contents of the "else" clause above with a standard comment form and the right
thing will happen whether a user is logged in or not.
.. _notes-on-the-comment-form:
Notes on the comment form
-------------------------
The form used by the comment system has a few important anti-spam attributes you
should know about:
* It contains a number of hidden fields that contain timestamps, information
about the object the comment should be attached to, and a "security hash"
used to validate this information. If someone tampers with this data --
something comment spammers will try -- the comment submission will fail.
If you're rendering a custom comment form, you'll need to make sure to
pass these values through unchanged.
* The timestamp is used to ensure that "reply attacks" can't continue very
long. Users who wait too long between requesting the form and posting a
comment will have their submissions refused.
* The comment form includes a "honeypot_" field. It's a trap: if any data is
entered in that field, the comment will be considered spam (spammers often
automatically fill in all fields in an attempt to make valid submissions).
The default form hides this field with a piece of CSS and further labels
it with a warning field; if you use the comment form with a custom
template you should be sure to do the same.
The comments app also depends on the more general :doc:`Cross Site Request
Forgery protection </ref/contrib/csrf>` that comes with Django. As described in
the documentation, it is best to use ``CsrfViewMiddleware``. However, if you
are not using that, you will need to use the ``csrf_protect`` decorator on any
views that include the comment form, in order for those views to be able to
output the CSRF token and cookie.
.. _honeypot: http://en.wikipedia.org/wiki/Honeypot_(computing)
Configuration
=============
See :ref:`comment settings <settings-comments>`.
More information
================
.. toctree::
:maxdepth: 1
models
signals
custom
forms
moderation
example