I am having some some problems here. I am using XAMPP on a Windows box to test. I will be uploading the final product to a CentOS server.
I have this line of code:
$dbFunc->GetTemplateName($report['uat_template'])[0]['uat_name'];
On the Windows configuration, this works fine. However I get a parse error on the Unix box. It isn't happy with the [0] identifier.
If i do;
$temp = $dbFunc->GetTemplateName($report['uat_template']);
$temp = $temp[0];
echo $temp['uat_name'];
It works fine, but it's added 2 lines of code?
Is there any way to make the first way work on Unix?
Thanks
The first example in your question makes use of array dereferencing feature in PHP, which is only available for PHP 5.4+. If you're using an older PHP version, you will need to upgrade. If upgrading is not an option, you're stuck with the second method, I'm afraid.
In PHP 5.4 PHP added a function array dereferencing has been added, e.g. foo()[0].
So it looks like on CentOS you have >=PHP5.4 and on XAMPP <5.4
More info : http://php.net/manual/en/migration54.new-features.php
Related
I upgraded from php 5 to 7.2, and there is no problem at local (some changes needed, but it solved).
One of my function not working in production server.
The code looks like this:
$someBool = in_array($some, array("asd", "fgh", "etc"));
If I make a var_dump on this, the result is UNKNOWN:0, but if I make a vardump exactly below this (there is no any if station before dump), the function works correctly, end the dump result will be bool (true) or bool (false).
(I don't overwrite this variable)
Again if I comment the var_dump line, the function works incorrectly.
There is anybody who has idea what can cause this behaviour?
Thanks for your help.
In the original function:
$needCmdText = in_array($fieldName,array(
'cmdpreid','cmdpostid','cmdskipid',
'cmdfixid','cmdexpid','cmdsysid'
));
Where the $fieldName always 'cmdexpid' from the client. (at my test cases)
And a funny news, a simple echo solve the problem too, but it should be under this.
I changed the php 7.2 to 7.1, which solved the problem without any code changing. (No need to dump, to solve).
I think there is a strange bug in php 7.2, which doesn't occure in windows environment.
Why does Dreamweaver show a red error on this line
<?php $pt=$test->Terms()['Terms'];?>
The line is perfectly valid and runs, and does what it is supposed to do, and yet dreamweaver insists that it is an error.
I have a function returning a named array you see, and it works fine on the page.
You are directly accessing an array key of a function result. Array dereferencing of function results was implemented in PHP 5.4. See http://php.net/manual/en/language.types.array.php
I'd guess that the syntax checking of Dreamweaver uses a version of PHP < 5.4.
You should check array key existence before referencing to it
I have a Form object $form. One of its variables is a Field object which represents all fields and is an array (e.g $this->field['fieldname']). The getter is $form->fields().
To access a specific field method (to make it required or not for example) I use $form->fields()['fieldname'] which works on localhost with wamp but on the server throws this error:
Parse error: syntax error, unexpected '[' in (...)
I have PHP 5.3 on the server and because I reinstalled wamp and forgot to change it back to 5.3, wamp runs PHP 5.4. So I guess this is the reason for the error.
How can I access an object method, which returns an array, by the array key with PHP 5.3?
Array dereferencing is possible as of PHP 5.4, not 5.3
PHP.net:
As of PHP 5.4 it is possible to array dereference the result of a function or method call directly. Before it was only possible using a temporary variable.
Array dereferencing as described in the question is a feature that was only added in PHP 5.4. PHP 5.3 cannot do this.
echo $form->fields()['fieldname']
So this code will work in PHP 5.4 and higher.
In order to make this work in PHP 5.3, you need to do one of the following:
Use a temporary variable:
$temp = $form->fields()
echo $temp['fieldname'];
Output the fields array as an object property rather than from a method:
ie this....
echo $form->fields['fieldname']
...is perfectly valid.
Or, of course, you could upgrade your server to PHP 5.4. Bear in mind that 5.3 will be declared end-of-life relatively soon, now that 5.5 has been released, so you'll be wanting to upgrade sooner or later anyway; maybe this is your cue to do? (and don't worry about it; the upgrade path from 5.3 to 5.4 is pretty easy; there's nothing really that will break, except things that were deprecated anyway)
As mentioned array dereferencing is only possible in 5.4 or greater.
But you can save the object and later on access the fields:
$fields=$form->fields();
$value=$fields['fieldname']
...
AFAIK there is no other option.
We recently had a disaster and had to move our php web application from PHP Version 5.2.6-1+lenny16 to PHP Version 5.3.3-7+squeeze15 and found a seemingly important difference.
In our application, there were instances where we incorrectly called an array's index using object syntax:
echo $array->index;
However, 5.2.6 seemed to forgive this, and correctly treat it as if $array['index'] was written.
Upon further testing, what 5.2.6 is specifically doing is disagreeing with 5.3.3 as to whether $array->index is empty();
Here is the test code I've run on both servers:
<?php
echo phpversion() . '<br>';
$array = array(
'x' => 1,
'y' => 2
);
if (!empty($array->x))
{
echo "not empty";
}
else
{
echo "empty";
}
?>
Here are the two different outputs:
5.2.6-1+lenny16
not empty
5.3.3-7+squeeze15
empty
Naturally, there are now a few outbreaks of broken functionality because we were never alerted to these errors during development. Is there a way we can configure php 5.3 to permit this incorrect syntax while we take a bit more time to find all the incorrect instances of it?
I don't think it's a configuration issue, is it? Was something changed in the way empty() works in between versions?
I just have put your example code to a general test across PHP versions (test) and it shows that you are correct, there are differences:
From PHP 5.0.0 up to 5.2.11 (and also early 5.3.0 to 5.3.1), this "undefined property" was reported as not empty which does qualify as a flaw or bug.
The related change in 5.2.12 (17 Dec 2009) was (ref):
Fixed bug #50255 (isset() and empty() silently casts array to object). (Felipe)
Technically this is not a backwards incompatible change from PHP 5.2 to 5.3 because it was a flaw in both branches and also fixed in both. Those are harder to spot if you migrate, because the standard migration guide does not cover them. Instead you need to go through the changes of the software and look for notes and references to tickets.
So to answer your question: This is a configuration issue because the PHP version used counts as configuration. You changed the configuration and then you had the issue.
Also as the report shows, this is limited to empty() and isset(), not general object/array access. As you can imagine, if that would have been the case, you would have found much more reference about it.
I have a web application that runs fine on our Linux servers but when running on Mac OS with the Zend Community Edition Server using PHP 5.3 we get the error:
usort(): Array was modified by the user comparison function
every time a page loads for the first time (it takes about 2 minutes for a page to tick over and load, on the linux servers the page loads in 1 second).
Has anyone else experienced this or has any idea how I can fix the problem, I have tried playing around with PHP and Apache memory settings with no luck.
There is a PHP bug that can cause this warning, even if you don't change the array.
Short version, if any PHP debug functions examine the sort array, they will change the reference count and trick usort() into thinking you've changed the data.
So you will get that warning by doing any of the following in your sort function (or any code called from it):
calling var_dump or print_r on any of the sort data
calling debug_backtrace()
throwing an exception -- any exception -- or even just creating an exception
The bug affects all PHP 5 versions >= 5.2.11 but does not affect PHP >= 7. See the bug report for further details.
As far as I can see, the only workaround is either "don't do that" (which is kind of hard for exceptions), or use the error suppression operator #usort() to ignore all errors.
To resolve this issue we can handle as below
1) use error_reporting
$a = array('id' => 2,'val' => 3, 'ind' => 3);
$errorReporting = error_reporting(0);
usort($a);
error_reporting($errorReporting);
2) use #usort($a);
$a = array('id' => 2,'val' => 3, 'ind' => 3);
#usort($a);
What version of PHP is on the linux box?
Are the error_reporting levels the same on both boxes? Try setting them both to E_ALL.
The warning is almost certainly not lying. It's saying that the comparison function you're passing to usort() is changing the array that you're trying to sort - that could definitely make usort take a long time, possibly forever!
My first step would be to study the comparison function, and figure out why that's happening. It's possible that if the linux boxes are using a pre-5.3 version, there is some difference in the behavior of some language function used in the comparison function.
I found that using PHP5.4 , logging with error_log($message, $message_type, $destination, $extra_headers) causes this error , when I clean log entries my problem solved. Logging may temporarily be suspended by disabling and restoring logging after sort function.