WordPress 5.6 image upload error: not a valid JSON response

For larger image file uploads I’ve been getting this error recently:

Reducing the image file size and then retrying avoids the issue, but this adds additional steps.

Multiple posts online like this one suggest this is an error with the permalinks and resaving the current settings on that page in the Admin panel will fix the error, but this didn’t fix it for me.

Looking around in my server logs, I found this error in my /var/log/nginx/error.log:

2020/12/23 00:36:45 [error] 36#36: *311 client intended to send too large body: 4132609 bytes

This post suggests adding a client_max_body_size param in nginx.conf (or increasing the value already there). I added a larger value than the size in the error and this fixed the issue.

2 years later: 2 years of running WordPress and MySQL on Docker in a VPS

It’s been 2 years since I migrated this site from a native install on a VPS to another VPS running Docker. I covered my migration in a number of posts, the first of which is here:

The surprising thing (maybe? maybe not?) is that the site has been up and running for the past 2 years with no issues. I think I rebooted the VPS a couple of times for reasons I can’t remember, but other than that the site’s been up reliably for the past 2 years.

It’s also been 2 years since I last renewed my SSL certificate, so time to do a couple of updates. More to come later.

WordPress error uploading photos on nginx: “client intended to send too large body”

Attempting to upload some new photos between around 3 to 5MB, the majority of the uploads failed, and this error was occurring repeatedly in my nginx error.log:

2018/08/06 07:18:37 [error] 43#0: *5 client intended to send too large body: 3125530 bytes

Based on this tip from here, the solution was to increase the default POST body size config with this setting in my nginx.conf:

client_max_body_size 5M;

Building and deploying Docker containers using GitLab CI Pipelines

As part of migrating this blog to Docker containers to move to a different VPS provider (here, here and here), I found myself repeating a number of steps manually, which always a good indication that there’s an opportunity to automate some or all of those steps.

Each time I made a change in the configuration or changed the content to be deployed, I found myself rebuilding the Docker image and either running locally, pushing to my test server, and eventually pushing to my prod VPS and running there.

I’m using a locally running GitLab for my version control, so to use its build pipeline features was a natural next step. I talked about setting up a GitLab runner previously here – this is what performs the work for your pipeline.

You configure your pipeline with a .gitlab-ci.yml file in the root of your repo. I defined 2 stages, build and deploy:

 - build
 - deploy

For my build stage, I have a single task which is to build my images using my docker-compose.yml:

 stage: build
 - docker-compose build
 - docker-test

For my deploy steps, I defined one for deploying to my test server, and one for deploying to my production VPS. This is the deploy to my locally running Docker server. It changes DOCKER_HOST to point to my test server, and then uses the docker-compose.yml again to bring down the running containers, and bring up the new containers with the updated images:

 stage: deploy
 - export DOCKER_HOST=tcp://192.x.x.x:2375
 - docker-compose down
 - docker-compose up -d
 - docker-test

And one for my deploy to production. Note that this step is defined with ‘when: manual’ which tells GitLab the task is only run manually (when you click on the ‘>’ run icon):

 stage: deploy
 - pwd && ls -l
 - ./docker-compose-vps-down.sh
 - ./docker-compose-vps-up.sh
 when: manual
 - docker-prod

Here’s what the complete pipeline looks like in GitLab:

With this in place, now any changes committed to the repo result in a new image created and pushed to my test server automatically, and when I’ve completed testing the changes I can optionally deploy the changes to my prod VPS hosted server.