Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When a user with appropriate rights, tries to edit an anonymous comment, the following PDOexception is thrown:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'uid' cannot be null in comment_save() (line 739 of /var/www/home/d7/modules/comment/comment.module).
Problem lies in the fact that $edit['uid']
is NULL
when an anonymous comment is edited, which is not allowed by the current database scheme scheme. This can be fixed by forcing it to 0
when it is NULL
.
Patch attached does that, and also adds a test for editing anonymous comments, because apparently that was missing.
Comment | File | Size | Author |
---|---|---|---|
#10 | 334826-comment-form-uid-D6-rev2.patch | 1.58 KB | brianV |
#7 | 334826-comment-form-uid-D6.patch | 2.16 KB | Dave Reid |
#2 | 334826_broken_anonymous_comment_editing.patch | 2.32 KB | maartenvg |
edit_anonymous_comments.patch | 1.64 KB | maartenvg | |
Comments
Comment #1
cburschkaPlease see the similar problem in taxonomy: #332145: UNSTABLE-3 blocker: taxonomy_form_term_submit passes empty string as parent [dbtng conversion regression]
Looking at your patch, I'm wondering if it is possible to make the same improvement as in the other one, namely making sure the uid is 0 from the start rather than filtering it through empty() later on. If it isn't, I apologize (just set back to CNR).
Comment #2
maartenvg CreditAttribution: maartenvg commentedYou mean something like this?
This changes the default value of the FAPI variable to 0 instead of NULL. Unrelated to this bug but a consequence of the way this is solved, the empty()-check in comment_save() on inserting a comment is dropped.
Comment #3
catchPatch looks good, and the test runs well. I wonder how many more of these are lurking.
Comment #4
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Long live tests! :)
Comment #6
Dave ReidI ran into this bug today with 6.x. Will post a patch shortly.
Comment #7
Dave ReidComment #8
Dave ReidI found this in 6.x while using an override of preprocess_user_picture, which is called during preview in editing a comment. Before the patch, the $variables['account'] that is passed to template_preprocess_user_picture is the following:
And after the patch:
...which the above matches the same output in current D7 HEAD:
Comment #9
brianV CreditAttribution: brianV commentedLooks good, RTBC.
Comment #10
brianV CreditAttribution: brianV commentedErr, somehow overlooked that the final hunk (whitespace adjustment) didn't apply. Rerolled for D6, and tested appropriately.
Comment #11
Gábor HojtsyCommitted to Drupal 6, thank you!