Don’t stiff clients, upgrade your stuff

Image shows a click with the text "Time to upgrade"

A client recently asked me to setup a Silverstripe site on their server. They were in the process of getting the files and database extract to me and then I would be good to go. I hadn’t used Silverstripe since 2008 but figured, why not? Setting it up on a new server shouldn’t be too much of an issue…oh boy, was I wrong!

After a while, I received the files and a database dump. Everything seemed ok although I was surprised to see an included vendor folder. I checked the composer.json file to see what I was working with and well, I was a little concerned. PHP was set to 5.6 and all but two requirements were set to dev-master and silverstripe/recipe-cms was set as 4.2.*, released sometime in 2018.

Get it working

OK, so the developers had installed Silverstripe in 2018 and never felt the need to upgrade it, not even once. So I thought, I’ll set up a dev environment and get going.
I created a Docker container with PHP5.6, MySQL 5.7, and a few extensions. I copied everything in, including the vendor folder and managed to get a half working website running. It wasn’t quite as easy as described as I needed to work out what extensions I needed and fix a couple of minor bugs, but the site was working.

I thought cool, now I can start upgrading the site. It was at this point I recalled every dependency was set to dev-master. So the first step was to set the correct version for each dependency. Well, the version as of 2018 and get a composer install to work.
I checked the installed.json inside vendor/composer and found the commit hash for each dependency. I then found the related version on GitHub and updated the composer.json. This was tedious work; however, I figured I was working towards getting a working composer.json. When done, I discovered this wasn’t going to work; the provided composer.json did not create the included vendor directory and there was too much stuff missing.

I decided to go back to basics and create a brand-new composer.json including every package listed in vendor/composer/installed.json. Eventually I got to the point where I could run composer install with no vendor directory or composer.lock file and get a working vendor directory. Awesome!

Although this worked, I couldn’t yet start upgrading as there was too much listed in my composer.json. I started checking each package to see if it was a core requirement or a dependency of something else and pruned the composer.json file down to the bare minimum. Several hours later, I again had a working composer.json file.

Upgrade it

A day in and I had a working Silverstripe site, running on PHP5.6 and MySQL 5.7. I was also confident I could clear the “vendor” directory and recreate it. As joyous as I was, I was no further along. I couldn’t put this online as I needed it to be running PHP8.0 at a minimum and MySQL8. Additionally, I was having to use composer 1.10.26 – that also had to change.

I started the upgrade process; I went step by step starting at 4.2.0 all the way up to version 4.10.0. At each release, I would trash the vendor directory and composer.lock file and see if I ended up with a working site. It was slow as I kept needing to tweak things. Every time Silverstripe added support for an updated version of PHP, I would rebuild my Docker container and test again, slowly fixing bugs and correcting dependencies as I went. As soon I was running PHP8, I switched to MySQL 8 and manually updated the database schema.

Stable & Supportable

The site is now sitting on a staging server for the client. There are a few small issues here and there that I need to fix, and I need to continue upgrading to the latest version of Silverstripe, however, for now, this client is happy.

The moral of the story – upgrade your stuff. If you are selling a website to a client, at least have the decency to upgrade it. Handing them a hot mess four years later is disgusting and the “development house” in question should be ashamed of themselves.

I’m not going to name the “development house” as I don’t know if this was a one off. I expect not but it isn’t for me say as I never dealt with them directly, I just had to pick up the mess.

Budget Pro development begins again

The budget overview screen in Budget. Shows the this month and the two following months and the expenses for each

There was an initial flurry of development on Budget Pro in October/November and then it stalled. The stall was primarily down to lack of time as I started a freelance project in the November and needed to obviously dedicate time to that. However, whenever a free evening popped up, I chose not to work on Budget Pro and instead work on Budget or the freelance project to try and finish it sooner.

No sinister reason behind this and we still fully expect to release Budget Pro within the first half of 2023. The issue was simply that there were still things to learn from Budget, our free budgeting App.

Budget Open Beta

During the open beta, we learnt far more than we expected. We had to improve the demo, we needed to rework the Budget overview and there were several small features which we deemed necessary and didn’t finish adding until the end of the year.

In late November, I decided to delay any further development on Budget Pro until the official release of Budget; that way we would get to see and resolve all our problems in one codebase and not worry about having to rework anything in Budget Pro.

We always planned on there being two offerings of our budgeting tool – Budget, the free version and Budget Pro, our subscription option. In building Budget first, it has enabled us to identify and iron out potential issues before developing the much more complex version.

Our two Apps, Budget and Budget Pro solve the same problem, but they tackle it slightly differently. Budget is aimed at everyone; Budget Pro is aimed at users who need to collaborate or have much more complex budgets requirements.

Budget Pro is due out within the first half of 2023 and as soon as we are able, we will open it up for beta, the plan being we don’t make any of the same mistakes we did with the launch of Budget.