Quoted from here:
If delimiter contains a value that is
not contained in string and a negative
limit is used, then an empty array
will be returned, otherwise an array
containing string will be returned.
But why I still don't get an empty array?
var_dump(explode(',', '', -1))
I get this:
array(1) {
[0]=>
string(0) ""
}
UPDATE
Try it in windows,with PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
I can confirm that this doesn't work in PHP 5.2.8.
It does work in PHP 5.2.11. In my opinion, there are many bugs in the 5.2 branch, so try always to use the latest version. 5.3 is more stable in my experience.
I've tried this example and got empty array. Wrong question.
Tested your code, and it does return an empty array: array(0) { }.
Running PHP 5.2.11.
Maybe there's an issue with your PHP version. Can you tell us which one you are running?
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.
I am trying to execute this code (it was working on php5, now I'am on php7):
$this->links->$data[$te]['attributes']['ID'] = $data[$te]['attributes']['URL'];
But I get this error:
ContextErrorException: Notice: Array to string conversion
Thanks in advance
This is down to the change in how complex variables are resolved in PHP 5 vs 7. See the section on Changes to variable handling here: http://php.net/manual/en/migration70.incompatible.php
The difference is that the expression:
$this->links->$data[$te]['attributes']['ID']
is evaluated like this in PHP 5:
$this->links->{$data[$te]['attributes']['ID']}
and like this in PHP 7:
($this->links->$data)[$te]['attributes']['ID']
See https://3v4l.org/gB0rQ for a cut-down example.
You'll need to amend your code to be explicit, either by using {} as appropriate, or by breaking it down into two lines. In this case, where you've got code that works fine in PHP 5, pick the former, since it will mean the behaviour stays consistent in all versions of PHP.
I have a project that uses MSSQL over pdo_dblib and freetds. MS scalar functions always returned their data in this format:
array(1) { [0]=> array(1) { ["computed"]=> string(3) "922" } }.
But now, on one of the servers the format suddenly is:
array(1) { [0]=> array(1) { [""]=> string(3) "922" } }.
So the key in the array became empty instead of "computed".
I know that I can change that key in my select statements by adding "as" clause. Still, the question is, what controls the default key?
Both servers use the same database.
As far as I know, this "computed" key is something that's added by pdo_dblib.
PHP version is different between servers, the one with computed has old 5.3, while the one with empty key has 5.5. But I think that this server had 5.5 for quite some time, while the computed key disappeared just yesterday. Not 100% sure though...
In the end I found out that this happens because there was a change in this commit to pdo_dblib. The motivation for this change was that it was clogging up memory.
It should be noted that the version that you get from pecl is weird. It has "computed" in dblib_stmt.c source, but still does not use it.
The version that works, is the one bundled with php sources. I was able to take sources from php-5.3.29\ext\pdo_dblib\ and build them against 5.6.4.
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
I noticed that one of my scripts wasn't working anymore, and started investigating. Eventually it boiled down to nl2br() not working anymore. Check out what results I get from a test script:
nl2br("asd",true): NULL
nl2br("asd",false): NULL
nl2br("asd"): string(3) "asd"
If the second parameter is specified, it returns NULL. WTF? The PHP installation on that box hasn't been touched in ages, it's an aging 5.2.6 on Apache2. Why has it stopped working all of a sudden?
Optional second parameter was added in 5.3.0
The second parameter has been added in 5.3.
My best guess: PHP interprets your comma as the comma operator, not as a delimiter for params, so it evaluates the expression to true or false instead of the string and that gets sent to the nl2br function.