Recent Topics

1 Aug 11, 2006 17:22    

I'm running b2evo 1.8-beta. A visitors tries to leave a comment and all it is published is the number "1047". He tries again, and it happens the same. "1047" is the post_ID of the post he was trying to comment on.

So I try to investigate the issue, check the "evo_comments" table, and both comments have a "comment_karma" of "0" and "comment_spam_karma" NULL, as the rest of the comments. I suspect, his comments were somehow rejected by the antispam system, but I don't exactly why. Is there a way to know how adn why a given comment is rejected?

2 Aug 13, 2006 20:24

If comment karma is -100 or below then the comment is rejected, does the comment's text in the database apear as the comment id as well? or only when the comment is displayed.

I would imagine this would be a problem with the submission or displaying of the comment, not a spam issue.

3 Aug 14, 2006 00:10

I checked in the database, and the content of the comment is the post_ID.

4 Aug 14, 2006 09:33

Have you made any modifications to the core of b2evolution, and are you sure your skin is compatiable with the 1.8 release...

If it is a clean install with a compatiable skin, then turn debuging in /conf/advanced.php to 2, then post any relevant debug information here, and we will try solve it.

5 Aug 22, 2006 15:48

Hi, I've changed a couple of things:

  • In conf/_advanced I changed the $htsrv_subdir trying to avoid trackback spam.

  • I added a couple of search engines in conf/_stats.php

  • I changed line 934 in inc/MODEL/items/_item.class.php from

    '<a href="'.$this->get_permanent_url( 'pid', $more_file ).'#more'.$this->ID.'">'.

    to

    '<a href="'.$this->get_permanent_url( '', $more_file ).'#more'.$this->ID.'">'.

  • Also in inc/MODEL/items/_item.class.php I changed the string "trackback.php" to "referencia.php" also trying to avoid trackback spam.

  • The previous_post() and next_post() functions defined in inc/MODEL/items/_item.funcs.php where changed to include modifications as described [url=http://forums.b2evolution.net/viewtopic.php?p=41378]here[/url]

  • In inc/_misc/_ping.funcs.php I substituted weblogs.com by another blog directory

  • [/list:u] Those are all the changes I've made. I enabled debuging as you say. The problem is that I don't know how to reproduce the error, because the problematic comments don't arrive, only the post_ID. I have the captcha and the Googlespell plugin enabled. In one case, the person left a comment, all in Uppercase letters, this comment passed fine and was published, then 6 and 8 minutes later (from the first comment), this person's comments were published only as the post_ID (622). I tried to post comments then using the same name, webpage, e-mail and message very quickly with 8, 6 and 2 minutes difference between them, and they all pass and get published. I do get an error all the time:

    Could not "SET NAMES latin1"!

    That's everything I can say now. In the meantime I guess I will require registration, because AFIK registered members don't have this problem.

6 Sep 05, 2006 22:04

I'm using 1.8.1 and the problem persists. But now I've found a pattern. If you send a comment from a page with a URL like this: http://liberal-venezolano.net/blog/index.php/2006/09/05/es_estonia_no_francia or http://liberal-venezolano.net/blog/?title=es_estonia_no_francia&c=1 (They are the same post), the comment is accepted normaly.

However if you send a comment from a page with a URL like this http://liberal-venezolano.net/blog/?p=1071&c=1 (again, the same post) the comment content is substituted by the post_ID, in this example "1071".

7 Sep 06, 2006 00:10

Good catch, Austriaco!

The problem is, that the comment form now uses one-letter names for the fields and "p" for the comment's content.

The comment gets POSTed, but the param from GET (?p=1071) overrides it.

Try disabling "register_globals" in php.ini or with

ini_set( 'register_globals', 'off' );

in e.g. /conf/_basic_config.php.

However, it's very bad behaviour IMHO to use those one-char params for the comment fields in the first place and then also duplicating names that already get used..

François once told me, that the one-char solution for the form fields is a temporary solution, so this might get fixed in 2.0.

9 Sep 06, 2006 10:41

blueyed wrote:

Try disabling "register_globals" in php.ini or with

ini_set( 'register_globals', 'off' );

in e.g. /conf/_basic_config.php.

I tried this in con/_basc_config.php (I'm in a shared host environment, so I suppose I cannot modify "register_globals" in php.ini), but the problem still persists :-(. Maybe changing the parameter name "p" and use another one, for instance 'comment_content'. What files should I modify to accomplish this?

BTW it seems strange that nobody else has reported this behavior. Maybe not so many people using 1.8 yet?

Update: I also tried the following in my .htaccess from the sample.htaccess shipped with the distribution:

# this will make register globals off in b2's directory
# just put a '#' sign before these three lines if you don't want that
<IfModule mod_php4.c>
php_flag register_globals off
</IfModule>

But to no avail.

10 Sep 06, 2006 11:02

Now it seems to be working. I changed the name of the "p" parameter in the comment form:

In ./skins/<skinname/_feedback.php, substitute "comment_content" (or whatever you like, I guess that if everybody uses different field names, spammers would have a hard time) for "p" in the first parameter to $Form->textarea():

// Message field:
                $Form->textarea( 'comment_content', $comment_content, 10, T_('Comment text'),
                                                                                T_('Allowed XHTML tags').': '.htmlspecialchars(str_replace( '>
<',', ', $comment_allowed_tags)), 40, 'bComment' );

And in $htsrv/comment_post do the same, in the first parameter to param():

$comment = param( 'comment_content', 'html' );

This works for me, at least for the moment.

11 Sep 24, 2006 22:47

Austriaco, setting register_globals does not work with ini_set(), because it is too late for autoregistering the globals then. So this is why it did not make any difference.

There's another report of the problem here: http://forums.b2evolution.net//viewtopic.php?t=9356&start=0&postdays=0&postorder=asc&highlight=

I've investigated further in it, but cannot reproduce it.. apparently there should be only one param "p", no additional GET param with the ID (as I've said above).

Austriaco, did this happen always on your installation or only sometimes, as reported in the other post?

12 Sep 24, 2006 22:51

Does this also happen when previewing the comment (Preview button)?

13 Sep 24, 2006 23:29

Austriaco, can you please try the following to help debugging this:
- add "p" as a field to the comment form again, as a hidden field in your _feedback.php:


$Form->hidden( 'p', '12345' );

- And then put the following code into /htsrv/comment_post.php:

At the beginning, after


require_once dirname(__FILE__).'/../conf/_config.php';


add:


if( $_POST['comment_content'] == 'debugtest' )
{
  $debug = 1;
}

Add:


if( $comment == 'debugtest' )
{
	phpinfo();
	debug_die();
}


before the two occurences of


header_nocache();
header_redirect();


in this file.

If you do not want to have the test comments inserted into DB, replace


$Comment->dbinsert();


with


if( $comment != 'debugtest' )
  $Comment->dbinsert();

So, now if you enter "debugtest" as comment data, it enables debugging and outputs phpinfo() and the Debuglog, instead of redirecting.

If you have it setup like this, please let me know, so I can test it.

Your blog should keep behaving like before, only "debugtest" as comment triggers the debugging.

14 Sep 24, 2006 23:32

Silencer, if you want to help with setting up the above debug-setup (or anyone else experiencing this problem), you have to modify the instructions a bit:
- do not add the hidden "p" field
- Instead of "if( $_POST['comment_content'] == 'debugtest' )" use "if( $_POST['p'] == 'debugtest' )"

15 Nov 15, 2006 00:34

I've probably found the cause of the error:
the captcha image plugin.

It adds a list of all $_REQUEST vars as hidden fields to the form, and if you access the feedback form with "p=X" (X being the post ID), there will be two fields in the form named "p": the post ID and the comment text. Now add some random browser/server interpretation of two input fields and you've got a nasty bug.

I've released a fixed captcha plugin: https://sourceforge.net/project/showfiles.php?group_id=160495&package_id=196745


Form is loading...