Server issue Threads with over 50 chars in lenght turn invisible

Floren

Floren

Well-known member
Update: This is indeed a PCRE bug, Jake was right.

This started on the assumption certain keywords make the thread title go blank.
After further testing, the issue is related to the number of chars present into thread title. For some reason the node title limit (50 chars) gets somehow intersected with the thread title, only when you view the thread list and only into thread title (compare line 327 with 333):

IMG_27092012_212515.webp

I created a live demonstration of this nasty bug, you can follow the original thread also.
Server setup: CentOS 6 64bits minimal install with Nginx 1.2.2, PHP 5.3.17 and MariaDB 5.2.12

Please do not state that you cannot replicate this issue, because is there. Others users reported the same behaviour on their servers.
 
I don't have this problem on my forum but...

Admin CP -> Appearance -> Templates -> thread_list_item

The title is word wrapped at 50 characters:

Code: 
{xen:helper wrap, $thread.title, 50}

That does some string processing including a call to preg_replace(). I have seen regex functions like this fail as a result of buggy PCRE libraries. Visit admin.php?tools/phpinfo to see what PCRE version is being used. I suggest upgrading your PCRE version to see if that fixes the problem. There are newer versions of PCRE bundled with newer versions of PHP:

http://php.net/manual/en/pcre.installation.php
 
Jake Bunce said:
There are newer versions available. Try upgrading.
Click to expand...
Based on my experience, it is not related to that. One thing is sure, this issue made surface in 1.1.3, 1.1.2 is OK.
I'm going to setup 2 test forums (1.1.2 and 1.1.3) on one of my dev servers and let you know. Logging into my life server is pretty hard due to security features implemented.
 
I've just tried this, and I'm running PCRE 8.21 and I don't have suhosin compiled. It doesn't make the thread turn invisible on my site.
 
I can't reproduce this bug.

In library/XenForo/Helper/String, find:
PHP: 
return preg_replace('#[^\s]{' . $breakLength . '}(?=[^\s])#u', '$0  ', $string);
Add add before:
PHP: 
return substr(trim($string), 0, $breakLength);
Does it working ?
 
Insy said:
Add add before:
PHP: 
return substr(trim($string), 0, $breakLength);
Does it working ?
Click to expand...
It does work but now it cuts the extra chars:
Code: 
	public static function wordWrapString($string, $breakLength)
	{
		$breakLength = intval($breakLength);
		if ($breakLength < 1 || $breakLength > strlen($string)) // strlen isn't completely accurate, but this is an optimization
		{
			return $string;
		}
		return substr(trim($string), 0, $breakLength);
	}

This is how it looks with the new code inserted:

IMG_14102012_183133.webp IMG_14102012_183145.webp
 
Technically, the title "This is a random thread title with over fifty characters in length" is reduced to 50 chars and displays as "This is a random thread title with over fifty char". This is definitely not related to PCRE.
 
Floren said:
Technically, the title "This is a random thread title with over fifty characters in length" is reduced to 50 chars and displays as "This is a random thread title with over fifty char". This is definitely not related to PCRE.
Click to expand...
Actually if the code Insy posted is working, which would return before the preg_replace, it could indicate the problem is on that line, no? I don't understand how you can rule out PCRE?

Create a test file:
PHP: 
<?php
 
function wordWrapString($string, $breakLength)
{
    $breakLength = intval($breakLength);
    if ($breakLength < 1 || $breakLength > strlen($string)) // strlen isn't completely accurate, but this is an optimization
    {
        return $string;
    }
 
    return preg_replace('#[^\s]{' . $breakLength . '}(?=[^\s])#u', '$0  ', $string);
}
 
$string = 'ThisIsAStringWhereThereAreLotsOfWordsWithNoSpaces';
$breakLength = 10;
 
echo wordWrapString($string, $breakLength);
.. and run it.

If the output is not exactly:
Code: 
ThisIsAStr ingWhereTh ereAreLots OfWordsWit hNoSpaces


.. then the problem definitely lies somewhere in the preg_replace, which would definitely indicate a PCRE bug, or a problem with the regular expression itself. It's one or the other.
 
Jake... I apologize, you were right. (y)
Jeremy... many thanks for your test idea, it was a PCRE bug:
PHP Warning: preg_replace(): Compilation failed: unknown option bit(s) set at offset 0 in /var/www/axivo.com/test.php on line 11
Click to expand...

I've made an rpm quickly for PCRE 8.21 and once I upgraded the version, the problem was solved. :eek:
PCRE 8.3x will break things in CentOS 6, stay away from it and use 8.21 instead.
I uploaded the rpm into Axivo repository, so others who run on CentOS 6 can fix it easy also:
# yum --enablerepo=axivo update pcre
Click to expand...
The issue does not make surface on CentOS 5 and PCRE 6.6 version.
 
Top Bottom