Erro HTTP no WordPress ao enviar imagem para a biblioteca de mídia

Você arrasta um JPG de 5 MB pra biblioteca de mídia, a barra chega no fim e aparece um lacônico “Erro HTTP”, sem mais nada. Quase sempre é uma de três coisas: o Imagick abortando no redimensionamento, memória travada no pool do PHP-FPM ou o arquivo nem chegando ao PHP. Dá pra separar as três em dois minutos.

Qual biblioteca está redimensionando

O upload em si quase nunca falha; quem quebra é a geração das miniaturas, logo depois. Veja com o que o site tenta redimensionar e quanta folga ele tem:

cd /var/www/rogertakemiya.com.br/html
sudo -u www-data wp eval 'var_dump( extension_loaded("imagick"), extension_loaded("gd") );'

grep -rE 'memory_limit|upload_max_filesize|post_max_size' /etc/php/8.3/fpm/
tail -30 /var/log/php8.3-fpm.log

Com o Imagick instalado o WordPress prefere ele: a ordem padrão do filtro wp_image_editors é Imagick e depois GD. E o ImageMagick tem limites próprios em /etc/ImageMagick-6/policy.xml — no Ubuntu vêm memory em 256MiB e width/height em 16KP. Estourou um deles, o processo morre, o PHP devolve 500 e o uploader mostra “Erro HTTP”. Esse arquivo vale pra máquina inteira: mexer nele afeta todos os sites do servidor.

Jogar o GD na frente

O mesmo filtro define a ordem de preferência. Num mu-plugin ele sobrevive à troca de tema:

<?php
// wp-content/mu-plugins/forcar-gd.php
add_filter( 'wp_image_editors', function () {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Voltou a funcionar? Era o Imagick. Se continua falhando, é memória — e não adianta só olhar o php.ini. Antes de redimensionar o WordPress chama wp_raise_memory_limit( 'image' ) e tenta subir sozinho para 256M, mas quando o memory_limit foi definido com php_admin_value no pool o ini_set é bloqueado e essa subida não acontece. Então edite /etc/php/8.3/fpm/pool.d/www.conf, deixe php_admin_value[memory_limit] = 256M e rode sudo systemctl reload php8.3-fpm. Foto de 12 MP descomprimida ocupa uns 150 MB; 128M não dá.

Última checagem antes de culpar o PHP: arquivo maior que o client_max_body_size do nginx nunca chega ao WordPress. O log de erro do nginx registra “client intended to send too large body” e nenhum ajuste no wp-config resolve.