Gosh darn it, I love Craft and still consider it the best solution on the market for actual content management but its update process is infuriating. I'd hazard a guess that somewhere between 40-60% of the time I try to install a plugin, run an update, or do anything else that requires Composer, I end up with a string of errors, or a memory leak, or an outright borked install – and often, a combination of the above!
Now, to be clear, this is almost certainly my fault 😅 (update: see note below). I'm no back-end developer and my knowledge of server configuration is minimal (to be generous). It's true that I've run Craft across several hosting services and platforms, including "specialist" options like FortRabbit, and no matter what server configuration I use, I can still all but guarantee crashes and problems when using Composer. But at the same time, I've never had any issues when using Craft for day-to-day tasks like content creation, copy editing, tweaking config or settings etc. It's robust as anything and stands up to all my weird requirements... until I try to use Composer.
The "obvious" solution is to never run Composer in production. For client work, that's the process I put in place. All updates are done locally, tested, and then cloned to the server. But client work tends to have benefits like hosting with SSH access, gigabit upload speeds, and, y'know, being paid for my time. On this here personal site, none of that is the case.
This is problematic, because the official "fix" when an installation or upgrade goes sideways is to wipe the vendors folder and composer.lock file and run Composer via a terminal. Obviously, that requires SSH access, which I do not have[1].
The second tactic is to build Craft locally, replicate plugin settings etc., run whatever updates/installs you need, then clone the Composer files and vendors folder to the server using FTP[2]. This has been my go-to solution for a while now, but it's a royal pain in the butt if you're only rocking 10MB upload speeds. The vendors folder tends to run in the hundreds of megabytes, and I'm pretty sure my ISP additionally throttles FTP uploads, so I rarely get the job done in less than three hours (and that's after another hour or so spent getting a local version of Craft up and running again). That's a fair chunk of time to burn through just because I wanted to try out a new plugin 😤
As a result, what I've started doing is logging into cPanel, creating a local clone on the server of the vendors folder and Composer files, then playing the Update Roulette game. If Craft collapses, I can just wipe the new folders/files and reinstate the cloned copies, then try again until it works. It's... not elegant, but it saves a lot of time in the long run.
Still, I am a lazy person at heart, so last night I threw caution to the wind and tried to install a plugin, blowing up Craft beyond the point of recall. To be fair, Craft warned me. The first install attempt only soft errored[3], which I've learnt can be overcome by (I kid you not) pressing the browser's back button and hoping that it magically just snaps back together. But, I figured that the issue had been a hard drive backup I was running at the time[4], so I paused it and ran the install again, only to get a complete crash that rendered my CMS completely broken. Moral of the story: don't code whilst tired, kids!
Luckily, I hit on a slightly less irritating solution. My hosting may not have SSH access, but it does have Jetbackup-powered scheduled backups, which allow for per-file (or per-folder) restoration. Luckily (largely because of, well, all of the above) it's been a while since I've done any updates or major config changes to my Craft install, so whilst my most recent saved backup was over a month ago, it's still recent enough to not undo anything I've worked on 🎉
I've never used this service before, so I went a bit overkill on the fail-safes. I did my usual renaming trick with the existing folders, created a full server backup, and downloaded the Jetbackup files locally to double-check everything was where it should be. It all looked good, so I selected the Composer files and vendors folder (only) in the Jetbackup Files panel, and chose to queue a restore operation. Then I sat back and waited for the little cog to stop spinning. And waited.
And waited.
...
After half an hour, I gave up and went to bed, figuring it would be done in the morning – which it was! I opened up my CMS and hey-presto, it works again 😭🥳🎉
But, I was interested to know how long that restore task took. After all, if it's less than four hours, this is a better tactic than the ol'FTP trick, but any more and probably still not that useful, unless you can leave it running overnight as I did. Well, after loading up my Jetbackup logs, it turns out that it took about 20 minutes. It was actually finished before I went to bed.
So there's a lesson learned: Jetbackup is a much more efficient way to get a broken Craft install back up and running, but it also has terrible state management and you should not trust its loading spinners 😂
Now let's see how long it takes for me to get lazy and break everything again...
🚨 Update: So, over lunch I decided to try and run some updates (with full backups this time!) and Craft predictably crashed. Only, this time I saved the error message and did some Googling. It turns out that whilst I had everything configured correctly in my extensions list, I had proc_open disabled in my php.ini file 🤦♂️
This was not obvious, as I don't have direct access to that file on my server and instead have to edit it in a "handy" config panel. However, the array of disabled functions was waaaay longer than the input element used to render it, so I hadn't noticed it before. I think the settings were probably changed when I upgraded to PHP 7 (a requirement for the previous Craft update I'd done), or Craft has only recently begun using these functions, which is why the issue is a relatively new one.
Anyway, if you're running into some variation of this error message:
Extracting archive The Process class relies on proc_open, which is not available on your PHP installation. The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems) Unzip with unzip command failed, falling back to ZipArchive class
Just make sure proc_open, proc_close, and proc_get_status are all properly enabled in your PHP config. Having changed those settings, I was able to run a full update on all plugins and Craft with no errors or issues 🥳
(I did say this was all probably my fault)
