error_log

The reason that most of the photos and entries from Norway aren't posted yet is because it takes a long time to edit photos when you have a lot of other stuff going on in life. And when I started chipping away at it in the hours before bed, I realised I was running out of disk space on bradism.com which was stopping me from uploading images and even logging in. I had to keep deleting log files that would then grow again over the next day and block me again.

I knew I needed a long term solution as I have plans to upload many more photos and no plans to upgrade my web hosting before 2027 when my extremely cheap, grandfathered deal finally runs out.

A cursory glance at my server’s file manager confirmed that the webroot directory where all the static content is hosted was consuming nearly all of my disk. All my images are currently hosted in JPG format, with an optimised JPG version as well, plus a card and thumbnail version. There are new formats, like AVIF and WEBP, that are much smaller without compromising on quality like I had been doing by exporting JPGs at low quality which made them look terrible.

I had the idea to use Cursor to enhance Bradism to handle new image uploads and convert them to AVIF. And to also add a button in the admin side so that I can convert known old images of large size to AVIF as well. This sounded like a good idea, and with AI it shouldn't take too long. Right?

Unfortunately, I had not set up the Bradism dev environment on the computer I upgraded to last year, so I had to do that, which entailed doing a lot of setup work on a new Virtual Box. And then I inevitably had to upgrade versions of things including PHP which led to deprecation warnings that I (AI) had to fix. Oh and in my new house I use the WiFi instead of ethernet which means the performance of my mounted disk in the virtual box is very bad. So yes, the AI did enhance the image upload process, add the button, add multi-image upload, come up with a new colour scheme, and fix a bunch of depreciations. It only took a week, most of which was spent not coding but setting up the environment.

Coding Bradism features was not how I planned to spend my Friday evening. I actually planned to spend it in the emergency department because I have a partially collapsed lung. But that’s a different story that hopefully one day someone will fill me in on. Instead of being in hospital I added the features and then logged on to the production server so that I could deploy them. As a quality minded individual I checked the remote server’s readiness to accept the deployment and make sure there were no modified files that would get overwritten by a deployment. And when I checked that, I noticed an Apache generated error_log in my webroot directory. And on closer inspection I noticed that this, adjacent to my JPG images, was 1.74GB gigs. Of the same deprecation warning that was for some reason being logged, fourteen times, every time someone (AI) visited my site.

So all that development effort did lead to the freeing up a lot of disk space. But it could have happened a lot quicker.