Fixed php 5.4 bug

  • Thread starter Thread starter ragtek
  • Start date Start date
R

ragtek

Guest
since i updated php to 5.4 on my dev machine, i'm getting this error while viewing threads:
error.webp
withoutfile.webp

i thought that it's from an add-on, but after spending 2h with add-on deactivating & activating, the bug didn't disapper.

the other strange problem is, that i've installed 2 other vanilla test boards but on only 1 i'm able to reproduce this.........

after ~ 4h i'll give it up

mike it's your turn:p
 
since i updated php to 5.4 on my dev machine, i'm getting this error while viewing threads:
View attachment 27690
View attachment 27691

i thought that it's from an add-on, but after spending 2h with add-on deactivating & activating, the bug didn't disapper.

the other strange problem is, that i've installed 2 other vanilla test boards but on only 1 i'm able to reproduce this.........

after ~ 4h i'll give it up

mike it's your turn:p
http://xenforo.com/community/threads/thread-view-error-on-php-5-4.30140/

Seems like you're having the same issue. Thanks for pointing this out.

Hopefully we'll get an answer or resolve.....

Seems to also affect personal conversations as well (PM)

Code:
Template Errors: conversation_view
 
    Illegal string offset 'thumbnailUrl' in /home/*****/public_html/forums/internal_data/templates/S.1,L.1,conversation_view.php, line 1150
    Illegal string offset 'thumbnailUrl' in /home/****/public_html/forums/internal_data/templates/S.1,L.1,conversation_view.php, line 1154
    Illegal string offset 'filename' in /home/****/public_html/forums/internal_data/templates/S.1,L.1,conversation_view.php, line 1169
    Illegal string offset 'filename' in /home/***/public_html/forums/internal_data/templates/S.1,L.1,conversation_view.php, line 1177


For the time being, I've reverted to 5.3.10, but I really do need 5.4 for something I'm working on. Hopefully this gets resolved soon.
 
No issues on Redhat with Axivo PHP 5.4.0 and a stock board, time to upgrade to a real OS? :D
Linux OS should have no impact on how PHP processes things.

But since you want to compare.... Red Hat, Cloud Linux, Debian, and Ubunut all yielded poor results.
 
But since you want to compare.... Red Hat, Cloud Linux, Debian, and Ubuntu all yielded poor results.
What do you mean by poor results? I was simply stating that I had no errors or issues with Xenforo while running my custom PHP 5.4.0 RPM in CentOS 5.8 64bits. Of course the OS has a major impact. PHP 5.4.0 does require a fair amount of missing packages in CentOS, which I had to write from scratch (i.e. libedit-3.0.20110709, libzip-0.10.1, openssl-1.0.1, re2c-0.13.5, sqlite-3.7.9, t1lib-5.1.2 and much more). All these new/updated packages are needed at compile time, or else you will end-up with errors similar to the one listed above. Is not weird science, all you have to do is look at the compile logs and you will see everything PHP needs there.

On top of that... my PHP package is specifically designed/optimized for Nginx 1.1.18 (which will turn stable in 2 weeks) and MariaDB 5.3.5, it will not work with Apache for example.
 
This error is bug: https://bugs.php.net/patch-display....abling_bad_string_offsets&revision=1323002696
In 5.5 this bug is fixed. In 5.4 need patch or change code for use isset in array keys.
Not true, the above mentioned patch (which is superseded by a more recent one) is already applied on PHP 5.4.0 final.
since i updated php to 5.4 on my dev machine, i'm getting this error while viewing threads... after ~ 4h i'll give it up.
You mean more like 4 minutes? I see those errors also, now. :D
Originally, I installed an empty board without testing it properly. The errors can be addressed very easy by editing the attachment_editor_attachment template to match the following content:
Code:
<xen:require css="attachment_editor.css" />

<li id="{xen:if $isTemplate, 'AttachedFileTemplate', 'attachment{$attachment.attachment_id}'}"
	class="AttachedFile {xen:if 'isset({$attachment.thumbnailUrl})', 'AttachedImage'} secondaryContent">

	<div class="Thumbnail">
		<xen:if is="isset({$attachment.thumbnailUrl})">
			<a href="{xen:link attachments, $attachment}" target="_blank"
				data-attachmentId="{$attachment.attachment_id}"
				class="_not_LbTrigger" data-href="{xen:link misc/lightbox}"><img
				src="{$attachment.thumbnailUrl}" alt="{$attachment.filename}"
				class="_not_LbImage" data-src="{xen:link attachments, $attachment, 'embedded=1'}" /></a>
		<xen:else />
			<span class="genericAttachment"></span>
		</xen:if>
	</div>

	<div class="AttachmentText">
		<xen:if is="isset({$attachment.filename})"><div class="Filename"><a href="{xen:link attachments, $attachment}" target="_blank">{$attachment.filename}</a></div></xen:if>
	
		<xen:if is="{$isTemplate}">
			<input type="button" value="{xen:phrase cancel}" class="button smallButton AttachmentCanceller" />
			
			<span class="ProgressMeter"><span class="ProgressGraphic">&nbsp;</span><span class="ProgressCounter">0%</span></span>
		<xen:else />
			<noscript>
				<a href="{xen:link 'attachments/delete', $attachment}" target="_blank" class="button Smallbutton">{xen:phrase delete}</a>
			</noscript>
			
			<xen:if is="isset({$attachment.thumbnailUrl})">
				<div class="label">{xen:phrase insert}:</div>
			</xen:if>
			
			<div class="controls">				
				<input type="button" value="{xen:phrase delete}" class="button smallButton AttachmentDeleter" data-href="{xen:link 'attachments/delete', $attachment}" />
			
				<xen:if is="isset({$attachment.thumbnailUrl})">
					<input type="button" name="thumb" value="{xen:phrase thumbnail}" class="button smallButton AttachmentInserter" />
					<input type="button" name="image" value="{xen:phrase full_image}" class="button smallButton AttachmentInserter" />
				</xen:if>
			</div>
		</xen:if>

	</div>
	
</li>

That brings me to a thread I already discussed these issues, but everyone thought I'm crazy. :)
 
Just to re-iterate what infis said:
This is not a PHP 5.4.0 bug, is simply related to properly writing a boolean type condition.
I was wrong. It's still a bug. The absence of a key in the array should not cause this warning. In the link about it and said. In particular there is a solution, and information about the patch in the release.
But in some of the RC version 5.4 this bug was. It is possible that some Linux distributions, and build on Windows could not be collected from the release, and from the RC.
Work on the 5.4 release XenForo should be correct without the need to change templates.
 
This error was in earlier versions of 5.4 and fixed (if judged by the bugtracker) before the release of 5.4. Thus, this error is simply not to be. Accordingly, there is no need to edit templates.
I regret that I do not speak English. Maybe I just can not properly translate into English his thoughts on the matter.

What kind of error specifically refers to, which leads to the need to edit the template?
 
This error was in earlier versions of 5.4 and fixed (if judged by the bugtracker) before the release of 5.4. Thus, this error is simply not to be. Accordingly, there is no need to edit templates.
I regret that I do not speak English. Maybe I just can not properly translate into English his thoughts on the matter.

What kind of error specifically refers to, which leads to the need to edit the template?
Don't worry my friend, about the English. :)
Related to what you call a "bug", in my books it is not. In PHP 5.4.0, the illegal use of string offsets causes E_ERROR instead of E_WARNING (PHP 5.3.x). This is a quick example:
PHP:
<?php
 
$i = ceil((1 * 2) / 2);
$var = 'foo';
 
// notice
var_dump($var[$i]);
 
// warning
if ($var['key'])
{
	var_dump($var);
}
 
// fatal
unset($var['key']);

The above code produces the following warnings/errors:
Notice: String offset cast occured in /var/www/axivo/error.php on line 7
string(1) "o"
Warning: Illegal string offset 'key' in /var/www/axivo/error.php on line 10
string(3) "foo"
Fatal error: Cannot unset string offsets in /var/www/axivo/error.php on line 16
Note that there are no array keys set, yet the var_dump is executed (which it should not, but you get the warning so you know your code is wrong). In my books, the previous PHP behavior was wrong and I'm glad they correct it. PHP is leaning toward a more strict, structured language and those kind of warnings/errors are the example of it. Obviously, everything is logic: "Hey, where are you going with $var['key'], this is not an array!"

In other words, there is a need to edit the templates if you want to comply with proper PHP coding, until Mike fixes the issue in Xenforo code. Everything relies (I think) on the way array keys are set into _prepareAttachmentForJson() function.
 
Related to what you call a "bug", in my books it is not. In PHP 5.4.0, the illegal use of string offsets causes E_ERROR instead of E_WARNING (PHP 5.3.x)
In 5.4 illegal use of string offsets causes E_WARNING:
Code:
C:\Program Files (x86)\NuSphere\PhpED\php54>php q.php
PHP Notice:  String offset cast occured in C:\Program Files (x86)\NuSphere\PhpED\php54\q.php on line 7
string(1) "o"
PHP Warning:  Illegal string offset 'key' in C:\Program Files (x86)\NuSphere\PhpED\php54\q.php on line 10
string(3) "foo"
PHP Fatal error:  Cannot unset string offsets in C:\Program Files (x86)\NuSphere\PhpED\php54\q.php on line 16
 
In 5.4 illegal use of string offsets causes E_WARNING.
That is the proper error message in PHP 5.4.0, I gave 3 type of errors related to the same code event (notice, warning and fatal on invalid use of array keys). You want a notice instead of a warning, if the code is not proper? Not me.

The proper way to write that code segment is:
PHP:
if (isset($var['key']))
{
	var_dump($var);
}
Let me repeat what I said into previous post: "PHP is leaning toward a more strict, structured language and those kind of warnings/errors are the example of it."

Look at all the other software developers how they fix similar issues (i.e. Wordpress, Drupal, IPB, etc.), nobody is complaining this is a PHP bug (because is not). :)
 
The proper way to write that code segment is:
I know.
PHP is not strongly typed programming language. Allows "on the fly" to initialize variables. This has both advantages and disadvantages.
If some things have to stop working or need to start to work differently, you will need to pre-declare them deprecated. Therefore, the change in E _WARNING E_ERROR was announced at the bug and fixed it to the 5.4 release. Is not it strange?
Yes. The code will still need to write more correct. In this you are right.
 
Therefore, the change in E _WARNING E_ERROR was announced as a bug and fixed into 5.4 release. Is not it strange?
I think the important part is that it was fixed in a RC release while still keeping the strict (proper) code validation into final release.
 
Not true, the above mentioned patch (which is superseded by a more recent one) is already applied on PHP 5.4.0 final.

You mean more like 4 minutes? I see those errors also, now. :D
Originally, I installed an empty board without testing it properly. The errors can be addressed very easy by editing the attachment_editor_attachment template to match the following content:
Code:
<xen:require css="attachment_editor.css" />
 
<li id="{xen:if $isTemplate, 'AttachedFileTemplate', 'attachment{$attachment.attachment_id}'}"
class="AttachedFile {xen:if 'isset({$attachment.thumbnailUrl})', 'AttachedImage'} secondaryContent">
 
<div class="Thumbnail">
<xen:if is="isset({$attachment.thumbnailUrl})">
<a href="{xen:link attachments, $attachment}" target="_blank"
data-attachmentId="{$attachment.attachment_id}"
class="_not_LbTrigger" data-href="{xen:link misc/lightbox}"><img
src="{$attachment.thumbnailUrl}" alt="{$attachment.filename}"
class="_not_LbImage" data-src="{xen:link attachments, $attachment, 'embedded=1'}" /></a>
<xen:else />
<span class="genericAttachment"></span>
</xen:if>
</div>
 
<div class="AttachmentText">
<xen:if is="isset({$attachment.filename})"><div class="Filename"><a href="{xen:link attachments, $attachment}" target="_blank">{$attachment.filename}</a></div></xen:if>
 
<xen:if is="{$isTemplate}">
<input type="button" value="{xen:phrase cancel}" class="button smallButton AttachmentCanceller" />
 
<span class="ProgressMeter"><span class="ProgressGraphic">&nbsp;</span><span class="ProgressCounter">0%</span></span>
<xen:else />
<noscript>
<a href="{xen:link 'attachments/delete', $attachment}" target="_blank" class="button Smallbutton">{xen:phrase delete}</a>
</noscript>
 
<xen:if is="isset({$attachment.thumbnailUrl})">
<div class="label">{xen:phrase insert}:</div>
</xen:if>
 
<div class="controls">
<input type="button" value="{xen:phrase delete}" class="button smallButton AttachmentDeleter" data-href="{xen:link 'attachments/delete', $attachment}" />
 
<xen:if is="isset({$attachment.thumbnailUrl})">
<input type="button" name="thumb" value="{xen:phrase thumbnail}" class="button smallButton AttachmentInserter" />
<input type="button" name="image" value="{xen:phrase full_image}" class="button smallButton AttachmentInserter" />
</xen:if>
</div>
</xen:if>
 
</div>
 
</li>

That brings me to a thread I already discussed these issues, but everyone thought I'm crazy. :)
thank you soooooooo much for this fix!
 
thank you soooooooo much for this fix!
Is not really a fix. :D

The real fix is to address the PHP faulty code in Xenforo, which I'm not 100% comfortable with. Is it obvious the call is done into thread_view template... but I have no idea how the code is processed to end-up calling some DoUpload class. Anyways, I bet Mike will enjoy fixing this nice and tight. :)
 
Top Bottom