From a critical PHP alert to several days of updates, security reviews, migrations and a redesign I'd been putting off for years.
It all started with a PHP security alert.
On 21 October 2026, fixes were released for two critical vulnerabilities that could allow remote code execution. The sort of news that, when you work with systems, makes you stop what you're doing and ask which of your services might be affected.
At first, the job seemed fairly straightforward: check the installed versions, work out what needed updating, apply the fixes and make sure everything still worked.
Just a bit of maintenance, really.
Three days later, I'd updated several services, investigated possible attempts to exploit the vulnerabilities, made backups, migrated an old Joomla installation almost from scratch and completely changed the look of my personal website.
I suppose that's one way to make good use of your time.
First things first: security
A critical vulnerability doesn't automatically mean a system has been compromised. It means there's a risk that needs to be assessed and addressed.
And in this case, the risk was serious enough that it couldn't wait until another day.
The first step was to identify which services used PHP and which might be affected. Checking a version number on the server wasn't enough: I had to look at the applications, their runtime environments and the dependencies each one relied on.
Some of the applications I use weren't even hosted where I remembered them being. Hardly surprising when you've spent years managing services and moving them from one place to another, but a good reminder to check the facts instead of trusting your memory.
With the inventory sorted out, it was time to set priorities.
Potentially vulnerable services couldn't simply carry on running as usual while I decided what to do. Some were temporarily stopped; others were updated to versions that included the security fixes.
I also reviewed the available logs for signs of suspicious activity.
As with practically any service exposed to the internet, there were automated requests, attempts to find resources and plenty of background noise. I found no evidence that the vulnerabilities had been exploited in the systems I checked.
That doesn't prove nothing ever happened, but it does help distinguish a potential risk from a confirmed intrusion. Those are two very different situations, and it's important not to confuse them.
Updating is easy. Keeping everything working isn't always.
Once I'd identified the problem, it was time for the supposedly easy part: updating.
For some services, the process was relatively straightforward. Prepare the update, apply the changes, start things up and verify the result.
But an update isn't finished just because a container is running again.
You need to check that the application responds, its components are compatible, the data is still available and the main features still work.
One application also needed a major upgrade of the underlying platform. For others, I had to review runtime versions and dependencies.
All of this took considerably longer than the phrase “update PHP” might suggest.
Still, there was one piece that made the job particularly complicated: my personal website.
The problem with a website that had been running for far too long
My website had been running on Joomla for many years.
It had survived different servers, infrastructure changes and several stages of my professional life. It still contained articles, projects, links and documentation I wanted to keep.
What it hadn't had was a proper technical overhaul.
When I looked into it, I found an old Joomla installation that I couldn't fix simply by changing the PHP version and restarting the service.
The gap between that installation and current releases was just too big.
At that point, I had two options: try to chain together successive upgrades and deal with every incompatibility along the way, or build a fresh installation and migrate only what was genuinely worth keeping.
I chose the second.
Not because it necessarily meant less work, but because it let me leave old dependencies behind and regain control over what I was running.
A migration that started with backups
Before touching the content, I backed up the original files and database.
And I checked the backups.
It sounds obvious, but a backup you've never verified is, to some extent, an act of faith.
Next came the job of separating the content I wanted to keep from all the structure that had accumulated over the years.
There were nearly a hundred articles, categories, menus, content in several languages and associations between the Spanish and English versions.
There were also extensions and features that had made sense at the time but that I no longer needed.
I decided to preserve mainly the articles and their organisation, leaving behind old gallery, download and other components that no longer justified carrying their dependencies forward.
The idea was simple enough: keep the history, but not necessarily all the technology that had come with it.
Of course, the idea was simple. Carrying it out was another matter.
Rebuilding a website isn't the same as copying articles
With a modern Joomla installation ready, the rebuilding began.
I had to restore the content, reorganise categories, set up menus, re-establish the links between languages and check that everything pointed to the right place.
Along the way came the usual problems of any migration involving years of accumulated data.
Categories that no longer existed, references that needed reinterpretation, menus that didn't quite fit the new structure and components that needed a different solution.
At one point I also discovered that an installation could be working perfectly and still be missing some of the Spanish language files.
It's those little joys that keep a migration from becoming boring.
The work moved forward through repeated checks: content, links, languages, menus, forms and navigation.
When I was done, the website was back online on a current platform, with a much simpler structure.
And that could have been the end of the story.
But then I made the mistake of looking at the homepage.
“While we're at it…”
With the security issue on its way to being resolved and the new installation running, I found myself looking at a technically renewed website that still looked rather old-fashioned.
The content was there, but the presentation no longer reflected what I do today.
My professional work has changed a great deal since the early years of the site. So have my projects, my interests and the way I want to share what I'm building.
And then came the phrase responsible for countless hours of work throughout the history of computing:
“While we're at it, we could improve this too.”
What started as a few cosmetic tweaks turned into a complete rethink of the website.
I wanted it to stop looking like an old personal portal with sections added over time, and become a clearer place to present projects, share experiences and bring back articles I'd written over the years.
Without necessarily turning it into a blog that would oblige me to publish something every week.
A different website, with the same history
The new homepage does a better job of showing what I do and what I want to talk about.
Projects now have a more prominent place, especially Protos, the programming language I've been working on for some time.
Articles and experiences now have a space of their own: the Journal.
My CV is still there, but it no longer dictates the entire structure of the site. I also took the opportunity to rethink how I describe my career and better reflect the work I do now.
Navigation is simpler, and the Spanish and English versions fit together coherently.
I've also refreshed the visual identity, brought back my personal avatar and added a design that works in both light and dark mode.
That last detail, naturally, brought its own collection of little problems.
Because making a page work in dark mode isn't just a matter of turning the background black. There's always a box that keeps its old colour, some text that loses contrast or a section that seems to have declared independence from the rest of the design.
The CV, for example, still had a few surprises in store.
Lots of checks, and quite a bit of artificial intelligence
I've carried out this whole process with extensive help from AI tools.
There's little point pretending otherwise, especially when a good part of my current work involves experimenting with these technologies.
They've helped me research issues, review configurations, prepare migration procedures, analyse results and develop the new design.
But the process still required decisions, supervision and a great deal of verification.
An AI can suggest a perfectly reasonable solution that doesn't fit a particular installation. It can misread a result, overlook a detail or solve one problem by creating another.
And when you're working with your own data and services, the responsibility for checking things still rests with you.
In fact, it's been a pretty good demonstration of how I like to use these tools: delegate part of the work, keep applying technical judgement and verify the results.
It also showed how an apparently simple conversation can lead to a surprising amount of work.
What began as an emergency became an opportunity
If that PHP alert hadn't appeared, my website would probably still look the way it did.
I'd have kept putting off the Joomla migration, and probably the redesign too.
The urgency forced me to review the state of several services, update components and rethink an installation that had gone too long without the attention it needed.
And once the most urgent part was dealt with, I took the chance to do something I'd been meaning to do for years.
The result isn't just a website with a different appearance.
I've reduced old dependencies, simplified maintenance, recovered historical content and ended up with a site that represents my projects and current work much better.
All in the space of a few days that began with a security alert and ended with an almost entirely new website.
It's not exactly what I'd planned to do that week.
But looking back, many of the most interesting things I've learned while working with technology have started like this: trying to solve one problem and discovering several more along the way.
At least this time, you can see the result.