Testing against various PHP versions - php

I have a PHP app that I would like to test against various PHP versions. I don't need to configure it with Apache or mysql, a simple php command line binary would do. I would however need cURL with SSL support compiled in.
The reason I ask as I tried compiling my own and ran into all sorts of issues with newer versions of curl don't work with older versions of PHP etc.
I already have a test suite and would like to run it against as many versions of PHP as possible.
Is there a good way to do this short of manually compiling a ton of php binaries?

Check phpfarm, primarily developed for PEAR's CI machine.

Related

software not working after change of php version

I have a commercial membership site php program on the server, but after the server upgrade it no longer works. The provider has ceased to operate so there is no support. I am using php 7.0.15, but the server wants me to upgrade to a more recent version, 7.4. This breaks the program /all I get is a blank screen)
My level of PHP does not allow me to debug such a complicated program. My question is:
is there any way of instructing php to only use the older version? I imagine that this would have to be done in the php.ini file on the server?
I would like to upgrade to php 7.4 on the server, but have this software run in php 7.0.
Is this possible?
The simple answer is No - PHP does not offer any options to emulate the behaviour of previous versions.
Partly because features are sometimes removed because they prevented changes in the engine, or would need a lot of work to operate with them; partly just because there is only a limited amount of resources available to work on the core of PHP, and maintaining multiple versions of each feature to enable such compatibility would take effort away from improving the current version.
Your short-term option is to find a way to run an actual copy of PHP 7.0 on the server, or a different server that will allow you to run it. You may need to pay someone who provides unofficial long-term support for old versions, since the last official security patch for that version was over 3 years ago. Even PHP 7.4 will only receive official security patches until the end of this year.
In the long term, your only options are to hire someone to update the application to run on a modern version of PHP, or to migrate to a different application which still has a vendor supporting it.

check old php scripts for upgradeing/migrating to newer php version

I've many PHP-Scripts based on older PHP Versions. I'm currently using PHP 5.3 and want to upgrade to a newer Version, but I don't know which is compatible with the functions I'm using. Is there a Framework or any other tool to check the Scripts with? I want to upgrade/migrate to PHP 7.2 and I know that some functions (like mysql) are removed.
I don't remember every function I used in those hundreds of Scripts and don't really want to search line for line for deprecated and removed functions.
You can have a look at Phan. It runs under PHP and can statically analyze your scripts for compatibility with newer PHP versions.
If you call it using
phan --directory <directory_with_scripts> --target-php-version 7.2
It'll tell you what will fly and what will not!
Hope this helps!

Can a PHP app be compatible to PHP5 and PHP7 at the same time?

I have a complicated custom PHP app written for PHP5.
Can an app be modified to be compatible with both PHP5 and PHP7?
The background is that the server runs PHP5. What if it was upgraded to PHP7, could the upgrade be seamless.
Most likely yes. But only if the app doesn't use PHP7 functions or syntax (In you issue it's only that). The best way to find out is to make a second server to test it out. An example: In Magento (big PHP app, I would say), there is only one line of code that crashes the app. This is a Syntax thing. But without testing out and reading the error log, you will most likely not finding it out by pure source code reading. I port multiple websites a week from PHP5 to PHP7. Most of the time the only problem is that some apps use MySQL instead of MySQLi (talking about the PHP-Modul. Not the Databases itself)
From PHP5 to PHP7 is major version change. It would be surprise if the code worked as it is! As a starting point, you can see this http://php.net/manual/en/migration70.php

Why does PHPinfo have a header version and library version? What are the differences?

I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.

Is there a interactive debugger for php like ruby's debugger?

I watched the Creating a weblog in 15 minutes with Rails 2 and after 9 minutes in the video he shows ruby's interactive debugger, which allows you to call functions/methods from within a running script.
This goes way beyond breakpoints and looks very useful.
Is there something for PHP that gives similar functionality?
Install xdebug and then use one of the debug clients mentioned here.
Although Milen's answer is the only correct one circa 2009, and Xdebug is still a useful tool, using it requires you to recompile your PHP or to edit your php.ini runtime configuration to load it as a shared object. It also means using a specific client application that supports its network protocol, such as an IDE like PhpStorm.
An alternative is phpdbg, which is an interactive debugger that ships with PHP core versions 5.6 and later and can debug PHP scripts written to conform to PHP 5.4 or later.
Using it is simple:
phpdbg php_script_i_want_to_debug.php
Once in the debugger, type help to access the help menu.
If you don't already have phpdbg on your system, it may be because your PHP was configured without the --enable-phpdbg option. You can either:
Recompile your PHP, being sure to add --enable-phpdbg when you run ./configure (this will simply also build the phpdbg binary), or
download the phpdbg source independently and compile it against your installed PHP (assuming you have the PHP source available). Instructions for doing that, while sparse, are here.

Categories