Résolution de l’erreur « 413 Entity Too Large » dans WordPress avec Docker

Bonjour, avec la création de ce site, je savais que j’allais au devant de certains problèmes.
Cette fois, c’est l’erreur inscrite dans le titre qui m’a fait perdre un peu de temps.

Parce que oui, avec un seul site web, on modifie dans php.ini
ou dans nginx.conf

Mais sous docker….

allez en avant pour troubleshoot ceci.

un peu d’histoire

L’erreur « 413 Entity Too Large » se produit lorsque le serveur refuse de traiter une requête car la taille de la demande dépasse les limites définies. Cela peut se produire lors du téléchargement de fichiers volumineux, comme des images ou des vidéos, sur une plateforme comme WordPress. Les causes courantes incluent :

1. Limitations de PHP : PHP impose des restrictions sur la taille des fichiers pouvant être téléchargés. Ces limitations sont généralement configurées dans le fichier php.ini à l’aide de directives telles que :

• upload_max_filesize : La taille maximale des fichiers pouvant être téléchargés.
• post_max_size : La taille maximale des données postées dans une requête.

2) Configuration de Nginx : De même, Nginx a ses propres limitations qui peuvent provoquer cette erreur. La directive client_max_body_size définit la taille maximale des corps de requête que Nginx peut accepter.

Comment verifier?

« Connais l’adversaire et surtout connais toi toi-même et tu seras invincible.”Sun Tzu

Afin de savoir ou on en est, on va ajouter le bout de fichier info.php dans notre wordpress.

On rentre dans le conteneur

docker exec -it <nom_du_conteneur_wordpress> /bin/bash

On crée le fichier dans /var/www/html (emplacement par défaut)

echo "<?php phpinfo(); ?>" > info.php

et ensuite on peut acceder à notre site
https://ton_site_web/info.php.

cela nous donne ceci, et la ligne qui nous interesse est « Post_max_size »

Mais également la valeur upload_max_filesize qui nous intéresse

Problème Solved

Ici, nous ne réglerons pas le problème dans le cadre d’un site web traditionnel avec la pile LAMP (linux apache mysql et Php) d’autres sites l’expliquent mieux que moi. je mettrais d’ailleurs ces derniers en ressources à la fin.
Je passe directement à la solution qui m’a permis de contourner le problème.

Au lieu d’ajouter directement un fichier dans le conteneur, j’ai crée un fichier à la racine de l’emplacement de mon docker-compose, et j’ai monté le volume dans ce dit fichier.

Bien sur, et on ne le rappelle jamais assez, avant toute modification, prenez soin de faire une sauvegarde au préalable

/chemin_du_docker/cp docker-compose.yml docker-compose.bak

ensuite, on va déjà créer notre fichier uploads.ini.

Pour des raisons pratiques, j’ai crée le fichier dans le répertoire ou se situe mon docker-compose mais vous pouvez le mettre ou vous voulez tant que le docker-compose renvoi bien vers ce fichier.

Nano uploads.ini

Puis à l’intérieur de ce fichier

file_uploads = On
memory_limit = 50M
upload_max_filesize = 5M
post_max_size = 5M
max_execution_time = 600

On ne va pas être trop gourmand, pour des photos, 5M suffiront.

Ensuite, on va devoir monter ce répertoire directement dans notre docker-compose afin qu’il se lance au démarrage du conteneur.

  techromancien-wordpress:
    image: wordpress:latest
    container_name: website-wordpress
    volumes:
      - ./website/wordpress:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    restart: always
    environment:
      WORDPRESS_DB_HOST: WEBSITE-db:3306
      WORDPRESS_DB_USER: WEBSITE_user
      WORDPRESS_DB_PASSWORD: DB_PASSWORD
      WORDPRESS_DB_NAME: BDD_wordpress
    depends_on:
      - WEBSITE-db
    networks:
      - webnet

Puis par la suite un petit reflexe quand on fait de la conteneurisation via docker

docker compose down
docker compose up -d

Mais malheureusement ce n’est pas suffisant,
je peux vérifier ma configuration php via l’ajout de info.php
Je vois bien mon POST_MAX_SIZE en 5M mais j’ai néanmoins des erreurs de copie.

Il va falloir modifier le fichier nginx.conf, qui se trouve lui aussi dans le container nginx-proxy

On rentre dans le vif du conteneur

Un outil qui m’a particulièrement sauvé la vie c’est « d’entrer » dans les containers. Une fois qu’on a pris le pli, la différence entre un service sur un hôte et un service dans un conteneur est relativement trivial.

Donc on va déjà vérifier nos processus qui tournent

docker ps

d08fe4b4992c   nginx:latest                  "/docker-entrypoint.…"   48 minutes ago   Up 42 minutes   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   nginx-proxy
1213c1ca6896   wordpress:latest              "docker-entrypoint.s…"   48 minutes ago   Up 42 minutes   80/tcp                                                                     techromancien-wordpress

Je montre que ces deux containers la qui nous intéressent
Ensuite pour entrer dans ces containers, deux possibilités, soit 

• via le nom
• via l’id

Le plus simple étant via le nom mais parfois avec l’id on s’y retrouve mieux

docker exec -it <nom_du_conteneur> /bin/bash

dans mon cas

docker exec -it nginx-proxy /bin/bash