I am searching for a way to check my PHP code for compatibility with different PHP versions.
Especially compatibility to PHP version 7.2 - 8.1 is what I am looking for. At first I tried phpcs but the results were not really good, so I tried something different.
To test the code I introduced phpstan which works really well (for one PHP version) but it seems it is only possible to specify one PHP version per configuration.
My phpstan.neon file:
parameters:
level: 0
phpVersion: 70400
paths:
- src/project
- src/library
Running vendor/bin/phpstan -c phpstan.neon works as expected.
Tried to specify more than one value for phpVersion but this only produces an error because the argument has to be int|null value.
Does anyone know a method to check more than one PHP vesion in just one run of phpstan? Maybe there is an appropriate rule set for different PHP versions?
Related
I'm following https://xdebug.org/docs/install guideline
When I run sudo make test In my MAC 2 PHP versions are installed PHP5 & PHP7 as project requires.
PHP : /usr/local/php5/bin/php
PHP_SAPI : cli
PHP_VERSION : 7.2.7
It gives below error
=====================================================================
EXPECTED FAILED TEST SUMMARY
---------------------------------------------------------------------
Test for bug #1530: Code coverage incorrect for last code line in a loop [tests/bug01530.phpt] XFAIL REASON: PHP bug #76046: PHP generates "FE_FREE" opcode on the wrong line.
=====================================================================
You may have found a problem in PHP.
This report can be automatically sent to the PHP QA team at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
This gives us a better understanding of PHP's behavior.
If you don't want to send the report immediately you can choose
option "s" to save it. You can then email it to qa-reports#lists.php.net later.
Do you want to send this report now? [Yns]:
I tried 2-3 times but same issue occurs.
the reason for the test failure is obvious:
XFAIL REASON: PHP bug #76046: PHP generates "FE_FREE" opcode on the wrong line.
you would need to patch zend_compile.c in the PHP source code (or wait for a fixed version). without patching zend_compile.c test-coverage results might be inaccurate - but nevertheless, common debugging should work. make test wouldn't check for it, when xdebug wouldn't partially rely on it (the title of the test even explicitly states why it checks for the bug). here's the diff, which adds CG(zend_lineno) = ast->lineno;. this "fixes the issue 100%" and not only it's symptoms:
index f1dd49a..9c0893b 100644 (file)
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
## -4807,6 +4807,7 ## void zend_compile_foreach(zend_ast *ast) /* {{{ */
zend_end_loop(opnum_fetch, &reset_node);
+ CG(zend_lineno) = ast->lineno;
opline = zend_emit_op(NULL, ZEND_FE_FREE, &reset_node, NULL);
}
/* }}} */
this bug affects PHP 7.0, 7.1, 7.2 - PHP 5.x was at least not reported.
since this is not a xdebug bug, installing even with the failed test shouldn't make anything worse, than it already is. to install xdebug, it's not sudo make test but make && sudo make install (only make install requires sudo).
Well, I'm transferring a little web server from one computer to other, on the 'other' computer I cannot a more updated version of PHP,
I just have to add my files through ssh and that's all, when I load my webpage it says explicitly:
The error is showing on a Debian with PHP 5.4.27 squeeze, the webserver comes from an Ubuntu with PHP 5.4.16 oneiric
Parse error: syntax error, unexpected '[' in ~directory~ on line 38
This is the line 38.
$VALUE=$DB->query("a nice sentence")->fetch()[0];
So, i was pretty surprised because PDO was accepted since PHP 5.1, so, i look deeper and i found the possible error, you can't simply do ->fetch()[0], you must separate it in order to be "processed",
However, I have transport this server with this information before, so i really don't know if it's something on the configuration of PHP or maybe the version by itself 5.4.X? You guys know any hint? As I said, i can't just install other updated version of PHP5, what do you recommend?
Have a nice night.
Edit: updated to the issue on the PHP 5.4 now
The error seems triggered by the array dereferencing. This was added in PHP 5.4.. Not sure how you made that work in 5.3.6
http://nl3.php.net/language.types.array.php
To workaround you could try
$VALUE = $DB->query("a nice sentence")->fetch();
echo $VALUE[0];
PHP Version on my ubuntu (where it works):
PHP Version 5.4.16
PHP Version on the Debian (where it does not work):
PHP Version 5.4.27-1~dotdeb.0
This version number was extracted by using phpinfo(); on the index page.
Apparently, the error was solved by JUST changing the first issue line (the other hundreds of codes that had that wasn't necessary to change, what i believe to be a little weird).
$VALUE = $DB->query("a nice sentence")->fetch()->offset(0);
When running
getenv('HOME');
it just returns false. Therefore some scripts ran by
shell_exec();
don't work, because they are missing the home path.
PHP (5.5) runs on debian, so it should work according to the manual, but why is it empty then?
I guess you must have found some solution to this problem. But in the interest of others who may drop by, in search of solutions to a similar problem:
I also encountered this sort of issue. In my case it happened in Windows, Apache, PHP stack, but only when I configure PHP to run with mod_fcgid. In that case, variables that I knew existed in the OS environment refused to appear with PHP getenv(), with the exception of few.
My solution: I added this to httpd.conf:
PassEnv HOME
I have problems after updating Zend FR to 1.11
Mimetype file checking generates:
Warning: string extension `B' invalid
It looks like cause of problems the string in the Zend_Validate_File_MimeType
$finfo = finfo_open(FILEINFO_MIME_TYPE, $file);
I have created simple test case
$finfo = finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic');
echo finfo_file($finfo, PUBLIC_HTML_PATH . '/images/missing.png');
finfo_close($finfo);
And i got same error :(
finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic'); //generates: Warning: string extension `B' invalid.
My OS: Kbuntu 10.10
Where am i wrong?
Ran into the same error message ("Warning: string extension w' invalid in Command") as Mike Purcell, but the fix for it was different.
On our servers we had a /usr/share/misc/magic and a /usr/share/misc/magic.mgc file. The magic.mgc file had been compiled from the magic file, but PHP still wasn't happy talking directly to the /usr/share/misc/magic file (we'd shifted to that file as part of debugging that the magic.mgc file needed updating).
The fix for us was changing our putenv line back to the magic.mgc file:
putenv('MAGIC=/usr/share/misc/magic.mgc');
Then, magic-ally :-) , the whole mime-type detection system started working again.
This may not pertain to your EXACT issue, but it did resolve the issue I was having which resulted in a very similar error message: "Warning: string extension w' invalid in Command".
For us, we have a heterogenous setup where some servers are still running php 5.2 and others running php 5.3. On the 5.2 boxes the magic file resides in /usr/share/file/magic, but on the 5.3 boxes the file resides in the default path of /usr/share/misc/magic. Apparently someone tried to reconcile these path differences by symlinking the 5.2 path so the codebase could be php version agnostic. But according to some comments posted on PHP site regarding symlinks to the magic file, it will result in unexpected behavior, which of course was resulting in the aforementioned error message.
So be sure the path you are passing is to the actual magic file, and not a symlink, and see if that resolves your issue.
Depending on your PHP version the magic format may be updated. This is documented in a note at http://php.net/manual/en/function.finfo-open.php
run php -v to see your version
I got the same error when pointing to an older magic file in our source tree, and resolved it when pointing to a newer magic file from my current linux distro
I had this error in Laravel (minus Zend FR, of course). Running PHP 5.3.21 on a Windows box with IIS.
Finding very little info online I was close to giving up. It worked initially when I followed instructions in the comments on PHP.net, which were basically to add fileinfo.dll to your PHP installation, and to also download the relevant magic files and point an environment variable to them.
There was some initial confusion until I realised I didn't actually have php_fileinfo.dll, so as well as adding it to the php.ini file, I had to download the file itself and add it to my ext directory.
Now what really had me stuck, was that it worked initially. The next day it didn't. To cut a long story short, it didn't need the environment variable, MAGIC. The reason this had me stuck, is because I had tried every possible scenario, but once the environment variable had been set, it had been set. And I had to restart the Windows server after removing it, to unset it. Once I did this it worked perfectly.
The database management system Sybase ASE supports multiple result sets, however the implementation of Sybase in PHP doesn't. There is a bug reported on this issue and there is also a patch supplied in that report (https://bugs.php.net/bug.php?id=48675). The patch is for version 5.2.9 and I've tried to add it to version 5.3.10. The source builds without warnings or errors, and testing the new function 'sybase_next_result()' does not yield a fatal error "Call to undefined function". This would suggest that the function is implemented, but not working as expected.
Configuration is:
configure --disable-isapi --enable-debug-pack --without-mssql --without-pdo-mssql --without-pi3web --with-mcrypt=static --disable-static-analyze --enable-cli --with-sybase-ct=%SYBASE%\%SYBASE_OCS%
There is a notice on 'sybase_query()' when there are multiple result sets saying "Sybase: Unexpected results, cancelling current in...". The first result set is retrieved. And this notice is returned even without the patch.
The number of stored procedures in the database that return multiple result sets is vast, and a 'sybase_next_result()' would be the best solution. In short, I looking for an equivalent to 'mssql_next_result()' (http://se2.php.net/manual/en/function.mssql-execute.php) for Sybase in PHP 5.3.10.
Worth noting is that the other parts of the Sybase implementation is in place and seems work as expected.
My testing environment is a WAMP server (Windows 7, Apache 2.21, MySQL 5.5.20, PHP 5.3.10) and Sybase ASE is version 15.7.0.
Is there anyone out there that has "solved" this?
With regards
//Jonas
Update:
A colleague gave me the instructions to use 'OutputDebugString()' (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) and catch that with DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647).
From this I can say that 'sybase_next_result()' is called but the block
if (sybase_ptr->active_result_index) {
...
}
is not run. This is probably correct (as I see it).
The row
retcode = ct_results(sybase_ptr->cmd, &restype);
is always setting 'retcode' to 'CS_FAIL'. This is perhaps because the earlier
ZEND_FETCH_RESOURCE2(sybase_ptr, sybase_link *, sybase_link_index, id, "Sybase-Link", le_link, le_plink);
sets 'sybase_ptr' in sutch fashion that 'retcode' becomes 'CS_FAIL'.