Join me as I embark on a deep dive down the PHP migration rabbit hole. This will be a multi-part series as I upgrade a horrifyingly long list of legacy websites and applications from v5.6 to 7.2.
Part 2: Getting organized and plucking the low-hanging fruit.
In Part 1 of this series I gave an overview of what I have to do and some of the challenges involved in a multi-site upgrade of this scale. Navigate: Next (Part 3).
Make A Plan
The first step to any large project is to get a clear picture of what’s involved. To that end I have been updating my master list of all my projects and websites. This table, which I keep in my wiki, includes notes about each one and which version of PHP and MySQL it’s running on. Before anything else, I wanted to make sure this list was complete. To do this, I went through all my local project directories and my source code repositories. I then checked my hosting accounts where I tend to put experimental and incomplete projects and checked those. I found that while my list of client projects was complete, my own internal stuff wasn’t documented completely.
The next step was to browse through my various notes about general maintenance needed by my projects. Notes like “use proper password_hash functions”, and “update for UTF8” were scattered around my wiki. I gathered all of these into a high-level prioritized checklist.
I then did some reading about what to expect from an upgrade to PHP 7. The PHP Appendices have some great information. Sammy Kaye has a slide deck from his talk at PHPNW, and a PHP[Architect] article. From resources like these, I made a list of backward incompatible changes in PHP which might bite me. This way I can check for these issues specifically.
With these steps I have a pretty good plan for what I’ll be doing.
Lighten The Load
The next step was to prune my projects down by archiving old stuff that is no longer needed, and deciding which projects can be discontinued. Unused applications and websites, as well as speculative projects that I know I’ll never keep working on are the first to go.
I then made the not-too-tough decision to deprecate both my internal CMS and my MVC framework. WordPress will replace the CMS for clients and projects which need one. I just can’t compete with WordPress’ plugins, themes and that glorious one-click upgrade feature. It’s awesome. A few security minded plugins and I’m happy with hosting WordPress sites. (I might evaluate Laravel based CMS options too.) My CMS is used on a couple sites including my company website – and these will migrate to WordPress eventually. However it will still need to be upgraded to PHP 7 because the clients using it won’t want a new website built any time soon.
My MVC framework was a tougher decision. I have what amounts to a basic MVC project structure integrated with my own DB abstraction layer and my templating engine (TemplateSeed). I have a responsive layout skeleton built-in and I can whip up new simple websites and applications with it at lightning speed. However, it definitely doesn’t adhere to SOLID principles, doesn’t use Composer, and lacks any bells and whistles. After creating a Laravel course for my local college, I have now adopted Laravel as my framework of choice and will use SlimPHP for simple websites and APIs. So my own framework is getting archived and I’ll maintain it on individual projects as needed.
Easy Upgrades
A few early, easy wins is just what I need, so I recently upgraded the 5 sites that use WordPress as the entire site CMS or for the blog. This couldn’t be easier – few minutes each to log in, clear out spam comments on my clients’ behalf, hit that upgrade button and do the same for plugins and themes. None had any hiccups so those were super easy. A big plus for WordPress.
I have two wikis running on the OSS wiki software, Dokuwiki. These I’ll upgrade next- it’s not automatic but it’s still pretty straight forward.
Speaking Of 3rd Party Software
Several years ago I was a bit of a collector of open source PHP applications. I used to install and try out various PHP bug trackers, project management apps, forum software and more. Luckily all of these that I actually needed have been removed and replaced with cloud-based solutions. This was a change of heart I had a few years ago to stop being responsible for all my tools and instead leverage free or affordable cloud solutions and get their maintenance and updates off my plate. It would have been a nightmare if all those 3rd party applications were also on my upgrade list.
I have one site built on an old version of CodeIgniter, and I plan to re-write that in Laravel as a YouTube series eventually. I hope it doesn’t cause me much grief in the meantime. That plus a few slide-show plugins, RSS parser, mobile browser detector, and WYSIWYG text boxes round out the bulk of the 3rd party code that needs upgrading. It’s helpful to have a clear picture of these things.
Along these lines I have a few OSS libraries that I was in the process of working on – but I’m now trying to be more choosy about what I release to the Open Source community. Why bother adding another library to my plate of things to take care of – unless I’m sure I’m not reinventing the wheel. A couple of my ideas were just my own versions of existing packages so I’ve discontinued those and archived them.
In my next post I’ll tackle one or two of the simplest sites. Get them working locally and test them on PHP 7.