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.

Comments

chawl’s picture

Sorry, 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.

chawl’s picture

I 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.

Tip: In case of syntax error, check your PHP compability with your module or disable it (module: spam)
ERROR: Script execution halted with error: syntax error, unexpected $end
Backtrace: wsod_check_wsod(a:0:{})[?:?]

So, we use PHP 5.2.17 on a Centos 5.5 box.

AlexisWilke’s picture

Unexpected $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

gnassar’s picture

At 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?

AlexisWilke’s picture

I 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

AlexisWilke’s picture

Okay, 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.

      $action = _spam_filter_duplicate_action();
      if (is_array($action) && isset($action['redirect'])) {
        return $action['redirect'];
      }

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

AlexisWilke’s picture

StatusFileSize
new845 bytes

chawl,

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.

gnassar’s picture

Why 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?

AlexisWilke’s picture

gnassar,

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

gnassar’s picture

Category: bug » support

OK -- 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.

chawl’s picture

Category: support » bug
StatusFileSize
new207.74 KB

Wow! 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.

gnassar’s picture

Thank 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.

chawl’s picture

Yes "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.

chawl’s picture

Probably solved. I just added

spam_init();

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.

gnassar’s picture

Well, 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.

chawl’s picture

In 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 :)

gnassar’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Thanks, chawl. And good luck. :) I look forward to hearing your results.

chawl’s picture

Status: Postponed (maintainer needs more info) » Fixed

Ok, "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 :)

AlexisWilke’s picture

gnassar,

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

chawl’s picture

AlexisWilke’s picture

Ah! I don't use the latest version of the Like Button at this time... 8-) Maybe that's a big enough difference.

gnassar’s picture

Status: Fixed » Postponed (maintainer needs more info)

Well, 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.

avpaderno’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (outdated)

I am closing this issue, since it's for a Drupal version no longer supported.