1. Definitely get a PHP IDE: https://www.jetbrains.com/phpstorm/
2. Get a step debugger and hook it in: https://xdebug.org/
3. Fix the code style: https://github.com/FriendsOfPHP/PHP-CS-Fixer
4. Run the code through some static analysis tools https://phpstan.org/ https://psalm.dev/
5. Upgrade the code with an AST fixer (might help you update to newer PHP version): https://github.com/rectorphp/rector
6. Add tests to it: https://phpunit.de/
7. Run mutation tests: https://infection.github.io/
The "0 budget" is rough, though.
- Make sure you have version control. So easy to do these days, so often forgotten.
- don't think that the steps above must be done in order, right now.
- dkarlovi mentions tests. Start with 1.) smoke tests like simple selenium tests or something like that. You'll find lots of vate towards it if you look and I admit it has issues but for simple projects like this that doesn't change much it should be fine. Of course of you find something better use that.
- one of the most important things about a good IDE is being able to refactor confidently so you can rename variables to something reasonable as you figure out what they really are.
- the book "refactoring legacy code" might be the best programming book I've read.
"Working Effectively with Legacy Code" is the name. The author is Michael C. Feathers I think.
My basic procedure when inheriting legacy code is:
- Load the project in phpstorm
- Perform autoformatting so it becomes readable
- Run code inspection to find any obvious issues the original author missed
- Write tests in phpstorm, if not already exists
- Run the code with xdebug, step through it
Adding tests for an app with no documentation requires a lot of effort.
code tests yes. Assuming it's a web app, probably not too hard. Get something that records the browser interactions, and do the common tasks people do (log in, click links, make a report, etc). Having general things like that automated to ensure you can run them repeatedly to make sure basic stuff didn't break unexpectedly will help provide some confidence when making changes.
As others said, vscode with php extensions works quite well (you do need a local php install for intellisense to work iirc?)
As for migrating. I wouldn't aim for 8, that's a hell of a jump to make from 4/5 and just getting to 7.x would give you a few years of breathing room https://www.php.net/supported-versions.php .
First goal, get it working on 5.6 without any deprecation errors or notices, that's a good basis for a "legacy" codebase to be on.
From there, the hop to 7.x is mostly changing any mysql_* calls, avoiding the short tags (use `<?php` instead of `<?' and a few other things found by looking at the migration notes here https://www.php.net/manual/en/migration70.php (other version notes available from the menu on that page).
As for tooling, Rector, phpstan and Psalm might be helpful, but might be more trouble than their worth if you've only dipped your toe into PHP development. Rector can do automated refactoring with some code (helpful for the mysql_* function removal/replacement with mysqli_* for instance). phpstan and psalm are static analysis tools that can help find problems or issues with the code.
Final comment, make sure this is in version control so you can track any changes made and have known working versions.
It gives examples and goes bit by bit through the process of organizing code.
I'm using its suggestions along with a static checker called Phan, which I chose because it attempts to "prove incorrectness rather than correctness."
0. Ignore PHP8 for now. There's much more community support for PHP7, so fix it up to work on PHP 7.4 first.
1. My first task is always to use a code scanner to test if the codebase is PHP7 compatible (or PHP 5.6, or the next version on from whatever you're running). See https://blog.fortrabbit.com/php-testing for an incomplete list (I've used others but haven't got my bookmarks to hand). You'll get false positives but also a good feel for whether there are serious issues.
2. You don't say if it's a CRUD app or an API. If it's the latter: set up a PHP 7.4 box (with a copy of the datastore) and route all traffic to the current production box and to the copy. Save the responses from both and compare they're the same. A simple way to see if the app will work on PHP, and when you find something that's broken, you can fix it, reset the logs, and try again. Hard(er) to do with CRUD, but I have compared the datastore contents before to check they're the same.
3. Needless to say, stick it all in source control if it's not already.
4. For your own sanity, run a code formatter over it if the code is messy.
5. I like PhpStorm as an IDE. It's not free, but the intellisense and refactoring support (and the built-in debugger) are timesavers.
6. Assuming it's not global variables everywhere, that they've used functions/classes(!), then as you fix bits of the code rename the single letter variables and add comments. PhpStorm can refactor variable names, so you see what will change before it happens.
7. If the code's using mysql_* functions, which aren't present in PHP7, there's a shim to make them work: https://github.com/dshafik/php7-mysql-shim
8. Good luck! I like unpicking codebases like this and keeping them running. As a sibling commenter has said, it's an internal system so assuming staff are not going to exploit any vulnerabilities or you have guarded against those already, there is no problem keeping it running internally as-is. So long as you can still recreate the VM from scratch (I have had old packages disappear - now that makes for an interensting disaster recovery plan) and reinstall everything you need should backups fail, you're okay.
Correct, it's not free, but there is a 30 day trial. And... if you want to try it past that, it's $9/month on month-to-month pricing. For anyone working in "western" economies, it's near enough to free to at least give it a trial for a few months. The other 'big' competitors - vscode and probably... eclipse - both can provide value, but I've found the JetBrains stuff provide a much nicer out of the box experience for most PHP folks getting started out that that $89/year or $9/month to try is almost a no-brainer. But have also had people disagree, and almost always spend more than the $89 of their own time (or their company's time) getting VSCode set up with a collection of plugins.
Also worth checking out is a package called Rector (https://github.com/rectorphp/rector) which will automate a lot of this by scanning the codebase and providing diffs so you can upgrade safely.
There is your problem. If it's runs on PHP5 (<?php phpinfo(); // in a php page), it might run without hurdle on more recent versions of PHP... or not, but PHP8 isn't a different language, they just added some stuff on top of PHP5. C extensions might break though, because yes, PHP relies heavily on them as the language is too slow to do anything meaningful like writing a database driver.
there were some backwards-incompatible syntax changes between PHP 5 and 7 though. a client once switched on PHP 7 on his ancient WP website and it stopped working altogether because it used some weird no-longer-supported form of `new Foo`.
Compiler: you are looking in the wrong direction, PHP is interpreted. There were some compilers, but it's not what you need.
Converting to PPHP 8: do you need that? what are you trying to achieve? You can keep the app another year or so it it is working, don't fix what is not broken. There is no way to convert to 8, you need to rewrite it, PHP become more object oriented with each version and that is a paradigm shift there is no converter for.
In my case the upgrade was demanded by security because the latest PHP5 release is no longer maintained.
For an internal app you're much better off just leaving it on PHP 5. Maybe add an op-cache for performance.
What I would like is an IDE experience: everything that isn't PHP8 compliant is underlined in red so I can fix the thing without launching the app every time and see if I broke something.
One thing on automated tools: getting a good result is decently tied in to the structure of your project in my experience. A common scenario I've seen is projects relying on requiring other files as part of their business logic (IE, parent file A includes file B that processes and renders content vs file B including file A that defines helpers and what not). This is especially common when projects use something like index.php?file=whatever for URLs. Most automated tools and IDEs will struggle with this and false-flag undefined variables, etc, because there is no hard include path. There are a lot of ways to resolve this but it depends on your project.
Also, PHP 7 is much more aggressive about warnings on types and various other things. Unless you adjust your error reporting settings, you'll likely see a ton of these when you finally switch. I personally enable them on dev so I can clean them up, and keep them reporting to Rollbar on production.
I have inherited a 12 year old PHP app written by 2 interns. The code was written with Notepad++ (no IDE), no comments except when they copy pasted something from the internet, most variables are single letter and it's the biggest spaghetti bowl I have ever seen.
To add insult to injury I have no experience with PHP (apart from peeking at this code to fix a minor bug here and there). To be fair the app works OK and has done the job for all those years.
This app has never been updated so it's PHP version 4 or 5 I think, it runs on an old Debian 5 VM, it's not facing internet, internal use only. It was supposed to be deprecated last year, but now given our budget (or lack thereof) and the sheer incompetence of our new provider I don't see it happening soon.
Is there a way for me to have an IDE with a kind of "compiler" that would help me convert this to PHP 8 so I can migrate it on a more recent VM? Of course there's 0 budget for this.