WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9994 closed defect (bug) (fixed)

Only a blank page returned when access blog home page

Reported by: kamiyeye Owned by:
Milestone: 2.8 Priority: high
Severity: blocker Version: 2.8
Component: Formatting Keywords: reporter-feedback
Focuses: Cc:

Description

Pre-requisites

Wordpress 2.8 beta2 installed in a local env. (not sure, but this maybe related, i guess)

Repro Steps

Simply visit the blog home page

Expected Result

Home page is rendered

Actual Result

  1. Only a blank page returned
  2. No error in http response package
  3. No error log in apache error log file
  4. No access log in apache access log file

The file

It took me a while to find it is caused by new wp-includes/formatting.php. my blog home page is correctly rendered once i replaced the file with its early version in an old 2.8 nightly build.
I were trying to find code level cause, but there are too many changes and i'm really not familiar with these files.i gave up.
These two files are to be attached, one is from 2.8 beta2, the other is from an early 2.8 nightly version, one week or two weeks ago, i'm not sure.

Attachments (4)

formatting.php (77.8 KB) - added by kamiyeye 6 years ago.
early version from a nightly build
formatting.2.php (81.3 KB) - added by kamiyeye 6 years ago.
from 2.8 beta2
formatting.3.php (80.9 KB) - added by ryan 6 years ago.
formatting.php minus 11345
9994.diff (479 bytes) - added by ryan 6 years ago.

Download all attachments as: .zip

Change History (25)

@kamiyeye6 years ago

early version from a nightly build

@kamiyeye6 years ago

from 2.8 beta2

comment:1 follow-ups: @ryan6 years ago

[11345] is the biggest change. Are you using svn? Can you merge that change out and try again.

Also, can your try accessing the individual post pages for the posts showing on your home page and see if a particular one is triggering the problem.

comment:2 follow-up: @Denis-de-Bernardy6 years ago

It sounds like a php memory limit reached issue. How high is that on your system?

comment:3 in reply to: ↑ 2 @kamiyeye6 years ago

Replying to Denis-de-Bernardy:

It sounds like a php memory limit reached issue. How high is that on your system?

It was 16M, now i changed it to 160M, and the home page is still blank.

comment:4 in reply to: ↑ 1 ; follow-up: @kamiyeye6 years ago

Replying to ryan:
I tried an individual post, a page, an attachment page and a backend option page, they all leave me a quick blank page with nothing else.
I've never used svn, i can try it tomorrow. It's too late, i have to sleep now.

comment:5 follow-up: @Denis-de-Bernardy6 years ago

k... could also be a fatal error with display_errors turned off.

comment:6 in reply to: ↑ 5 @kamiyeye6 years ago

Replying to Denis-de-Bernardy:
Come on, i'm doing theme developing all day, how can i turn off it? It's on, all the time

comment:7 in reply to: ↑ 4 ; follow-up: @kamiyeye6 years ago

Replying to kamiyeye:
ryan, i replaced formatting.php with its 11345 version as you said. It's fine, works well just as the earlier nightly build version

comment:8 in reply to: ↑ 1 @kamiyeye6 years ago

Replying to ryan:
Should reply to you, but replied to myself...

@ryan6 years ago

formatting.php minus 11345

comment:9 in reply to: ↑ 7 ; follow-up: @ryan6 years ago

Replying to kamiyeye:

ryan, i replaced formatting.php with its 11345 version as you said. It's fine, works well just as the earlier nightly build version

That narrows it down to any change from 11345 on. Try formatting.3.php, which is the latest formatting.php with only 11345 reverted.

comment:10 @ryan6 years ago

  • Severity changed from normal to blocker

Setting to blocker until we can figure out what's up.

comment:11 @ryan6 years ago

It could be an infinite loop. Those usually die leaving no trace in the logs.

comment:12 in reply to: ↑ 9 @kamiyeye6 years ago

Replying to ryan:

hey ryan, i did everything you said, and much more. So after a half afternoon's trouble shooting, i think i found the root cause.

Let's first look at line 169 in formatting.php of the old version(works well), the function seems_utf8:

function seems_utf8($Str) { # by bmorel at ssi dot fr
	$length = strlen($Str);
	for ($i=0; $i < $length; $i++) {

and line 190 in latest version:

function seems_utf8(&$str) {
	$length = strlen($str);
	for ($i=0; $i < $length; $i++) {

There is an & added, OMG... yes i use this function in my theme.
After i removed the & from the latest formatting.php, everything is on track now.
It might be a type mistake, i guess, a deeply hidden bug, am i right?

comment:13 @dd326 years ago

What are you passing into the seems_utf8 function?

The & mearly means to pass a reference to the string, rather than a copy of the string..

comment:14 @ryan6 years ago

Does is_string() return true for what's being passed? Maybe we need a is_string() check at the top for extra safety?

comment:15 follow-up: @ryan6 years ago

We might want to drop the ref from 2.8 and look into adding it back for 2.9, just to be safe. Figuring why this is happening would be preferred, though. :-)

comment:16 in reply to: ↑ 15 @westi6 years ago

  • Cc westi added
  • Keywords reporter-feedback added

Replying to ryan:

We might want to drop the ref from 2.8 and look into adding it back for 2.9, just to be safe. Figuring why this is happening would be preferred, though. :-)

Adding is_string sounds like a good idea.

We do need to know what is being passed in here though really. Maybe the reporter can attach some examples of what is being passed to seems_utf8, afterall the refernce should make things better not worse.

Also good to know enigronment details - PHP version etc

@ryan6 years ago

comment:17 @ryan6 years ago

Patch, in case we decide to remove the ref.

comment:18 follow-up: @kamiyeye6 years ago

sorry to back later, i didn't think there are still questions. now paste my codes on, maybe a little late cos i saw the patch, but i think some of you may like to view it anyway, and i believe you will know at a glance why it happened:

......
$text = substr($input, $start, $length);
$len = strlen($text);
	
if( $len > 0 && !seems_utf8($text[$len - 1]) ) {
		
	for( $i=0; $i<3; $i++) {
			
		if( $len < 3 ) return '';
				
		if( !seems_utf8($text[$len - 3].$text[$len - 2].$text[$len - 1]) ) {
			$len --;
......

Glad to know the ref is removed, as you can see, if it is added, no matter how i change my codes, my function will not work as desired, i'll have to make an old-version seems_utf8 copy in my theme.
Great patch, great work! And again, your quick reply and responsible work impressed me, you are awesome!

Best Regards,
Kami

comment:19 @ryan6 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [11518]) Don't pass by reference. Props kamiyeye. fixes #9994

comment:20 in reply to: ↑ 18 ; follow-up: @Denis-de-Bernardy6 years ago

Replying to kamiyeye:

sorry to back later, i didn't think there are still questions. now paste my codes on, maybe a little late cos i saw the patch, but i think some of you may like to view it anyway, and i believe you will know at a glance why it happened:

Just FYI, strlen and substr are not multibyte safe unless overloaded.

comment:21 in reply to: ↑ 20 @kamiyeye6 years ago

Replying to Denis-de-Bernardy:

yes i know, thanks anyway.

Note: See TracTickets for help on using tickets.