No way to utilize `next` parameter to redirect after comment deletion

[Dmitry Dzhus]

How is default «delete comment» view from new comments system meant to
get next argument (see contrib/comments/views/moderation.py)?

I think good way to do it is to support next GET request parameter, so
that one could use /delete/123/?next=/blog/entry/bla-blah as a link to
comment deletion page in order to redirect to page other than default
«deleted» view after actually removing the comment.

This works with «post comment» because next_redirect in post_comment function can see the next POST parameter in data. This does not work with «delete comment» because confirmation page is rendered first with next="None" in confirmation form.

[Dmitry Dzhus]

A simple patch to enable using next GET parameter with «delete comment» view

[Dmitry Dzhus]

A simple patch to enable using next GET parameter with «delete comment» view

[neithere]

The little change introduced in the existing patch should apply to all django.contrib.comments.moderation methods that expect the next argument (which simply can't be in the path as it's a path itself). These methods are approve(), delete() and flag().

I think that next=None should be removed from method signatures, too. In this case the next variable would be undefined in the POST handling code, so we should either get its value from POST or simply pass next=None to next_redirect() because the latter can get the same data itself.

Or did I miss something?

(By the way, a non-existent comment.permalink is used instead of the actual comment.get_absolute_url in source:django/trunk/django/contrib/comments/templates/comments/delete.html and friends. That's a bit off-topic though.)

[neithere]

This patch enables correct redirecting from moderation views by passing a next parameter via GET

[arne]

If a user decides to preview a comment before posting it, the next parameter is also lost. #9268 describes the problem, but wants to solve more than just passing the next parameter. Maybe this patch could be modified to also pass the next parameter for the preview view.

naive approach:

--- contrib/comments/views/comments.py
+++ contrib/comments/views/comments.py
@@ -80,6 +80,7 @@
template_list, {
"comment" : form.data.get("comment", ""),
"form" : form,
+ "next": data.get("next", None)
},
RequestContext(request, {})
)

[Kevin Kubasik]

I got this foo.

[Jacob]

There isn't a bug here. The next param is meant for people who want to wrap one of these views either with a custom URLconf like

    (r'^flag/(\d+)/$', flag, {'next': '/I/am/done/'})

or with a function that wraps the view. If it's not given, the next param will be pulled out of GET or POST (depending), so you can use an <input type=hidden name=next> in your HTML.

[Dmitri Fedortchenko <d@…>]

I still believe this is a shortcoming...

[Dmitri Fedortchenko <d@…>]

I still believe this is a shortcoming...

[Dmitri Fedortchenko <d@…>]

It's all good if you happen to stick a next param in a post form, but what if you want to post a link using javascript and include a next parameter as a get request? Then you're out of luck. It seems rather annoying to have to create a custom URLConf or application just to be able to redirect to a page of your choice...

I've tested it, and looked through the code, and the simple fact is that the next parameter is just not included unless you create your own POST form with the next hidden field.

If you try to use a standard get link with next in the query string, it will be lost, as well as if you use a "post link" with a little help of javascript.

I think the next parameter should always be fished out from both GET or POST. The patch I submitted does this, it also keeps the view argument as the dominant next param, and if there is a next in POST, it will be prioritized.

[Dmitri Fedortchenko <d@…>]

PS: I can't really see where next_redirect picks up the "next" parameter from GET, if I missed it, please point me in the right direction so I can hide in a corner.

[Kevin Kubasik]

Ok, I think I have enough tests proving this in the cases where it seems sane to me, but I understand that realistically I probably missed a few. This branch has the solution in it:
​http://github.com/kkubasik/django/tree/comment_redir

I have attached a patch as well.

[George Song]

The latest patch breaks the use case that Jacob cited above. I think we need to decided on the order of precedence here, as there are multiple places where next could come from: view arg, GET param, POST param. The following feels right to me:

• POST: POST param > GET param > view arg
• GET: GET param > view arg

If this is the case, we need to test and document accordingly.

[Kevin Kubasik]

Sounds good to me, if we want to utilize this inheritance order, then I'll implement it this week!

[Kevin Kubasik]

For the documentation needed, should it be in the main docs? Or just docstrings in the code?

[Alex Gaynor]

Docstrings are implementation. This is a public facing API which means real docs.

[Kevin Kubasik]

Updated Version of Kevins Patch. Still Needs Docs.

[Kevin Kubasik]

Docs, Tests and Code.

[Kevin Kubasik]

I should note that I chose to explicitly check GET then POST for readability over request.REQUEST. If there is a strong feeling towards changing this to REQUEST, that's not a problem, but I wanted to make sure it was known that the POST preference was explicit.

[James Bennett]

This isn't critical enough to get developer time before the 1.2 release; with luck we'll hit it in a 1.2.x bugfix release, or if not then in 1.3.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

django.contrib.comments has been deprecated and is no longer supported, so I'm closing this ticket. We're encouraging users to transition to a custom solution, or to a hosted solution like Disqus.

The code itself has moved to ​https://github.com/django/django-contrib-comments; if you want to keep using it, you could move this bug over there.