 We're going to be talking about PHP 7CC and PHP compatibility. I had it snuck that one in, a couple of static analysis tools. Who here is running 7.2 in production? See a few hands, not too many. This tool is helpful for all the way up to 7.2. Both of these can help you helpful. So this will be very pertinent to everybody here. So I was like, other than Wim and one other person, so we're good. The talks are, my slides are posted online. If you want to follow along, see the examples, anything like that, the slides are posted on the join-in. All the coding examples that I have are posted on GitHub. You can also go and pull that down and follow along and look at the code and see what's wrong with it and why it's not compatible. So feel free to follow along. You have your laptops up, installing things. That's perfectly fine. I like that approach. As I mentioned, I run the Utah PHP user group. It's about 5,000 miles away. It's a long track, but it's good to come here. Left-flying drones, senior software engineer. We're going on a drug testing platform. I'm sorry if you've ever been fired for positive drug tests. Really, it's in the United States mostly, so apparently not someone here. But master's degree and so on. I learned yesterday that the Utah PHP user group's older than any user group in the UK. It was from 2003, so it's going to be by just a year. It's an early starting one. I did live up in Manchester for a couple of years. If you live in that area, come talk to me. I love talking about Manchester and the Lake District. So it was a great time I had up there. It was a while ago, but I lived there for a couple of years. This is where I live. I love flying drones. It's a drone picture. It's a nice mountains in some snow. And I'm going to say at the Western US mountains, not mountains. And there's open west. I flew my drone during lunch at open west to that picture. I was very happy with it. Good Salt Lake Valley there. It's a fun polyglot conference in the summertime. If you want to learn how to pick locks, that's a good one. We're going to talk about these tools. Anyone know what this is? Anyone know what this tool is? I see one hand go up. Any others? Anyone? Only one? I see a couple. OK, I see another hand. Someone want to be brave and tell me what it is? Yeah, a crimping tool for pex piping. So if you've never used one of these, it's a tool. I learned how to use it not too long ago with some plumbing in my house. A little leaking. Wasn't too bad, luckily. But you have a few parts to it. You have the main tool. You have these little rings that go into the tool. And you have this tool over here. It's a compatibility checker. It lets you know if what you're doing is right. It checks to make sure that you've got the crimp on right and that the plumbing is going to work. If you don't get it on right, you're going to have leaks. You're going to have bugs. You're going to have issues. So this is a practical, real-world example of where we have a compatibility checker. Something's used in plumbing to help prevent problems. We have the same thing for code. We have some tools that we can use to help prevent issues when we upgrade. So when you walk out of here, my hope is that you have a good understanding of why to upgrade to PHP 7, some of the important things there. If you're here for Wim's talk yesterday, he went much more in-depth than I'm going to go into. And primarily, you're going to know how to use these tools that we're going to cover. You should be able to walk out of here knowing exactly how to use them and be able to run them against your projects. You can even run it against your project during this talk if you'd like to. That's perfectly fine. And again, the slides are posted. The code is posted if you want to follow along, unjoined them. The slides are posted through the join-in. Why are these tools important? The main project I worked on, that drug testing that I mentioned, was a big project that started in PHP 4. So I had some very old styles of code. It was hundreds of thousands of lines of code. And because it was a legacy application, it had few unit tests. And upgrading it to 5 was a mess. Getting it to 7 was going to be even harder. Now, that project has made a lot of progress. It's gotten a lot of unit test added to it, behavioral test added to it. It's gotten framework as in framework on it. It's got all these different nice things. It was in Expressive. Also, these nice things coming onto it. But we wanted to move it to PHP 7. Again, hundreds of thousands of lines of code. There's no way to look at all those lines of code to make sure it's going to work. And the unit test didn't have complete co-coverage. So our unit test didn't have complete coverage. So there's a common struggle. Anyone in that kind of similar situation? It's very common, right? And then upgrading to PHP 7 was a task. As a developer, I had my project manager try to upgrade. And they didn't pick up an attraction. So then I tried to work with our customers, which happened to be a child company. But it was just kind of a funny organization. And that didn't work out very well. So I went to SysAdmins. And the attraction didn't pick up. They were busy with other SysAdmins things. So finally, as a developer, that responsibility fell onto me. The process I took was running these automated tests, these automated code coverage, running unit tests, and making sure that the code is compatible with PHP 7. And then we're able to move that along. And once I took ownership of that, it moved up very fast. Within a couple of months, we were on PHP 7.1 in production. So as developers, that's something you can take on to push to move to upgrade to PHP 7. Because if you don't do it, nobody else is going to do it for you, most likely. Here's a quick rundown, a quick overview of our agenda. Why upgrading, introduction to the tools, how to use the tools, we'll go into the options with them, some common issues, we're going to do some live demos. I've got an analysis that we're going to compare some frameworks around the tools against some frameworks. We're going to see how they're doing right now. And the CSV output of that, by the way, is on the GitHub repo. If you can run with it, do whatever you want on there too. And some considerations at the end. So why would we want to upgrade to PHP 7? And as we go through these different things, the focus right here really is identifying incompatibilities, things that are not going to work. If you upgrade to PHP 7 right now in production, it's going to break. We want to watch for those. We want to fix those. And we're going to talk about how these automated tools can help out. So PHP 7 is two to three times faster than PHP 5.6. That's very good, right? Your server responses are going to become faster. 30% to 50% better memory consumption than 5.6, and which leads to more requests per second. So our apps become faster. Our server load goes down. We start seeing some time saving, some money saving. Customers are happier. The server is responding faster. That's all good. Security, we have C Spring, which has random bytes and random ints. So we get some good cryptographically secure numbers. Libsodium was introduced into PHP Core in 7.2. It's the first, it made PHP the first programming language to have a modern security suite built into Core. So everyone that's laughing at PHP previously is no longer laughing anymore. So very good. It passed a full security audit and everything. It's a great, great project if you're looking to do any encryption at all, looking to Libsodium. MCrypt was kicked out because it's based on stuff that has been updated for a dozen years. So it was deprecated in 7.1. It'll be gone probably 7.3 or 8. Password hash lost its salt option. Yes, that was one of the worst things you could do. It's gone as good. It automatically does it now, and it's a deprecated. It's a gone function deprecated. Argon2, anyone using Argon2 on their password hashing? It's not the default yet, but it's available in 7.2. And it's better than Blowfish that's currently the default. So that's great. I'm not sure when it's slated to become the default, but it's coming up. We have scalar type declarations. This is one of the best features of PHP 7. So we have the ability to have scalar types. So we have int being passed in. It's forced as int. We have return types. We have something being specified on the return. That right there is bliss. It's so nice to have that. Levi Morrison did a lot of work on that one. He lives down the road for me. OK, about 20 minutes down the road for me. He did a lot of work on that, and he did a great job on that. It's a huge benefit for PHP to have that strict typed on the method returns. But this is one of the big catches. We have reserved class names. When we're trying to upgrade to PHP 7, if you have a class name int, or string, or float, or bool, or null, or true or false, they're all incompatible. So the compatibility tools are going to be able to pick up on these and catch those. As a 7.2, you can also add void to that list and object as deprecated. So this is something we'll get into whether the tools catch that or not. No colescing, I love the question-question mark. Basically it says this, if it's null, then do the second thing. That's what it basically does. Spaceship operator, Davey Shafik. This is his favorite one, the names is great. We have anonymous classes, we have generated return from expressions, exceptions, and errors instead of hard failures. Many more great features. We won't cover all of them. This isn't a PHP 7 focused as far as features, but just be aware of what's there and what could be incompatible with what you currently have. So I have the top three offenders list that we're gonna go into. Number one offender that I found when we were upgrading was classes that still had PHP 4 style constructors. So instead of having underscore underscore construct, it had the class name. That's a PHP 4 style that's long gone. If you have those, they will not work in PHP 7, it must be fixed. Number two I found was HTTP raw post data. Okay, anybody have that lingering around? We had some really old Sulp services that apparently still were using it and we had to go fix all those. Luckily it's an easy one fix. We won't be going into detail of exactly how to fix these. PHP.net, if you look up those specific things, it lists out exactly what the recommended replacement is. So just be aware of that. We won't go into exactly how to fix it, but we'll be able to identify them and know what needs to get fixed. Then you have the tools available to go and make those fixes. The third offender I found was static calls to non-static methods. Okay, so maybe a developer didn't notice or when they wanted to take a shortcut, so instead of newing up an instance of it, they just did a colon colon method. This is public, right? You can do that, it works. Well, okay, that's not how it was intended to be used. And in PHP 7, that's no longer available, it's deprecated. So that was a big thing that I found and had to watch for. Other things that are removed to be aware of, call user method and call user method ray. We have e-redge is gone. MySQL is replaced, either MySQL, I or PDO. Same with MS SQL, so use SQL server or PDO. PDO is recommended. Sit magic quotes, run times, set socket bind blocking, and so on. So we have a whole bunch of things that have changed or been removed in PHP 7. So if we're using any of these things, we have a problem that's going to need to get fixed. We also have short opening tags, ASP tags that are gone, and XDBug no longer supports PHP 7, or sorry, PHP 5. So if you're using XDBug, you upgrade to 7, you've got to upgrade your XDBug version as well. I gave a talk about that yesterday about XDBug. And most libraries are focused on PHP 7. I found, especially if you use Composer to install packages in libraries, a lot of them are starting to lose support for PHP 5 since it's no longer actively supported. It's in the security patches only. So these are the reasons why it's important to get this upgrade done. So PHP 7.cc is the first tool that we'll talk about. And we're gonna go to a live demo. So PHP 7.cc is a command you can run. It's available with Composer. You run it against a code base, and it gives you some output. So in this case, we see ArrayOrder, and it gave us a warning because it's a possible ray element creation during by reference assignment, okay? We have BitwiseShift going on. BitwiseShift by negative number, that's gonna fail. So it tells us exactly what's gonna happen. It gives us the line number. It tells us what happened. Here's constructor, right? So we have a constructor.php, and of course it's got PHP 4 style, naming on the constructor. It tells you that it's now deprecated. We have date formatting divided by zero. It's gonna catch a lot of these things. And these scripts were intended to be backwards incompatible things that it was running against, so there's gonna be a whole bunch of errors in here and that's expected. Ered's removed, right? So we see it's removed function. Ered's replaced, Ereg. Anyway, so you can see it gives you nice output. It tells you the line numbers. It tells you what happened. It gives you an error or a warning. There's also an info. Like here's MySQL. It's trying to do MySQL connect. Of course it's gonna error because MySQL's gone. So it tells you exactly what happened, what line it was. And so on, down the listing, it says C-split, right, removed. At the end it tells you how many files it checked. As a note, PHP 7CC gets a few fewer files than PHP compatibility because PHP 7CC defaults to only PHP files. And it tells you the amount of time it took. And we'll get into the analysis at the end too, or near the end on that. Okay, so now we've seen it. I like to start with kind of the live demo to get an idea of what it looks like and get a feel for it before we dive into it. I don't know the author's name of it. Anyone know the author's name? I have the GitHub name, but I don't have the person who actually did it. It's a standalone library available through Composer. Static of code analysis tool like we've talked about. So it's available just to run by itself at standalone. We get to PHP compatibility. It's a sniff for code sniffer. So that's the little difference there. It was focused primarily for upgrading to PHP 7, so it doesn't catch a lot of the PHP 7.1 and 7.2 things, but it catches a lot of the things going from PHP 5.3 to 5.6 all the way up to PHP 7. And again, it doesn't automatically fix things for you. That'd be so nice if it did, but that'd be really, really hard to make it do that. And it's really not too bad as a developer to go fix them. If you have identified the specific lines, you have a PHP.net reference to look it up, know what had to happen, and know what needs to occur to make that start working. To install it, Composer require install a slash PHP 7 cc. Dev is the default now, but you can do dash dash dev. And then to run it dot slash vendor slash bin slash PHP 7 cc and then the path or the specific file. If you add it to your path, using those commands right there, then you can just do PHP 7 cc and then whatever target you have. And that will give you that nice output that I showed you earlier. And so if you're following along in your laptops, feel free to pull it down and run it. Again, you can go target specific paths or you can target specific file using it. So we're gonna go over the options as well because that helps with display and determining what needs to happen. So the dash h or dash dash h is pretty standard. It gives you the help information. And it looks like that. We'll go through to these real quick so you're familiar with those. So dash e is extensions. As I mentioned, the default extension for PHP 7 cc is PHP, but maybe you have other files that have PHP code in them that are not PHP files. Then you can target those files specifically. So you change the extension to whatever that, you know, maybe PHP s and PHP files. Be example, it's comma separated available. You have accept or dash x to exclude specific files or specific directories. This is especially helpful for running it against vendor. So you're using composer again, then you have vendor and you can skip that directory. You're not gonna wanna run PHP 7 cc against your vendor directory, generally speaking, because it's, you're targeting your files, right? So you'll use composer to upgrade the packages rather than running compatibility checkers against vendor code. You have the level. So the default is the info and everything above that. So info, warning, message, and error. Or warning, error. You can change that if you want. If you wanna see the infos and don't wanna see the warnings, you just want the, maybe just errors. So generally, you're gonna wanna look at least through all of them at least once. Just again, it makes sure it's gonna be compatible. Dash R is very helpful. It gives you relative paths and cleans up the output. When I showed you the demo that had dash R in it. So instead of having the full path to the file, it's gonna have the relative path from where you're at the command line or terminal. So much cleaner output, much easier to read. Not necessary, but helpful. Inager size, used for bitwise shift checks. You have dash O output format. This is really helpful if you wanna, if you have a lot of files and a lot of things you need to go change. It has the option for JSON format. So you can take that JSON, grab it in some PHP code and code it and do some things with it, for example. Maybe you could have it create tickets automatically for all the changes and you can go and hit those, maybe create user stories or defects against that and go fix all those. An example that might be going a bit overboard but if you have a very large product with a lot of issues, that would be a good way to get to use of that. So it's nice to have the JSON format. You have a quiet mode which runs without outputs. So if you have a very large project perhaps that you don't wanna have, it's killing it basically when the process is running, it would be an option to quiet that down. Dash B gives you the versions. You know which version you're on, but Composer's gonna tell you that too. My case is running with 1.2.1. ANSI forces ANSI output for pretty colors if you're in the terminal. Or no ANSI if you wanna turn it off. You different verbose levels, defaults to one. So there's a quick introduction to the options with that tool and we'll jump over to PHP compatibility. We'll go back to it and we'll do some comparisons back and forth comparisons with comparing these two different tools. So PHP compatibility is another tool. It's RAM and come back up here. So it gives you a different looking output. As it runs along, if you have the progress on, it gives you, it looks like we're running a bunch of unit tests. It looks like that similar output. It gives ease for errors with W for warnings. You can kinda watch that, especially on a bigger project, otherwise it just sits there, you don't know what's going on. Let's tell you exactly what's going on as we're running. It tells you the file, it was ran, it was checked, it gives you the number of errors, the line number. So we here, see here this one's got the best, a bit wide shift operators by negative number. So we saw that with the PHP 7CC. Okay, so it did catch that same thing there. You know, it's gonna give you multiple errors. You have the two line two, line three. Give you a similar description as PHP 7CC. So we see it's telling you what happened and why. And you can go through this. The output can be very large. If you have a very large project, you might wanna pipe it out to a file or something. It's all big output. It tells you the time it took and the memory used. So you can use that. If we'll go into the comparisons, we'll see which one's faster. Any guesses yet? Which one's faster, anybody know? Anybody wanna take a guess? Well, maybe in the second one. See the PHP compatibility out here. We'll get in that, we'll see, we'll see. They have different strengths and weaknesses. So it's interesting to see which one's gonna pull out. We'll get into that. PHP compatibility, primarily written by Wim, who's sitting right here in the front. So thank you for your contribution to the community with that one. It's a SNF for PHP code sniffer. So if you use code sniffer for sniffing code to check for coding standards is what it's typically used for. So if you're running PSR, back in the days, pair coding standards. And you can run these different SNFs to make to ensure that code meets a specific standards. Maybe it's tabs versus spaces and the curly brace on the new line and indentation, all these different type of styles and standards. So you can add different SNFs into it. So code sniffer, you can add different SNFs. You can customize SNFs and these SNFs can all be configured to run together against code. Often used as like pre-commit hooks. So committing your code up, you just gotta pass the SNFs before it can be pushed up, for example. Again, it's a static code analysis. It's not gonna fix the code for you. And it's used for upgrading from going all the way back to PHP 5.1 all the way up to PHP 7.2. So it has wider covers in PHP 7CC. It goes back previously a couple of minor versions and goes forward a couple of minor versions ahead of PHP 7CC, so wider range. It also has the ability to specify where you're at and where you're going. The simple install, Composer fire, PHP 7 essentially, and you also have code sniff installed for setup. These three will get you there help you build and run it. If you only have one SNF, you can set it to have the install pass, you can copy and paste that. You can check which SNFs you have installed, it's PHP CS for code SNFr dash dash config show, and it'll show you a configuration. And then you run it, similar to PHP 7CC, if you don't have a new path, dot slash, full stop slash vendor bin PHP CS, and then coding standard equals, and you tell it the coding standard, you can run, if you leave it off, it'll run all your SNFs, if you specify it, if you didn't specify it in the configuration, you have to specify it there. And the target. If the bin is including your path, then it's just PHP CS by itself. And again, if you don't specify the standard, it's gonna run all of them. So, we're gonna go over the help for this tool as well. We'll go over all of them, but we'll go over the ones that are applicable to coding or to upgrading to PHP 7. So, you have N, which is your warning severity. You can turn off warnings, you see errors, so it kind of gives you a check in there. You have W, show errors and warnings, which is the default values, you generally won't ever use that, but you can. You have local directory only, which doesn't go recursively. This one's very helpful, if you wanna check a specific directory, but maybe you don't wanna run it against the entire project at that time. Especially if you have a large project, you wanna just check one directory at a time, or you have it broken apart, right? So maybe you're hitting your PHP memory limit, and it's crashing. You just wanna go one directory at a time, perhaps. This is a good option to use there. So just check it without going recursively. Dash S gives you the SNF codes. So if you look here, it says PHP compatibility, forbidden switch with multiple default blocks, okay? So if you look, the file name is switch multiple defaults. So you know that that point, that that's the SNF that picked it up, and you can look at that SNF and compare it with what you have and understand why better. So it's very helpful for understanding why something's not compatible. Gives you a little bit more information that you might want, might need. Interactive mode. For this one, I wanna do a quick live demo because it's easier to show than to explain. It basically gives you the ability to interact with the process, with the progress. So it gives you a hit enter to recheck, S to skip, or Q to quit. So if you hit enter, it's gonna recheck the exact same thing, and it's gonna tell you it's not fixed, and it's gonna ask you what to do next. So then you can switch over to your IDE, you can make the fix, hit enter again, and if it's fixed, it'll go on to the next one. So this one's really helpful if you're working through code, you're just gonna step through one by one, right? You're gonna fix it, go to the next one, fix it, go to the next one, and then you don't have to fire up the tool every single time, so you just step through and fix them one by one. So very helpful tool, S to skip, it'll just go to the next one, right? Until you fix that one, and then Q if you wanna quit out. So that's interactive mode. Again, I like that mode, it's very helpful for working through a project and fixing your code to make it compatible. Dash ease to explain the coding standard. It tells you the number of SNFs, so it's got 67 SNFs. So you know it's gonna fix about 67 different incompatibilities, okay? It's giving you an idea of what's going on. It's got a generic SNF, it tells you, and it doesn't list all of them, there's 66 right there that it goes through and it has, it's gonna run against this. Or it's breaking it apart, it creates tokens and figures out the code and then runs those SNFs, checks for patterns. Dash P shows the progress, I mentioned that one earlier, where it gives you a, it's a little hard to see the green, but it gives you a PHP unit looking progress on there. It tells you the number of files, it tells you the percentage, it tells you when it's hit an error or a warning or whatever other issue you have pop up. So it keeps you up to date on where you're at. Quiet mode, we saw that with PHP 7CC. Disables the progress and verbose output. If you have memory issues, that might be a helpful thing. Dash M, stops the memory error messages from being recorded. Maybe if you're using a really large project and you just don't want them outputted. But you got to be careful with it too. It's gonna trigger some different cascading issues. List files processed. This is dash V. This is very helpful, just if you want to ensure what happened. It's gonna tell you the, what's processing, the number of tokens. So the tokens basically is the, the PHP compiler is breaking apart the PHP code and has to interpret it. So it's telling you it's 59 tokens and 11 lines and so on until you remember errors and warnings. I use this to grab the analysis stuff at the end too, the comparison. Dash VV prints the rule sets. So you can start going to the tokenizing and see what's happening. So we see a beginning of PHP tag. It's got a class, static calls, curly brace bracket, public. So it goes and breaks apart the PHP code to give you a better understanding of how that SNF is working exactly. It's helpful for debugging, it's helpful for understanding what exactly is going on. The dash VVV, so it's very, very verbose. This is a debugging mode. Gives you some more information. We probably won't need that before we're doing here. Dash I gives you the installed SNFs. So you know what's installed and what's gonna be running. Dash D gives you the directives. This is very helpful. You could add like memory limit, for example. So maybe you have a large code base again, but your memory limits maybe like 128 or 256. But it's gonna run and it's maybe gonna take 600 megabytes to run. You can do a dash D memory limit, increase it to 1024, run it again, it'll work. You won't hit that memory error. That's one I had to use quite a bit, especially in large projects. There's other options available. We're gonna go into all of them. Well, those are the ones that are most applicable to what we're trying to do here. It's common issues. As a developer, we wanna have our error reporting cranked up. We wanna see those deprecated flags. We wanna see those warnings. We wanna see those errors. If we don't have that on, and we try to run the code, we're not gonna know that it's not really fixed. These static code analysis tools do not pick up everything. You're still gonna have issues. It's not perfect. Some of the patterns are too hard to recognize automatically. By having our error reporting turned on, it helps us indicate, and if we're watching your logs too, of course, it helps indicate where the problems are and help track them down. Unit tests, this is a common issue. The unit tests and functional tests really help, but it's kind of a double edged sword. Often with older projects, they're not gonna have unit tests, right? And they probably don't have dependency injection and other techniques to help with testing. So that's another item that's very helpful to make sure your application's gonna run after upgrading is to have those automated tests to ensure the functionality and the codes working. You can also pick up on those other areas that may not automatically be caught by the compatibility checker tools. Again, the common issue, if you're trying to fix the vendor directory, it's not the right approach. We wanna use Composer to upgrade that, so we wanna tell Composer, and I'll upgrade these packages for PHP 7.1 or 7.2, whatever we're upgrading to, and let Composer handle the dependencies and do the upgrades for you there so you can just ignore the vendor directory. Most, the vast majority of the time, you should just be ignoring that on your code sniffing or code checking. PHP 7.CC does have an infinite loop error that I've run into a few times, and they don't appear to be fixed in that anytime soon. So if you run into that, you start having to do accept the skip, basically. So you'll see where it's at, and you figure, okay, it's in this directory, we're gonna skip that, and you have to run one file at a time and narrow it down until you figure out which one exactly it's failing on. So that's gonna have a heads up. That one does where it's had occasionally, and just be aware of that backwards compatible code. So, for example, a framework might say, you know, if this is PHP 5.6, then do this, if it's PHP 7, do that. So you don't wanna go changing those. Of course, those are gonna be mostly in the vendor directory, but maybe if you run into your code where it's doing that, I'll just keep that in mind that you, if you're upgrading to PHP 7, you can go to remove those backwards compatibilities. You're not gonna need those anymore, but they may have been in there for a reason, right? So that the code could work on an older version of PHP, for example. So that's a common one that is seen. The analysis. So, again, I posted this all online already on GitHub. It includes a spreadsheet. I ran this with PHP 5.6, going to PHP 7.2. 49 files were examined for this. To create these files, I went through all the compatibilities, the backwards incompatibilities, the deprecated things on PHP.net, and tracked them down, made a file to replicate that. So I had 49. Some of them have multiple issues with them. If you looked through them all, I would not recommend using any of them in production. They are all bad intentionally. Snapshot of what I found. PHP CS, which is the PHP compatibility through PHP Code Sniffer. Had a total of 33, which is a sum of errors that were found in that small code set. I had four warnings compared to PHP CC, which only found 30, but found six warnings, okay? So, little difference there. They're fairly close, but there are some differences. PHP compatibility found a total of 23, 23 files that had problems in them. So that's what the count refers to, is the number of files that have problems. And three of them had warnings, whereas PHP 7CC found 27 and five, so a little different. The unique ones, so this is where there was a file that had, for example, an error in it, that none of the other three warnings errors showed up on the other columns. So PHP compatibility had the most unique ones, or equal, that had four versus the errors versus four warnings of PHP 7CC. So they're not catching the same stuff, are they? There's a discrepancy there. They're different. And that's okay. The good thing is they're both open source. We can use them both. There's a quick little pie chart, because pie charts are amazing, and they make cells and all sorts of stuff. PHP 7CC, again, this is just a pie chart. They thought it'd be great. We kind of see that the errors are most common. The warnings are gonna be smaller that they pick up on. The warnings are things that you may or may not need to fix. Most of the time you do have to fix them, but not always. The errors are things that are absolutely just gonna break. Okay? So here's an overview of those files when I ran that. So we have, and the names of the files reflect the problem with them. So we have extra parans, we have a foreach with a pointer in it, funk, get, arg. So we see that the different checkers found different things. Okay, this is where the stats come from. Kind of interesting that they pick up on the same things most of the time, but there are some differences. And I coded these to the best of my knowledge. So maybe it wasn't a perfect example. Maybe that's why they didn't get caught. That could be, or it could be that the pattern is too hard to catch. So that gives you an idea where we're at with these ones. The next set, HTTP raw post data, they both found that one pretty easily. Int does a class name, they both found, for example. Invalid octal, they both found. JSON to JSOND was changed. I didn't catch that, empty JSON string, for example. mcrypt deprecated was deprecated in PHP 7.1. So we would not expect PHP 7.cc to catch that. We'd be an example of where PHP compatibility is gonna be a major benefit to get you all the way up to 7.2. MS SQL, MySQL, both those pick those up and so on. It's kind of funny to read through it and see which one's picked up what. A little competition between the two compatibility checkers. Here's the next set, we have static calls, right? So this one I mentioned, neither of them found it. I was kind of surprised. That's probably a hard one to see when he's thinking about it. He's thinking about it. Why wouldn't it catch that? Yeah, it's a hard one. You'd have to analyze what it's trying to call into. So it may not even be the same file. It could be a completely different file it's trying to call into and so you just don't know. Which is again where the unit tests and stuff come in much more handy, even if it's a Selenium or clicking on things test. Switched multiple defaults where it was caught yelled with parentheses, kind of surprised that PHP 7CC only picked that one up. PHP 7.1, so these are PHP 7.1 specific items and these are PHP 7.2 specific items. So dynamic calls was picked up by PHP 7CC which just kind of blew my mind because it wasn't written for PHP 7.1. But we see that PHP compatibility did pick up on more things of course than PHP 7CC did in the 7.1 and 7.2 realm. Which is expected and that's good. It tells us that we want to use more than one tool. One tool by itself will get us a long ways. But if we can run multiples, it might get us 95% with the first tool and then the next one's gonna get us the next or a few percent closer. A few more, they both caught the object. Again that's a 7.2, PHP 7.2 but PHP 7CC kind of caught it, so it's kind of surprising one too. And there's where the stats came from. Timing, so I ran this on a very large project. It had 2,364 PHP files. Okay, so very large project, larger than the most, not huge, it was bigger of course, but it's a good dataset to run against. PHP 7CC took 276 seconds. PHP Compatibility took 271, so it came in pretty close. PHP Compatibility was just barely beat it out. Not by a ton, so they take about the same amount of time as what I found. Okay, everybody have you cashed that? Okay, which framework's gonna win? Any guesses? So I did it against Zend, Slim, Symphony, Laravel, WordPress. Any guesses which one was the fastest? Laravel? I'm hearing maybe Slim was the fastest. Which one do you think had the most problems? Hmm. And remember though, it may not be that it's a bad framework or has problems, it could be that it has backwards compatibility built into it. So that's a big caveat with that one. It may be in there intentionally, and that's okay. So, Zend Framework, won with 330 backwards compatibility issues, but it ran into the infinite loop error, which PHP 7CC, so I couldn't ever finish it. Okay? And it had 2,300 files. Symphony with 3,700 files only had 34 issues. That's impressive. That's pretty good, okay? PHP 7CC, and that gives you a timing too of how long they took. So generally speaking, we found PHP 7CC was faster. On the big project I ran, it was slower, but on the frameworks, PHP 7CC was slightly faster. It's not a huge difference though, just a little bit. To run this, basically what I did is I just used Composer to require those frameworks on a project by itself, and then I ran the tool against that directory that it sits in, entire directory. So we see Slim with only 46 files, of course, was the fastest. It had no PHP code compatibility issues. It only won that PHP 7CC caught. Pretty good. That one ran really fast and was quick. Wordpress. Took the longest, not too surprising. It has fewer files, but it must be bigger. It had 302 compatibility issues. 177 PHP 7CC issues, but as I mentioned, these could be intentional. So we can't just judge a framework by its stats in this case. Because like I said, often we'll see like the PHP version is this, then do that, and so it'll still pick up on those even though the code is specifically identifying which version to do. It may not necessarily reflect an issue. So that's again, that's a big caveat with these stats. Any surprises in there? Anybody's surprised, anything like that? Kind of interesting to run it against the frameworks and see where we're at. So what we're gonna do next is I need one volunteer, a lucky volunteer to tell me a package that he would like to run this against. We're gonna do a live demo. Anyone? What's the package he's like to run this against? Any packages you wanna run this against? Behat, okay, okay. So now we have Behat. So we're gonna run this, let's install Behat. I have my debugging on, don't I? Okay, so now we're using Composer, we're installing Behat. So I just wanna demonstrate how easy it is to run this. So we installed, so we have Behat there, okay. So we're gonna pop back over here and we're just gonna change this. We're gonna run PHP 7CC and that's gonna run it against a vendor Behat, okay. So run PHP 7CC against Behat. We'll see how it does. Then we'll run PHP Compatibility against it. So I wanna do this because we wanna, well see, this is something we can do. This is an easy, these are easy tools we can use to run against and see what's happening. So that's gonna take a couple of minutes here to run. We have a, I'm not sure are there. It found nothing. That's impressive, it found nothing. That's a Behat, wow. That was a, that's a robust project. They are on top of this apparently. Let's try it with, let's try it with this other one. So we'll do the same. Okay, I might need another project to run this against if it's gonna be that good. We could run it against PHP unit. That might be a, that might trigger a few more. I don't know, though. Only one, okay, so no PHP code was found on this file and open tags are not allowed, okay. So it only gave us one. Okay, so that was pretty good. I think Behat, that's impressive, that's amazing. Oh, we got interactive, don't we? That's what it was, okay. We'll run it again, take off the interactive, could call them. Okay, so there we go, yeah, that's what I was expecting. All right, so 731 files, we see the progress running. So here, this is probably an example of a project. We could do this and say installs an older version of it and it'd probably have a lot of problems. But in this case, it just has that one warning. They weren't told us where they had it. Any other projects you wanna try it on? Try Drupal, I heard. Even though, let's see, even though it was exactly which one it is. What? No, Drupal, that's Drupal. Why did it pull up when it did Drupal, that's weird. Okay, so we'll do, Poser, install require Drupal slash Drupal. Okay, so we'll run it against Drupal. This will be the last one we'll do. And again, if you have your own project, run it against your project right now. Let's see what you find. Kind of interesting to see what we get here. So we're downloading in Drupal. We'll run it against there and see what it looks like.