comment: 2 sets the body of comment as 2
rmyoung - February 21, 2008 - 11:11
| Project: | Mailhandler |
| Version: | 6.x-1.5 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
If you have
comment: 2
in the mailhandler commands as suggested in the readme.txt the only content that is displayed in the comments imported by listhandler is 2
If you just leave that command out the comment is put into the forum but the comment which has been created can't be commented on. ie. only the original post can be commented on.

#1
Hi Matt,
I put
comment:2in the instructions after browsing the mailhandler documentation and doing a few tests. I swear that I have comment:2 in my test mailing lists, but I can't check right now.
Can you try amending the code as suggested in point 3 of the post
http://drupal.org/project/listhandler#comment-286464 ?
It sound exactly like your problem.
I never noticed any change when I tried that and I never heard a response from the poster when I asked - but maybe I just didn't test all cases.
Thanks.
P.
#2
I had the same issue and this fix worked for me.
Works perfect now.
#3
I can confirm that changing the mailhandler.module as suggested does resolve this issue. I found the instructions in the post above a little confusing so here is what needs to be done:
edit the mailhandler.module file.
Find the "create the comment" section (about line 120)
Remove the following line:
if (!$node->comment) $node->comment = $node->body;And replace it with the following lines:
// We dont want the node's comment setting to be the body of the comment.if (!$node->comment or preg_match('/^\d$/', $node->comment))
$node->comment = $node->body;
#4
I also had the same problem and the code above fixed it for me, too. Maybe this should be categorized as a Mailhandler bug since that's where the fix is???
#5
I've posted a patch to Mailhandler: #232502: Command "comment: 2" sets the comment content to "2" but will leave this as 9 times out of 10 people will go searching here for answers.
Until Mailhandler is updated you can either apply the patch below (applies against the latest dev and stable releases of MH) or remove "comment: 2" from the Default commands section and ensure that the content type used for forums allows comments.
Regards.
P.
#6
- I think that mailhandler issues should reside in the module's issue queue (I didn't notice at first sight that this started as a LISThandler issue...)
- I didn't succeed to reproduce the problem. Maybe it was already solved? I used the 5.x-1.3 version, and used both an inline comment command, as well as a default one. Both worked with no problems.
Please reopen the issue if it's still persistent.
#7
Reopening as this issue still persists. The above patch fixes the issue.
#8
Let's try to localize the problem.
I understand that you use listhandler. Can you, for the sake of testing, try to send a mail directly to your mailhandler address, with the above command, and report on results?
If you run into the same problem, using only mailhandler, please indicate how to reproduce the bug, and I'll try it.
#9
Yes I can reproduce this just using mailhandler. To reproduce:
set the default commands in the mailhandler configuration screen to
Send a message to the mailhandler address and a cc to yourself. Import the message using mailhandler and it imports as a node OK. Reply to the message you received as a cc and send it to the mailhandler address. Then import the message using mailhandler. The reply email imports as a comment on the node made from the first imported email with a correct title but the comment body is
So it seems that when the imported message is a new thread it imports fine as a new node but if it is a reply to a previous message (comment on a node) is it imported with a body of 2.
Hope that makes sense.
#10
I'm starting to understand the problem, but I need to investigate it more, since I'm afraid I found some other bugs (I'll report them if they prove to be bugs).
What happens is that you have the "comment: 2" as a *default command*, and it is prependded also when you post comments. Now, since the comment body is not called "body", but "comment", so this is what you get in the comment's body...
I'll try to come up with a solution. Thanks for the help, rmyoung!
#11
So now it works for me - I took out the comment command from the default commands, and set the nid of the newly created node:
nid: 49
type: comment
Body of comment to nid: 49
Maybe by modifying this line:
<?php if (!$node->comment) $node->comment = $node->body;?>to be just:
<?php $node->comment = $node->body;?>In function mailhandler_comment_submit, we can bypass this issue.
Still - I don't understand how you succeeded to send comments without specifying an nid in the mail's commands.
#12
I think that listhandler must generate the nid or cid and keep a record to maintain the threading.
I note that the readme.txt in listhandler no longer says to use this command so can I maybe I can just remove it. The readme.txt now reads
Where 123 is the numeric taxonomy id of the forum you created in step 4.
The line "status: 1" sets the created node/comment as published.
Should I remove the command
comment: 2or usetype: commentinstead? I always thought that 'type: comment' and 'comment: 2' behave differently but do they?#13
Hi There,
I left it in the Listhandler queue as the problem usually manifests when used with Listhandler, even though it's really a Mailhandler issue.
You're welcome to do with it what you want, but I've managed to lose visibility of the issue :-( so I don't what the current status of the problem is.
Some time ago I specifically removed the instructions in the Listhandler documentation which says: 'put "comment: 2" in the Mailhandler commands' as it stops users from logging calls about it.
If I remember, I will do a bit more investigation into this and read this thread in it's entirety, and then see in what ways (if any) it needs to go forward.
Cheers.
P.
#14
OK so now I figured it out.
comment: 2sets the node comments setting to 2 in the database ie. makes it read/write. This can be done by setting the comment setting for the content type ( if using listhandler the forum post content type) to read/write in admin/content/type so then this command (comment: 2) is not needed.type: commentis not the same. It would set the content type to a comment. This command is not needed when using listhandler as it determines what is a node and what is a comment. You only need to set it to publish and associate it with the forum using the tid as the updated readme.txt now says.#15
Sometime in the future I'll do some order in the documentation area. I'll make sure this goes in.
#16
This problem still seems to exist
I have comment: 2 set in my mailhandler so that a new article can be mailed in with comment enabled
However i am then unable to email in a comment for that node. It either doesn't work at all or I just get '2' in the body.
I am using the dev version of mailhandler
I was using;
nid: 1008
status: 1
comment: 2
and
nid: 1008
status: 1
type: comment
#17
Mee to having these issue (6.5) even i don't have set comment:2
any update?
#18
This issue also surface with Mail 2 Web and just as the patch suggests it has to do with ...
if (!$node->comment) $node->comment = $node->body;$node->comment has to do with the level of commenting allowed on the node - so 0,1,2 for none, read, read/write. Or at least when the node is first loaded. I have worked around this by explicitly setting...
$node->comment = $node->body;...in my code before it's handed back to mailhandler. This ensures that the body of the comment is set to what I want vice the number "2". Not sure it's anything but a hack since the $node->comment property should be 0,1, or 2. So we have a namespace conflict with the comment module when we use $node->comment to move the comment body around. Anyway...
Perhaps a better way to do this is to forgo the check and just set $node->comment to $node->body right before type casting to array and sending to $comment_save?
R,
Coby
#19
Please test the attached patch.
#21
Forgot to attach the patch
#22
Just wanted to note that z.stolar's patch in comment 21 solved the problem I was having.
#23
commited
#24
Automatically closed -- issue fixed for 2 weeks with no activity.