'Login to post comments' does not work

I can't reproduce. If I am logged out. I see the user login block, but no "'Login or register to post comments" link.

This bug does seem to be consistently reproducible, both in my own site and on drupal.org.

As an example, go to the URL http://drupal.org/node/81557. Scroll past the initial post, and you'll see just above the first comment a line reading "login or register to post comments". Both the login and register links have %23 in them where there should be a #.

The login link in the above case is: http://drupal.org/user/login?destination=comment/reply/81557%2523comment...

i think i fixed the bug mentioned

unconed told me that the original "bug" was a workaround to a mod_rewrite bug so i think this should only be applied if necessary

patch details:
i started from that version: // $Id: comment.module,v 1.455.2.7 2006/07/18 10:46:24 unconed Exp $
i replace both occurances of "drupal_urlencode" with "urlencode"
done :)

this makes those login urls look a bit less nice but at least they work (for me :))

Well done TomyLobo, that fix appears to work.

If you look in the Drupal admin logs, you also found these errors prior to the fix being applied:
Type Date Message User Operations
php 02/09/2006 - 8:07pm You have an error in your SQL syntax; check the manual ... Guest
php 02/09/2006 - 8:07pm implode() [ Guest
php 02/09/2006 - 8:07pm Invalid argument supplied for foreach() in ... Guest

Thanks again.

It would seem the actual bug is that a #fragment should not be passed as part of a destination URL, because #fragments don't work in redirects. I've attached a patch to remove it.

Here's a corrected patch, there were two mentions of #comment_form in the module.

I apologize if the following question is inappropriate... I have a patch to resolve this issue but it's made against user.module, not comment.module. I believe it's a better solution as it preserves the fragment id. Is it proper to post that here or should I open a new issue on user.module (referencing this one) and post there?

Please feel free to post it here. I had no idea it was possible to preserve the fragment part of a URL thru a redirect, if so, cool!

Sorry for the delay, I was OBE. The attached patch is built for the DRUPAL-4-7 branch but will apply on DRUPAL-4-7-3 as well. I traced the problem to the destination URL in the query string being url encoded enough times that it then coudn't be parsed. This patch urldecodes it once before using it as the form action and it eliminates the problem for me.

I'm sorry and apologize for my ignorance.

How does one apply these patches?

moving to HEAD to get more reviews.

Pugs, after backing up your Drupal files and database follow the instructions here: http://drupal.org/node/60108

I can't recreate this with HEAD or 4.7.4 so I'm going to mark this fixed. Please reopen against the proper version with more information if I'm wrong.

What version is Drupal.org running? It's not fixed for that version.

Hi, I've just downloaded Drupal 4.7.4 and set it up with php 4.4.2 running on Linux 2.4 and I get exactly the same problem. Applying the patch to user.module supplied in one of the above comments fixes the issue.

I don't know if the problem affects all Drupal 4.7.4 installations, or only those running php 4.4.2, or whether there is something else which determines whether or not it happens. Admittedly the problem does not occur on Drupal.org, but I have found a live website running Drupal 4.7.4 where the problem can be seen:

http://beta.ivrpa.org/

This blog entry indicates that the site is running 4.7.4:

http://beta.ivrpa.org/node/657

To reproduce the problem, visit the above site, register an account, then find where it says "login or register to post comments", and login using that login link (not the ordinary login box). After you login you should be redirected back to the node you were commenting on, but instead you will get a page not found error.

As I mentioned the issue seems to be fixed by at least one of the patches available on this page. I think the fix should be incorporated into Drupal to resolve this issue.

this is apparenlty fixed in 4.7 HEAD as evidend here on drupal.org