Php 7 Migration is still a hot issue for developers around the globe. Some host providers already completed the process, but many others are still lacking behind. Therefore, it is good to share some wisdom and technical tips that will help random PHP citizens around the world.
I see two major parameters that should be carefully considered in the beginning of this tough marathon and they are reusability + versatility.
Reusability
Everyone should agree the equation below:
Reusability = Time = Cost
We all wrote our PHP 5.0 code some time ago. Our frontend applications are built on top of it and those PHP programs worked fine in the dungeons of our CMS. Now, we have to change the architecture of the underground facilities, but remember! The old code provided the expected results and all we want is to keep it the same. Because, the old code is reliable and well-testet over time. Integrating the failing parts to the newer version of PHP is sufficient. As a result of these, we don’t aim for rewriting of classes, we aim for catching and fixing the integration issues. This is a search & destroy mission. Although this strategy failed in Vietnam War, but never mind.
Versatility
This will be a long process for most of the developers and since you are working in short sprint cycles (say 3 weeks), at least half of your migration commits will be delivered to the production server which still runs on PHP 5.0. One may disagree with this approach by saying:
‘Nope, we will keep the migration commits on a different git branch and when all tests are complete and sufficient code coverage is reached, we will merge these two branches.’
The decision is certainly up to you, but I wouldn’t recommend this method. Because, there will be surely some conflicts after this big merge operation and the outcome will not be as reliable as you think. Therefore, I recommend to follow another path: Make sure that your fix commits works both on PHP 7.0 and PHP 5.0.
Fatal Error Examples and Solution Tips
EXP-1: “Fatal error: Uncaught ArgumentCountError: Too few arguments to function…”
We start with a popular one. You will see this error message when one of your php functions is using a default argument. See the example function below:
public function myFunction($array1, $array2) {
if (!$array2) {
$array2 = array();
}
return count($array1) + count($array2);
}
The simple php function above expects two arrays as arguments and it returns the sum of array sizes. myFunction will work fine on PHP 5 even though you pass only one array, but the same call will give a fatal error message on PHP 7. Because, PHP 7 does not automatically assign a relevant default value on undefined arguments like PHP 5 does. Therefore, we should edit the function as following:
public function myFunction($array1, $array2 = array()) {
if (!$array2) {
$array2 = array();
}
return count($array1) + count($array2);
}
By assigning an empty array to the second argument, we let the function run both on PHP 5 and PHP 7.0. The same error message will occur when the second argument is a string, integer or an object. Then, we should use the relevant default value in syntax. For example, empty string “”, 0 or NULL values can be used accordingly for default initialisation.
You may end up getting the same error on redundant argument declaration. For example, $array2 might be declared in the function signature, but it might be actually never used. Certainly, this is the simplest case. Just delete the redundant argument and get over with the refactoring.
EXP-2: “Deprecated Methods with the same name as their class will not be constructors in a future version.”
The error message above already explains a lot, but seeing an example code excerpt is definitely enlightening:
class CafPage extends myPage { function CafPage($tid, $view_id, $title, $site) { $this->myPage($tid, $view_id, $title, $site); } }
The error apparently triggers in the constructor. PHP 7 does not like using the same name on both the class and the constructor function. Therefore, the same function should be edited as following:
class CafPage extends myPage { function __construct($tid, $view_id, $title, $site) { $this->myPage($tid, $view_id, $title, $site); } }
This fix will run on PHP 5 and 7 without any issues. Remember: Versatility!
EXP-3: “Non-static method … should not be called statically in …”
I witnessed this error message in a function call similar to the one below:
return UserdataHelper::runTemplate('bla-bla.php');
It seems PHP 7 was not happy with :: reference on non-static methods. Therefore, I firstly initiated the caller object and triggered the runTemplate function by arrow object operator (->).
return (new UserdataHelper)->runTemplate('bla-bla.php');
And Eureka! It works!
Conclusion
Three example error messages are handled in this post. These are the frequent error types that I came across during our migration process. Above all, the sneakiest php errors are those which do not output a fatal error message. These issues usually occur when an ajax call refers to a php function and they are harder to find out. So, most secure testing method is of course validating the expected functionality of your web-application.
Sercan Leylek / OSLO
![!![] = true](https://storksnestblog.files.wordpress.com/2017/09/screen-shot-2017-09-09-at-00-05-43.png?w=720)
