Hello,
"Mark as spam" link on a comment gives WSOD, comment is not unpublished, but a spam log is created with a blank type, blank title, "99" score, "unpublished" status, and blank IP. Also as the entry has no check box to check, you can not delete the entry from the list, but from spam_tracker table manually.
Every time you click "mark as spam" (and got a WSOD), identical bogus entries pile up in the list.
Latest working revision is "1.51.4.1.2.41.2.30.2.29 2010/12/28 06:07:30", thus I downgraded to this.
We are on D6.20, and only Spam Duplicate Filter is enabled.
Tx for a great module by the way.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | module.list_.jpg | 207.74 KB | chawl |
| #7 | spam-6.x-duplicate_hide_redirect.patch | 845 bytes | AlexisWilke |
Comments
Comment #1
chawl commentedSorry, some corrections :/
First a typo, bogus entries have "not published" statuses, and a fudge, entries have had check boxes, but no actions can be applied to entries.
Tx in advance.
Comment #2
chawl commentedI dug up a bit more.
WSOD module logs nothing for the above error, "but", watchdog has many entries like the one below for completely irrelevant page calls (e.g. user/45, taxonomy/term/23, etc.), those have nothing to do with spam check.
So, we use PHP 5.2.17 on a Centos 5.5 box.
Comment #3
AlexisWilke commentedUnexpected $end usually means that it reached the end of a PHP script while still in a block. (i.e. if() { ... and no '}' found before EOF.)
It could be coming from your theme. Would you be able to test with Garland, to make sure?
Thank you.
Alexis Wilke
Comment #4
gnassar commentedAt the same time, nothing should be causing us to WSOD, really. So we need to narrow down if the WSOD is actually related to marking as spam or is a broader link problem.
Does marking a comment as spam from the comment admin page cause a WSOD also?
Does just unpublishing a comment not cause a WSOD?
Comment #5
AlexisWilke commentedI just tried with the latest 1.x-dev (as my version is different) and it worked just fine (no WSOD). Although the Duplicate module itself doesn't seem to react as I'd expect, but for that I'll do some more testing.
Thank you.
Alexis
Comment #6
AlexisWilke commentedOkay, I see that the mark as spam code ends with this code. It doesn't cause any problem to me, but I guess that's what you're experiencing. If the $action variable is set to the wrong URL, then it will fail with a WSOD.
Now, I have to find out why it would be wrong for you.
One question, to make: is the "Mark as spam" link you are clicking at the bottom right of the comment links?
Thank you.
Alexis
Comment #7
AlexisWilke commentedchawl,
Would you please try removing those 4 lines of code and test without them. If you still get the WSOD then it's probably due to another module.
Just in case, there is a patch with the code changes.
Thank you.
Alexis
P.S. This patch is only for test purposes, it is NOT to check in the CVS.
Comment #8
gnassar commentedWhy would this be the bit of code that's causing the problem, out of curiosity?
It actually seems to me that that that if() statement will actually never be true. Am I missing something?
Comment #9
AlexisWilke commentedgnassar,
That's the only thing I can see in the Spam module that would possibly affect the outcome of the click and generate a WSOD. But I don't foresee this removing the WSOD. But just in case, since I was not able to create a WSOD on my own systems...
Thank you.
Alexis
Comment #10
gnassar commentedOK -- do you have an answer for my second question? Because if I'm correct, that block of code can't affect the outcome at all.
chawl: Seems like right now we have 3 active questions that, if you answer for us, would help us track this down:
Would you be able to test with Garland, to make sure?
Does marking a comment as spam from the comment admin page cause a WSOD also?
Does just unpublishing a comment not cause a WSOD?
Marking as "support request" until this is replicable.
Comment #11
chawl commentedWow! Tx for your attention, I was busy sorry.
First of all, today's (10th Jan) latest dev causes WSOD also, but, if I only replace the newest "spam.module" file with the one from the rev."1.51.4.1.2.41.2.30.2.29 2010/12/28 06:07:30", everything works perfect again. So a change in this very file seems to cause smt.
I left the WSOD module enabled for two days together with the "working" Spam module revision and strangely I got some more log entries like in my previous post, but few of them mention (3/22) other modules also with same details, thus probably entries has nothing to do with the actual WSOD but only false warnings from some Apache-PHP effect. But I have no more errors on watchdog except these, not even one from other (plethora of) modules.
Now answers:
#3@AlexisWilke: Garland is not working also.
#4@gnassar: Marking as spam from admin page works perfectly. Unpublishing from admin page works perfectly.
#5@AlexisWilke: Disabling Duplicate Filter changes nothing.
#6@AlexisWilke: Yes, I am clicking the link under comment.
#7@AlexisWilke: Commenting those lines changed nothing.
I will check two versions of spam.module file with diff and will try to find a clue.
In fact ours is a rather busy and complicated site and if you check the attached module list, you can find why our case is a perfect crash test, and why I try not to claim Spam module directly.
Sure something is going haywire on our side. That's all I can report now.
Thank you.
Comment #12
gnassar commentedThank you!
Just to clarify:
When you say that 1.51.4.1.2.41.2.30.2.29 is the last working revision, does that mean that you've tried 1.51.4.1.2.41.2.30.2.30 and can verify it doesn't work?
edit -- You probably know this already, but just to have the link easily available, you can find the entire revision history for the spam.module file here:
http://drupalcode.org/viewvc/drupal/contributions/modules/spam/spam.modu...
Knowing exactly which is the last revision that works, and which is the first that breaks, would be very useful.
Comment #13
chawl commentedYes "Revision 1.51.4.1.2.41.2.30.2.30 - (view) (download) (as text) (annotate) - [select for diffs]" is perfectly working, rev.31 isn't.
Sorry for pasting, but I should clarify that I mean the rev # on the list, not the one on the file header.
Hope this helps, tx.
EDIT: I changed revision info, sorry for brief confusion.
Comment #14
chawl commentedProbably solved. I just added
to line 27 to the latest rev (Revision 1.51.4.1.2.41.2.30.2.36 - (view) (download) (as text) (annotate) - [select for diffs]) and voila!
Everything works perfectly again :)
Hope this helps. Tx.
Comment #15
gnassar commentedWell, that gets us a little closer to the problem. It probably means that some other module is conflicting with spam.module -- we just don't know which one yet.
Try this:
1) install http://drupal.org/project/util module; this will allow you to edit module weights
2) take note of the current module weight of spam.module, then set it to the lowest available weight (should be something like -99)
3) take out the spam_init() line you added in line 27.
I'm betting everything works okay.
If that is not the case, let me know and I'll continue to be baffled until I come up with something else. :)
If that is the case, then we are sure it's a module conflict -- some module was loading first, and "behaving badly" in a way that breaks spam.module when it tries to load. (Or perhaps vice versa -- maybe spam was doing something wrong!)
So the next step is to start moving spam.module upward in weight until you see the WSOD again, so we can narrow down your huge list of modules :) to figure out where the conflict is.
Comment #16
chawl commentedIn fact setting "-1" works, "0" fails.
Eventually 3/4 of the modules have weight 0, but I will try to assign weights and do some reorder tryouts.
Wish me luck :)
Comment #17
gnassar commentedThanks, chawl. And good luck. :) I look forward to hearing your results.
Comment #18
chawl commentedOk, "Facebook social plugins integration" module's, "Like Button" sub-module causes the problem.
I'm not sure now if FB module is properly installed, a hack/patch of it screwed up something or modules natively clash, therefore I'll check the other side.
Tx for marvellous support BTW :)
Comment #19
AlexisWilke commentedgnassar,
Should we add something in a Run-time Requirement to detect such problems? I've seen that in many other modules, I think that could be a good idea so we don't lose the knowledge and we can refer people to the admin/reports/status screen when they identify such problems.
We could also indicate how to fix the problem with a link to the documentation, for instance.
Now, I will have to test with another of my websites because I run the Like Button on one of them. I'd like to know whether I have the problem on that site too.
Thank you.
Alexis
Comment #20
chawl commentedFYI, #1022010: Like Button causes WSOD for Spam module
Tx.
Comment #21
AlexisWilke commentedAh! I don't use the latest version of the Like Button at this time... 8-) Maybe that's a big enough difference.
Comment #22
gnassar commentedWell, we should probably keep this open for a bit until we've figured out where exactly the fault lies.
Alexis, could you try the Like Button dev version and see if you can replicate the problem? Then if you drop back to the old version and don't have it anymore, we can pull a changeset to see what code specifically is causing the problem, and then see if it's because of something they did or something we did.
Comment #23
avpadernoI am closing this issue, since it's for a Drupal version no longer supported.