5 ms·

Can a fellow geek knowledgeable in PHP gives me a few pointers? I have inherited a 12 year old PHP app written by 2 interns. The code was written with Notepad+

• AdrianB1 6y ago
  IDE: Visual Studio Code with the PHP extensions, free. 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.
  • Osiris 6y ago
    I was able to convert a PHP 5.4 app to 7.1 but after that there are too many backwards incompatible changes to be easy to fix. Even the upgrade to 7.1 took a few days of tweaks to the code. 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.
  • jmnicolas 6y ago
    I know PHP is interpreted hence my comment "to have an IDE with a kind of "compiler"". 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.
• throw_m239339 6y ago
  > 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. 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.
  • uryga 6y ago
    > PHP8 isn't a different language, they just added some stuff on top of PHP5. 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`.
• dkarlovi 6y ago
  Roughly in the order you should do it. Hopefully it's at least PHP 5.3 code: 1. Definitely get a PHP IDE: https://www.jetbrains.com/phpstorm/ https://www.jetbrains.com/phpstorm/ 2. Get a step debugger and hook it in: https://xdebug.org/ https://xdebug.org/ 3. Fix the code style: https://github.com/FriendsOfPHP/PHP-CS-Fixer https://github.com/FriendsOfPHP/PHP-CS-Fixer 4. Run the code through some static analysis tools https://phpstan.org/ https://phpstan.org/ https://psalm.dev/ https://psalm.dev/ 5. Upgrade the code with an AST fixer (might help you update to newer PHP version): https://github.com/rectorphp/rector https://github.com/rectorphp/rector 6. Add tests to it: https://phpunit.de/ https://phpunit.de/ 7. Run mutation tests: https://infection.github.io/ https://infection.github.io/ The "0 budget" is rough, though.
  • AdrianB1 6y ago
    All good advice for the average PHP developer, but I think it is overkill for someone that is starting with PHP just to keep alive a very old app. Adding tests for an app with no documentation requires a lot of effort.
    • dkarlovi 6y ago
      Of course, that's why the list is sorted, he might never make it pass 1 :)
      • tpetry 6y ago
        Yes. Upgrading really old php application (v4? really?) to v8 is such a big step it will need much dedication, so many things changed between 4 and 5 its not easy. And even upgrading 5 to 7 may break so many things. I would not like to switch with him.
    • mgkimsal 6y ago
      > 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.
• deleted 6y ago
  [deleted]
• rossriley 6y ago
  Getting a copy of PHPStorm will make things much easier, you can run Reformat code on PHP files and you can also do mass updates from code inspections. Also worth checking out is a package called Rector (https://github.com/rectorphp/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.
• tehbeard 6y ago
  Do you have a staging enviroment you can use? 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 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 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.
• pbowyer 6y ago
  I've spent a lot of my career updating/fixing/replacing aging PHP apps, so here are some pointers: 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 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 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.
  • cblconfederate 6y ago
    Regarding mysql* i 'd guess it's probably easier to just replace it with mysqli_* calls. Only a few changes would be needed unless the app is doing something unconventional.
  • 6y ago
• thunderrabbit 6y ago
  While not free, Paul M Jones book Modernizing Legacy Applications in PHP has really helped me get control of a large old codebase. https://leanpub.com/mlaphp https://leanpub.com/mlaphp 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." https://github.com/phan/phan https://github.com/phan/phan
• deleted 6y ago
  [deleted]
• tim333 6y ago
  Given the 0 budget etc. you could perhaps as a compromise migrate to a recent VM but with an old PHP? (eg like https://www.howtoforge.com/tutorial/install-apache-with-php-and-mysql-lamp-on-debian-jessie/ https://www.howtoforge.com/tutorial/install-apache-with-php-...)
• sfteus 6y ago
  I maintain half a dozen PHP apps written for PHP 4-5, all of which now run on at least PHP 5.6, and a few of which I've gotten to PHP 7. Advice given by everyone else is excellent. PHPStorm is a must for me, one of the only pieces of software I pay for instead of using some OSS alternative. 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.
• juangacovas 6y ago
  As others pointed, the best thing you can do is learn to debug PHP interactively with an IDE (easier locally) so you can step, REPL and so on, into a mess of a code to improve it