
Ask Slashdot: What's the Best Way to Transfer Legacy PHP Code to a Modern Framework? 112
Slashdot reader rzack writes:
Since 1999, I've written a huge amount of PHP code, for dozens of applications and websites. Most of it has been continually updated, and remains active and in-production, in one form or another.
Here's the thing. It's all hand-written using vi, even to this day.
Is there any benefit to migrating this codebase to a more modern PHP framework, like Laravel? And is there an easy and minimally intrusive way this can be done en-masse, across dozens of applications and websites?
Or at this point should I just stick with vi?
Share your thoughts and suggestions in the comments.
What's the best way to transfer legacy PHP code to a modern framework?
Here's the thing. It's all hand-written using vi, even to this day.
Is there any benefit to migrating this codebase to a more modern PHP framework, like Laravel? And is there an easy and minimally intrusive way this can be done en-masse, across dozens of applications and websites?
Or at this point should I just stick with vi?
Share your thoughts and suggestions in the comments.
What's the best way to transfer legacy PHP code to a modern framework?
vi is an editor, not a framework (Score:2, Funny)
vi is an editor.
Laravel is a framework.
Looking at them as alternatives makes no sense.
Here's my advice:
1. If you want to modernize your site, consider something other than PHP. PHP is great if you need to slap a website together in a weekend, but it doesn't scale well.
2. You should switch your editor to Emacs.
EMACS (Score:2, Troll)
Re: (Score:1, Troll)
And that old and outdated OS with a crappy text editor-like GUI still sucks donkey balls.
/ ducks
Re: (Score:3, Informative)
Re: (Score:2, Interesting)
Hmm, well some of my PHP websites are serving millions of pages a day, so your "scaling" argument is just false.
Sorry, I was unclear.
PHP can scale loadwise.
It doesn't scale to more complexity and bigger development teams.
Re: (Score:3, Interesting)
Re:vi is an editor, not a framework (Score:4, Informative)
Meta would beg to differ.
Nope. Meta agrees with me.
Meta uses "Hack", which is a modified, type-safe language based on PHP.
Meta fixed some of the things that make PHP hard to scale. They wouldn't have done that if they believed vanilla PHP was good enough.
Hack (programming language) [wikipedia.org]
Re: (Score:2)
Today it is much faster (eg. it does include JIT), flexible (eg. anonymous functions as first class construct), consistent (in every release a few warts get corrected), and safer (allowing more type hinting but also readonly attributes, enums, etc...).
Re: (Score:2)
Re: (Score:2)
Re:vi is an editor, not a framework (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2, Flamebait)
Re:vi is an editor, not a framework (Score:5, Insightful)
If your PHP code works on the current version of PHP (at least 8.3 at this time of writing) then do not change anything.
If your PHP code does not work on the current version of PHP, consider why you're using PHP. PHP is good normally because it doesn't make micro-breaking changes frequently. PHP is bad however because the changes it make more align it with just being C++, which is what ultimately destroys the usability of scripting languages.
Every single time. This also why Perl fell out of fashion, Perl is fine, and then you update Perl and you have to update 10,000 dependencies on C libraries that also break. This is also what is happening to PHP, Ruby, NodeJS, etc. PHP has the least amount of dependency hell out of the box, having not been built that way, but even then, the developers of PHP make changes that inexplicably depreciate functionality for no damn reason.
Re: (Score:1)
Re: (Score:2)
Ahem, you are correct in that vi is an editor but emacs is definitely a framework, multifunction printer, tea timer, flight sim, virtual machine, and operating system... and it isn't worth a damn as any of them. About the only thing it isn't is an editor.
Re: (Score:2)
That last line was the joke I was looking for.
Re: (Score:1)
I tried, but the vim/vi key binding is broken :( ...
Sadge
You're my twin, no joke (Score:5, Interesting)
I have done exactly the same thing, also since 1999, and I've also been faced with the same issue. My conclusion is that the benefit of continuing to understand all of my code is greater than the benefit of attempting to standardize it with someone else's framework. The problem with using a framework is, in my opinion, (1) not understanding fully how it works, and (2) not being able to just take a blank file and write a script into it-- and (3) what if the framework falls out of favor or someone pulls the plug on supporting or updating it? There is no substitute for being able to hand-code PHP from a text editor, which results in a deep understanding of the LAMP stack and many other benefits. Lately I have hired a new software engineer and tasked him with learning this method of writing code, and he says it's a wonderful experience because now he understands how a web application really works. I also have code that has run perfectly for many years, and it would take a lot of person-hours to convert it. So my vote is no, don't bother transitioning your code to a framework.
Re:You're my twin, no joke (Score:5, Interesting)
I concur 100%, well said..
Using a framework basically hides the core, low-level functionality from you, and forces you to follow their 'plan'. Oftentimes the 'plan' is shit.
I tried lots and lots of frameworks and never found one that didn't constrain me from doing what I wanted- and sometimes that was just to open up a blank page and start writing code. Add to that all the overhead many of these frameworks drag with them and it just becomes a bloated mess.
Yes, I'm old school (and old!) but as you mentioned, "there is no substitute for being able to hand-code PHP from a text editor". That's how you gain a real understanding of what's happening instead of blindly typing make_table() or get_user_info().
Writing the functions yourself will always teach you more and you can tailor them so they work the way you need them to rather than what some dev on another continent thinks it should.
Re: (Score:1)
Re: You're my twin, no joke (Score:4, Insightful)
Frameworks are useful once your team grows to 4+ people - at that point it is much easier to bring newcomers up to speed with a framework, and much easier to help other projects that use the same framework.
So, no, there is zero reason to switch over the projects to a framework for the projects themselves; but there might be merit to do it for your contracting biz ðY(TM)
Re: You're my twin, no joke (Score:1)
Maybe not directly relevant, but I'm reminded of slightly mate's recent blog post that some might find interesting:
https://infrequently.org/2024/... [infrequently.org]
Re: (Score:2)
I'd generally agree with this. I'd add that moving code such as yours to a framework really just doubles up your problem. That is, the language gets updated, so the framework gets updated and now you've got to understand both sets of changes to update your code to make it work. Hopefully the framework insulates you from a lot of the language specifics, but won't do it all.
I'd say a framework is good if it's offloading a lot of the work for you. PHP is somewhat unique in that it's already HTTP request/respon
Re: (Score:2)
I agree with you (and with your life experience), without being a PHP programmer.
I have written tens of web sites or components over the years. Started off with Perl (CGI.pm), then moved to the way-way-faster Apache mod_perl. No frameworks to speak of, although I used several templating engines.
My favorite language changed for many reasons to Ruby. I wrote several systems/websites using Rails.
But my systems... Tend to be kept running for many years. I still have at least one mod_perl system in production I
Just rewrite it (Score:1, Informative)
Re: Just rewrite it (Score:3)
Always consider the fact that a framework comes with a lot of overhead.
Re: (Score:2)
In many cases a framework comes with a lot of functionality you don't use, you might use 10 features out of a 100, add to it that some frameworks adds a dependency to certain other libraries like database libraries and they will in turn lead to some extra overhead.
In the long run you also enter into version dependencies making it harder to upgrade.
Re: (Score:3)
Why switch? (Score:5, Insightful)
If your code works, and is well-written, and you understand it, and it's easy to modify, what is the point of switching?
If any/all of the above is untrue, then yes... maybe you should switch. But then you might as well switch to a better language than PHP.
Re: (Score:1)
Re: Why switch? (Score:1)
There certainly are benefits to a framework, though it just comes down to the individual situation. If you are a one person show, there are less benefits. Its not worth the hassle of rewriting a lot of stuff for the sake of doing it.
The benefits of a framework are that they include a lot of code thatâ(TM)s boring to write over and over again. Like authentication. Also if you want to hire people they will see more value in getting a framework on their resume than bobs homebrew code. There is also the be
Re: (Score:2)
Well, first things first, double-check any ancient PHP that's still active for security issues. Most of the changes in the last 25 years have been because of exposed vulnerabilities.
Next, if you are still doing PHP for new projects, then next steps depends on if one of those projects is relatively simple.
If it is simple, then just write it with the new frameworks (and I'm on the VSCode side as far as the editor goes).
If it is more complex and you need to get a handle on the frameworks, then just pick ONE le
Re:Why switch? (Score:5, Funny)
Yes, stay put.
If vi isn't the answer, you asked the wrong question . . .
hawk
Why add a dependency to your codebase? (Score:2)
+1
If your old code works, is safe to resist to current threats (ex: XSS), and has to continue to work for a long time, adding dependencies might not be the best strategy. You'll have to keep your code with the evolution of the framework, and hope for the maintenance of the framework to be provided for how long you will need. Are you ready for the death of that framework in 2-5 years? What will you do when that happens?
Let old code die... (Score:1)
ive experienced this first hand... (Score:3)
someone i was working with build a very successful SaaS with freehand PHP without a framework, but it was clunky, hard to maintain and kept getting hacked.
they hired a 3rd party to rebuild the service from scratch using laravel, unfortunately the project wasn't managed at all and expectations weren't aligned so after about 12 months and a lot of money wasted the rewrite was scrapped. The biggest problem with this approach was they used the waterfall model and expected everything to come together nicely at the end rather than an agile model of quickly, build, test, release etc.
Eventually they just hired a dev to maintain and make increnetal improvements. the platform is still running.
Personally I'd just take an agile approach. integrate laravel in to the platform to initially just handle auth and hand over the rest of the pages to the old system. laravel's ORM can map to any clunky database, then migrate each of the old pages or features to laravel, one at a time, releasing and testing often until everything has been migrated to laravel and the old site has been phased out.
Re:ive experienced this first hand... (Score:4, Insightful)
Re:ive experienced this first hand... (Score:4, Insightful)
Yep, Agile has completely failed in practice. Yet people cling to it. Just another example of the abject stupidity that pervades most of the human race.
Re: (Score:2)
What's the alternative though?
Believing "good old fashioned waterfall is good because old software still in use was developed with it".
That's just survival bias. You're looking at the few examples that survived, and pretending that the millions of failed projects that never saw the light of day never existed. Tons of projects got cancelled when using "old" methods as it just takes forever to get something that just wasn't what the client wanted.
Agile is not the problem, it's just another iterative software
Re: (Score:2)
If you choice is "Agile or Waterfall", then you have no place in this discussion. There are more way to get things done.
Incidentally, "pivot away and adapt" does not work with Agile either. Instead of a failed project, you simply get one with really crappy results. That often is worse.
Re: (Score:2)
If you choice is "Agile or Waterfall", then you have no place in this discussion. There are more way to get things done.
I suspect you are conflating "scrum" with "agile". Scrum is a shit methodology with seminars and certificates; agile is a group of loosely-coupled ideas [agilemanifesto.org] that can be used in varying degrees.
Given that at the core of it, the definition of "agile" is essentially "not waterfall", I'm not sure there are a lot of distinct alternatives to planning and building software. If you disagree, what are 2 or 3 other options that are distinct from those two?
Re: (Score:2)
Hehe I was trying to lead him there. It's always the case with these retirees (look at his UID). "I have loud opinions about things I don't understand".
Re: (Score:2)
"Retiree" my ass. I am active. Your hallucination does not impress me one bit. And defining "agile" as "not waterfall" is just bullshit. There are more models than waterfall.
Re: (Score:1)
Scrum is a meta process/method.
At the moment it is the best and the simplest development process/method mankind knows.
If you can not do Scrum, then you are probably utter incompetent in anything that requires forward thinking.
Scrum is a meta process. It defines the big picture of a development project. It is not limited to software. Originally it was actually industrial production. It does not tell you what to do when. That you have to define in your actual process.
If you are to stupid to do that, you proba
Re: (Score:2)
yeah, you have no idea what you're talking about. and now you try to avoid the discussion by shutting it down
fucking boomers.
look at your UID. You're retired, fuck off already.
Re: (Score:2)
look at your UID. You're retired, fuck off already.
You wish. Got nothing to say? Be a complete idiot and attack gender, name, race, age of the other person. Well done!
Incidentally, you are off by about 10 years, and only if I chose to stop at the official retirement age. People like me routinely get offered to work longer, because we are very hard to replace. In fact even dropping a hint that I might be interested gets me offers. Not that I financially need to. But I like what I do.
Re: (Score:1)
That is why basically every project I get into touch with is doing one or the other agile method?
Re: (Score:1)
You never did an agile project.
Or you would not write bullshit like this.
* Agile is the reason almost all software released to the public these days is pure shit. - which for example?
* The entire thing is an attempt to treat software development as a management process - wrong. There is nothing to manage in an agile process
* rather than a development process. Agile is purely development driven. The most famous agile process has it even in its name: eXtreme Programmimg.
*' Following no formal development p
Re: (Score:2)
Re: (Score:2)
Don't (Score:4, Informative)
No benefit for existing code. Don't even try.
For future projects, maybe, but also probably no. By now you must have created your own libraries of stuff that you use - in essence, your own framework. Experiment with Laravel, if you want, steal any good ideas. Stick with what you know.
But do start using a decent editor that actually supports coding.
Re: (Score:1)
Re: Don't (Score:2)
Netbeans works great for code on a remote machine (uses sftp).
PHPStorm (Score:2)
Re: (Score:1)
Re: (Score:2)
I have no idea what the application looks like, but perhaps some kind of front end (nginx ?) can be used to divide the application into smaller services and then set about implementing new services with your chosen framework and wrap-->replace old components piecemeal.
In any case you will want the modularity so that in 10 years time when the new "best practice" framework becomes yesterday's radioactive waste you can repeat the excercise
Divide and conquer (Score:1)
Then convert one of those pieces to modern code, possibly using a framework.
Repeat until all code is good.
And don't use PHP for new projects.
Easy Peasy (Score:4, Funny)
You open your AI tool and give it this prompt 'Please rewrite legacy PHP to [Modern Framework] in an error-free manner' and then lay off all of your developers.
Re: (Score:2)
Re: (Score:1)
Bonus points if it writes the lay off letters first.
Learning curve (Score:1)
Ditch vi (Score:2)
Have you read "Kill it with fire"? (Score:4, Insightful)
https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/1718501188 [amazon.com]
Kill it with Fire has notes from Marianne Bellotti, a person who's managed the conversions of multiple legacy systems with recommendations on how to keep the conversions momentum going, biggest killers of projects, how to manage your people, and more.
Delete, start over. (Score:2)
Although this may sound like a very counterintuitive and unproducvive approach, trying to migrate existing code that has grown over years or decades to a new framework is a major pain in the arse. By trying to replicate the old code and functionality in a new framework you embark onto a journey of pain while attempting to migrate unmigratable, framework-specific structures. Somewhere around the 3rd week mark down the line you realise how silly the idea was and that it's easier to ditch all the spaghetti cod
Re:Delete, start over. (Score:4, Insightful)
That's assuming anyone can actually articulate 100% of the must-have business logic that the old version supports. They can't. When the legacy codebase is also the spec, you'd be throwing away the spec when you do a rewrite.
depends (Score:2)
migrating right off the bat just for the sake of it, absolutely not.
if you feel that you can benefit from the services and abstractions that laravel (or whatever framework) provides just try to build your next smallish project with it, and you'll have a clear idea of how this compares to your custom code base, what such a migration would entail and where it would be appropriate or worth the effort.
if you're not convinced, you can repeat the process with another framework, at this point you'll already have c
If it works, leave it the way it is. (Score:1)
Similar boat (Score:3)
I am in a similar position. In my case, I didn't write the code, I inherited it. And it is old Windows based asp.net web forms instead of PHP. In my case, if I had the option, I wouldn't mess with it. It kinda-sorta works. However, I have to work with it daily. And that is a massive pain in the rear. So, I am converting a very large app to a modern React app, one page at a time. It was very slow going. But, modern tooling, including AI editors like Cursor have sped things up significantly.
And I thought they'd have to pry vi (neovim to be exact), from my cold dead fingers. I've been a vi user from the early 90s.
One piece of advice I will give you: Don't listen to anybody that tells you to not use AI for this sort of work. They are being a luddite. Yes AI makes mistakes. So do humans. Once you have understood that, you can use it to massively improve your productivity. Look into Cursor code editor.
AI is a tool, not a panacea (Score:1)
Don't listen to anybody that tells you to not use AI for this sort of work
While I generally agree, proofread the results for any obvious issues like copyright issues (if it "generates" comments that look like they were from some specific project that might have been in the AI training data, watch out).
Also look for non-obvious issues, like corner/edge cases that the original code handled well but the AI-replacement code didn't. Or the reverse: Where the original code had a bug (say, forgetting to handle an edge/corner case) that needs to be kept because fixing the bug will brea
LLM To The Rescue (Score:3)
In my humble opinion,
I think that he should first create a framework in Perl to translate all of its code base into a meta-code representation.
Then, train a LLM with this meta-code data and with StackOverflow.
Finally, start asking question to this model about how to perform this migration.
Of course, choosing Vi instead of Emacs was not the problem here but its main benefit and wisdom.
Re: (Score:2)
Are serious? I cannot tell....
Re: (Score:2)
Are serious? I cannot tell....
Either's he's serious or he's joking.
If he's joking, it's funny, laugh.
If he's serious, it's funny, laugh.
Don't (Score:1)
Want to rewrite to be more "modern", ask netscape. Wait, you can't. They pulled the same stunt and lost valuable time and went out of business. If you still update these sites, try refactoring just the bits you need to update. If you update them often enough, you'll have an updated application and you'll learn refactoring skills in the meantime.
You would only undertake the effort if it gave a payoff in return. Will your visitors "see" a difference? Will they care they are browsing on a "modern stack"?
Re: Don't (Score:2)
Let AI do it for you! (Score:1)
No joke! .. you can program the script at first with ChatGPT until it works with the API, then go on from there to enhance you
Just select a framework, and then write a simple script that uses the API of e.g. OpenAi to convert each file after another.
If you wan't to do it correctly start with creating tests for the old software just the same way, then tell it to confert the tests for each file first and make your script to reupload files to convert again with the reportet errors from the autogenerated tests.
Re: Let AI do it for you! (Score:2)
The harder part is giving it enough context of the rest of the project if its not exactly written in a modular way. Still the way to go. But it might require some planning. (With ChatGPT, obiously.)
The best? (Score:2)
AJAX it up (Score:2)
Re: AJAX it up (Score:2)
Hate on Frameworks Not Languages (Score:1)
1) Frameworks are garbage for maintainability and performance over the long term. Spaghetti code can beat them, simple, well written code always scales better and requires the least amount of maintenance... Lavarvel, Django, Symphony, React, Angular none of them are guaranteed to lead you to anything but constantly ne
Will anyone else EVER need to maintain it? (Score:1)
If not, then "if it ain't broke, don't fix it."
If so, then you either need to train your replacement in your way of doing things, redo the code in a way your replacement can do them, or (most likely, since you likely don't know who the future maintainers are) make sure your code is modular enough and stable enough that each module can be imported "like a black box" into whatever future paradigm there is without someone having to do any heavy lifting. Bonus points if it's written well enough that an AI or s
Clarify FORTRAN/COBOL (Score:1)
Forgot to specify "ancient" FORTRAN/COBOL - stuff from before the first moon landing.
Need more information (Score:2)
Context - I'm someone who, in the past, had written a lot of web code that mostly was *not* built on top of any framework(s).
In my experience, a framework may or may not benefit *you* directly all that much. However it can make it a lot easier for your client / employer to find someone who can maintain it after you've moved on. Also, knowing one or more frameworks can open new opportunities for you. So, for future code at least, I would suggest learning one and at least using it for any new code you're deve
Maintain what you have... (Score:2)
Next major version can change to use frameworks on PHP (although I'm not always a fan of using frameworks, depends on the application), or start migration to Python or NodeJS (although some will say you're just change one crappy platform for another).
Editor (Score:2)
For an editor just use vscode. It works. Any IDE is miles better that vi for editing code. Hell I use vscode for bash scripting these days.
For a framework... Meh. There's up to you. They do make a lot of stuff easier, and updates to the framework mean updates to security. It's code you don't need to maintain, just keep up to date. Just like any libraries you use.
Look at productivity (Score:1)
Don't (Score:1)
As somebody who retired and saw somebody else work on my old style php code, the new High IQ programmer immediately attempted to cram hundreds of small individual .php files used by a JS frontend, callbacks, and cron jobs into an MVC pattern, and only afterwards noticed things like that most of it returns json (which was somehow a huge problem) or that various directories all have different permissions models, or that the sql statements actually do more than CRUD and thus didn't fit neatly into his Models.
T
You don't have a problem! (Score:2)
Your "problem" perfectly illustrates the awesome power of PHP. You're running well maintained legacy systems for decades and still are on top of things. Using VI (wtf??!?).
If you want to upgrade, upgrade pure PHP and its newest features. Frameworks like Laravel or Symfony are for people, projects and teams who need to have maintainability over large and long-term projects and need to be fast and agile in new ones. And aren't all that well versed in pure php. A problem you don't have I presume.
Switch to a b
Re: (Score:1)
I use Jetbrains PhpStorm ... (Score:2)
... but you might be just fine with VScode [visualstudio.com], Intelephense [intelephense.com] for VScode+PHP [visualstudio.com] and some other PHP extensions. Searching and installing extensions directly in VScode is trivial, it has it's own GUI for that, including automated suggestions, previews, ratings, installation and usage statistics.
PhpStorm and VScode+Intelephense are the two big ones, you're likely good with either. A completely different league vis-a-vis Vim either way.
Ditch PHP (Score:2)
Re: (Score:2)
"Ditch PHP" is not helpful. First of all, ditch it for what? And why?
Node.js (Vue/React/Svelt (- really shiny!)...etc) seems to be the trendy thing (a.k.a. one of the "next shiny things"), yet JavaScript has historically had similar issues as PHP, but both have evolved to the point where any reason not to use either a five-ten years ago has probably been minimized today. (That said Node.js has introduced a whole new level of dependency hell which is a huge issue that only seems to be getting worse).
Or maybe
Re: (Score:2)
It's especially worse for me because I need to make systems that will be in use for decades, so the language I'm based on can't keep throwing away compatibility every year, and even worse if I use frameworks that then throw away this compatibility once a month instead of once a year. I finally managed to
Frameworks are just a quick start (Score:2)
until you need things that the framework doesn't support.
NoNoHellYes (Score:2)
>Is there any benefit to migrating this codebase to a more modern PHP framework, like Laravel?
No
>And is there an easy and minimally intrusive way this can be done en-masse, across dozens of applications and websites?
No
>Or at this point should I just stick with vi?
Hell yes
Frameworks are a pox on coding, forcing many layers of stuff between your code and what it does. HTTP is not complicated. It doesn't need a complicated framework.
Document Your Framework (Score:1)
For larger systems I
Why a framework? (Score:1)
It's a question you should ask:
https://infrequently.org/2024/... [infrequently.org]
Keep doing what works (Score:2)
You should keep doing what works for you. If your codebase isn't bit rotten, if it still works with the latest versions of PHP, there is no need to change. As some fellow slashdotter posted earlier, maybe you should ask Netscape about full rewrites..
Regarding your editor/IDE, I'm willing to bet good money that most of these folks that tell you that vi(m) should be dissed in favor of some aberration by the Evil Empire (vscode) don't know anything beyond the bare minimum (entering INSERT mode, moving the curs
No need to change anything (Score:2)
Just make sure your code works with the latest PHP version.
I also recommend to use phpstan (or phan or psalm) to static check your code and have some test unit system setup (phpunit, pest, etc) which makes checking if you things work on a new PHP version much easier.
Personally I do not use much vi anymore, I prefer to use VSCode with some plugins to make the coding more easier for me (eg automatic php code sniffer stuff to make sure my code formatting is ok)
But switching all to a framework? Whatever you wou