How to keep your legacy PHP project working with minimal efforts
I hope this article can be helpful for PHP-based website owners, but also it can be quoted in a conversation between a PHP developer and a client.
So, what is the point? Extremely outdated but excellent working PHP projects are widespread cases in business realities. It’s enough just to open PHP projects listing in Upwork (or any other freelance marketplace) to prove that. Small online shops, CRM, CMS — there are many PHP websites that were created years ago and still work.
From a business perspective, it’s awesome. You paid once and then should pay only for the server’s costs. Every code upgrade costs money (because the developer’s job isn’t free), and sometimes it’s hard to understand what’s been changed and why it spent a few weeks of the developer’s job for that.
From a developer’s perspective, such a project can look like hell. Fixing one bug creates another, local deployment is hard, no documentation, etc. It seems to be better to rewrite everything from scratch. The client asks a reasonable question, “will my sales grow up after that?”. Usually, the answer is not so good. Usually, it sounds like, “no, but the code will be cleaner, the system is more stable, bla-bla-bla”. It sounds reasonable to me, the developer, but very often, it sounds not so exciting to the client.
The client wants just “add one more button” or fix “a simple” bug when the developer proposes to spend a few thousand for “refactoring,” “rewriting,” and other developers’ words.
Where is a golden mean? How not to spend the whole budget for refactoring from one side but not get a non-working project in the future from another side? Let’s find it out.
I decided to list the essential points of PHP-based websites. They are standard for all modern projects but, unfortunately, far from always used for legacy projects that “just work.” If you can afford all these items — it’s great. If you don’t — you should know what is a must-have and what can be skipped at the current stage.
So, here is a list (it has no order):
- Infrastructure backups
- Database backups
- Code backups
- Files backups
- composer usage
- database migrations usage
- 8.x version of PHP
- unit-tests
- code style agreement and fixers
- framework usage
- single entry point usage
- crontab usage
I will describe every item for three properties: Importance, Complexity, and Amount of Work.
- Infrastructure backups
For a proper website setup, it’s necessary to have the correct configs and know the correct versions of external dependencies. Sometimes it’s very easy, and you can run the website with default configs, and sometimes it’s tricky enough to make it work, especially locally, on the developer’s machine.
Why it’s important? In case your server is broken, hacked, or even upgraded — infrastructure backup will decrease system downtime.
How it can be achieved — starting from creating a simple text document “how to setup” and ending with a Vagrant or Docker image
2. Database Backups
There are two kinds of people: those who backup, and those who have never lost all their data.
There are plenty of ways to lose all your data in the database: bad SQL query, hackers, system bugs, and hardware problems. And even though database backups are easy enough to implement, I saw a lot of projects without them. Sometimes they were, but it looked like from time to time saved data to a backup.sql file.
It’s a critical point, and there is nothing more to say.
3. Code Backups (VCS usage)
You can lose not only your data but even the whole website. It’s easy to imagine the developer who accidentally deleted the project from the server when thinking it was locally (sounds funny, but it happens not so rarely for beginners).
Another option — lose a few days (or even weeks) of the developer’s work because of the unexpected death of the hard drive.
Sounds bad? Yes. Is there a solution? Yes! It’s necessary just to use VCS (version control system) GIT. It’s free for small projects and really cheap even for big ones.
4. Files Backups
Sometimes websites store user-uploaded files, like avatars, documents, agreements, etc.
If you have those, and you don’t want to lose them one day — it’s necessary to make a backup. It can be really easy or hard enough — it depends on the amount and size of your files.
One of the ways to achieve that — move files processing to cloud-based storage like Amazon S3, which has a built-in feature for backups.
5. Composer Usage
It’s a must-have practice in 2022.
A typical website uses at least a few external dependencies like libraries. Composer allows keeping them updated and verified and makes deployment faster and easier.
In other words, not a critical thing from a business point of view but critical from a developer’s perspective.
6. Database migrations usage
Shortly, it’s a way to track changes in the database’s structure.
It greatly improves system stability if multiple developers work on the project simultaneously.
Not critically, costs almost nothing, nice to have!
7. 8.x version of PHP
I would say it’s a must-have.
The current version is 8.1, while some projects still run 5.6.
New versions bring more performance (sometimes very noticeable) and fix vulnerabilities. Sometimes after migrating from 5.x version to 8.x version, it’s even possible to buy a cheaper server! Also, website users definitely will notice speed improvement.
Upgrade complexity totally depends on the website, sometimes it can take 1 hour of work, and sometimes it can take months. The more often you keep it updated — the easier to do that. Upgrade PHP 5.6 to 7.1 — can take weeks of work, and upgrading from 7.4 to 8.1 can take a few days or even hours.
8. Unit tests
Developers, please don’t blame me for this “importance” rating.
Unit testing is standard practice for new projects, but they are extremely hard to be written for legacy, outdated projects. Sometimes it’s not even possible at all without deep refactoring.
So we have a conclusion — it’s nice to have unit tests, but sometimes it’s not possible or can take months of work.
It’s not a critical thing for keeping existing projects “on the fly.”
9. Code style agreement and fixers
It can be non-obvious for non-programmers, but usually, there are plenty of ways to achieve the same result with a code. It’s called a code style, and different coders can have different ones.
When there are multiple developers on the same projects — it’s nice to have an agreement on how to code. It’s about the developer’s comfort. That’s all.
Way to achieve — implement tools for auto-checking and code auto-fixing. Sometimes it can take some time.
10. Framework usage
Frameworks (like Laravel, Symfony, or Yii) can dramatically increase development speed and system stability. But it works only in case they were used from the very beginning.
If you have a big project written in the times of PHP 5.6 without frameworks, then implementing the framework usually means rewriting the whole system.
As a result — implementing frameworks into an old legacy project can take an unpredictable amount of time while being is not critical for just keeping it “on the fly.”
11. Single entry point usage
It’s a pretty technical detail, but I will try to describe it.
Shortly, if URLs on your website look like “/login.php”, “/posts.php,” “/order.php?action=buy” (in other words, always contain “.php”) — your website has multiple points of entrance. It’s always harder to support such websites, and it can even cause security issues.
If you are planning to add a lot of new pages/features but do not have enough resources to rewrite everything from scratch using frameworks — moving everything to the one entry point can do great work in refactoring. Just for keeping the project on the fly, it’s not critical at all.
As for complexity — usually, it’s a complex task that should be given only to the senior-level developer.
12. Crontab usage
A common task for websites — do some background job, like sending scheduled emails or making backups.
Many-many years ago, some cheap hostings could not schedule background scripts, so some developers bypassed it by using random user requests to run scheduled scripts.
It’s a “stone-age” practice. Now, even free servers support crontab; your project definitely should use it in case of background jobs need. It will bring much more stability and reliability.
That’s all for today!
To summarize, backups, modern PHP version, and composer usage are must-have practices in all projects, even for really outdated ones. Everything else is optional and depends on the situation.
Modern projects are awesome, but in reality, we still have a lot of “nasty jobs,” and they always will be 🙂.
