It feels weird to just appear here and add a post without acknowledging the long awkward silence. It’s almost exactly two years since I last posted. It wasn’t you, it was me. The last two years have involved, migrating to AWS, learning Laravel, hiring and working with amazingly talented developers and making peace with the fact that its ok that you’re not the smartest guy in the room.
It’s also fair to say that while I’m relatively happy with life, it has been a stressful few years, hence the lack of content. Lets just say that if you processed a photo of my hair, you wouldn’t need to worry about calibrating your RGB settings. If grayscale works, you’re good to go.
Another skill I have acquired over the last two years is the ability to dig my head out of the sand. Not burying your head in the sand in the first place may seem like a more obvious starting point, but cranial sand immersion is deeply ingrained in my core. I work remotely and in another continent from most of my co-workers. The continent I work in has poor internet connectivity. Even if I answer your Skype call I can still sit really still and pretend my connection just dropped if it gets awkward. Strong qualities for someone who heads up a department and co-founded a company, but we will unpack all that another day. You’re here for the tech.
So… tech, burying your head in the sand, digging it back out, yes, yes, yes. Get to the point…
My new found self-excavation skills were partly forced on me from a tech perspective. It turns out that ignoring that weird error in the server logs, pretending you didn’t notice that an instance didn’t spin up and ignoring the fact that your head twitches every time you have to talk to the marketing department
can will lead to issues down the line. Those issues will also manifest themselves late on a Friday evening after you’ve had at least one more glass of wine than is safe when trying to solve any conundrum more complex than “Do I open another bottle of red, or move on to the whisky”. I call it Frank’s Law for reasons I won’t explain because it might get me in trouble with a client.
With that in mind, I refused to go quietly into the night, or indeed the sand, when we span up some staging instances this week and encountered the following error:
Your Composer dependencies require the following PHP extensions to be installed: mbstring
“Well that’s easy, install mbstring idiot” you might exclaim, and you might be half right. However, our staging instances use exactly the same base AMIs and build scripts as our production instances, and they’re running just fine (pauses to check production instances because being smug about your tech also ties into Franks Law).
We span up a new instance in the production environment. No issues whatsoever. We compared the php info across both environments. Neither has the mbstring module installed. To further add to the mystery we install the Composer CLI during the build process but its not installed on the EC2 instances and at first glance this seemed to be a command line thing. After all I’m seeing it in my command line right*?
*spoiler alert: I’m not right
We installed php-mbstring on the staging instance and everything was fine with the world. My head began to veer in a southerly direction, but not this time. I set my noggin northward and swore to myself that I would not rest until I had solved this mystery with only my wits, tenacity, and ability to type things into google.
Searching my local app for “Your Composer dependencies require” returned no results. Initial web searches for combinations of “laravel”, “mbstring missing”, “changes to laravel requirements” and “best shovels for making head-sized holes in sand” shed no light on things either, and then came the light bulb moment, Composer is throwing the error, why not ask them why they are?
Ok so it was less a lightbulb and more a visit from Captain Obvious, but a quick google for “Your Composer dependencies require the following PHP extensions” took me to this well written explanation on php.watch and suddenly everything clicked into place (emphasis is mine):
“When you dump the Composer autoloader (or when it’s done automatically during a package add/update/remove operation), Composer v2 now creates a new vendor/composer/platform_check.php file that immediately terminates rest of the application if the current server platform does not match the original environment it was created on.“
“…if the platform is missing certain extension that are missing, the error message will be extended to show missing extensions as well:“
Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: pdo, xml
The last build process that we ran on production was 21st October (I was on holiday ok, usually we do 6000 deployments before lunchtime), Composer 2 was released 24th October. Downloading the last build of production and the current staging build showed that staging contained
vendor/composer/platform_check.php while production didn’t. So in actual fact we’ve required and not installed mbstring all along but prior to the recent composer update had not exposed this issue, or encountered any errors thrown by the app to suggest that we were missing it.
To cut this long, and largely irrelevant story short(er than it could be once I hit my stride and this coffee kicks in):
- Run composer update prior to deploying if your build process is going to do the same
- Keep up with updates to the packages you use (we have a very neat process for checking for vulnerabilities but clearly not updates)
- Know what your app requires (RTFD)
- Stay out of the sand if you can, but if you can’t try The Big John Metal Detecting Relic Spade*
*I didn’t receive any commission for this promotion I just thought it might be amusing to actually google for “best shovels for making head-sized holes in sand” and this is what came up.