Executar o processamento em lote na biblioteca de mídia existente

O que a execução faz — e o que tem de estar ligado antes

Os dois módulos de imagem do Kakapo Performance trabalham no momento em que o WordPress gera os tamanhos de imagem: a compressão define a qualidade e remove os marcadores EXIF, IPTC e XMP dos tamanhos gerados; o módulo de formatos cria as derivadas WebP e AVIF. Ambos atuam, portanto, a partir do próximo upload. Para as imagens que já estão na biblioteca de multimédia não acontece nada — e é exatamente essa lacuna que a execução em lote fecha.

A execução não inventa trabalho. Aplica ao acervo exatamente aquilo que ligaste mais acima para os novos carregamentos: WebP e/ou AVIF e «Remover metadados». Se nada disso estiver ligado, o botão de arranque fica bloqueado e indica o motivo — por exemplo, que o servidor não consegue escrever WebP ou que simplesmente não há nenhuma definição ativa. Encontras o cartão «Reprocessar a biblioteca multimédia existente» na área «Imagens», por baixo das definições de imagem; a ordem na interface corresponde à ordem de utilização: primeiro configurar, depois deixar correr sobre o acervo.

São tocados exclusivamente anexos do tipo JPEG e PNG que não estejam no lixo. A linha “Imagens JPEG/PNG no acervo” indica-te o número antes de arrancares.

Iniciar, acompanhar, parar

Um clique em «Iniciar execução em lote» cria a execução e começa de imediato. O trabalho decorre em passagens com um orçamento de tempo de 8 segundos; depois disso, a passagem dá retorno, a indicação é atualizada e a seguinte arranca ao fim de 200 milissegundos. Se no fim de uma passagem restarem menos de 3,5 segundos, não se inicia mais nenhum anexo — o módulo de formato conta internamente com pelo menos três segundos por imagem. Em servidores com max_execution_time definido, o orçamento é ainda limitado a 80 por cento desse limite, para que a passagem não seja cortada a meio do pedido.

A barra mostra progresso real: número de anexos concluídos a dividir pelo número total. Por baixo estão os números correntes — derivadas geradas e ignoradas, uma linha para WebP e outra para AVIF, além dos ficheiros aligeirados e dos bytes libertados. Bem em baixo acompanham as últimas 14 linhas do registo, cada uma com o nome do ficheiro e aquilo que resultou desse ficheiro.

“Parar” interrompe a execução. O botão passa depois a chamar-se “Continuar”, e o arranque seguinte prossegue exatamente no anexo em que ficou. O mesmo acontece se simplesmente fechares o separador: a execução para e não se perde nada. Se voltares a abrir a página, ela consulta o estado e faz avançar por si própria uma execução ainda em aberto.

Como a execução sobrevive a uma interrupção

O estado é guardado antes do trabalho em cada anexo, e não só depois. Se uma passagem morrer a meio — limite de execução do servidor web, memória, um ficheiro em que o GD se engasga —, a passagem seguinte sabe onde emperrou. Se o mesmo anexo ficar três tentativas sem qualquer progresso, é posto de lado com uma linha em texto claro no registo, em vez de manter a execução presa para sempre a um ficheiro.

Duas páginas de administração abertas ao mesmo tempo não se podem atrapalhar: um bloqueio permite sempre apenas uma passagem. Se uma passagem for abatida pelo servidor web e o bloqueio ficar para trás, ao fim de 180 segundos ele é considerado órfão e é assumido.

Ao continuar, o número total é apurado de novo em vez de ficar congelado — entre parar e continuar pode ter havido carregamentos ou eliminações. Se desligares todas as definições de imagem a meio da execução, ela para-se a si própria, em vez de fazer trabalho que já ninguém encomendou. “Repor” descarta o progresso e o relatório; os ficheiros já gerados permanecem.

Ler o relatório corretamente

No fim aparece uma linha final com tamanhos de ficheiro medidos — não estimativas. Para cada derivada gerada, a execução compara o tamanho do original com o tamanho do resultado, ambos valores reais do momento da geração. Só é contado o que surgiu de novo nesta execução; o que já foi convertido durante o upload não aparece uma segunda vez.

Três coisas estão ali assim de propósito e não de forma mais bonita: WebP e AVIF têm linhas separadas, porque do mesmo original resultam duas derivadas — uma soma comum contaria o original a dobrar. Por isso, os valores percentuais valem por linha e não podem ser somados; um navegador vai sempre buscar apenas um dos dois formatos. E os novos ficheiros ocupam espaço adicional no disco: a poupança acontece na transmissão para o visitante. Espaço de armazenamento realmente livre só o dá a remoção dos metadados, e esses bytes constam de uma linha própria.

Se não foi gerado nada, o relatório também o diz: ou já estava tudo tratado para o acervo, ou nenhum resultado ficou mais pequeno do que o seu original. Um resultado que não seja mais pequeno é descartado e contado como “ignorado” — nunca como ganho.

Quando algo é ignorado

Cada derivada não gerada recebe um motivo em texto claro, e os motivos aparecem reunidos na linha final:

• «não é mais pequeno do que o original» — normal, o original mantém-se. • «demasiado grande para a memória disponível» — o módulo de formato verifica as dimensões da imagem antes de descodificar e recusa, em vez de deixar o PHP bater no limite de memória. • «já existia um ficheiro no destino» — não é substituído. Isso acontece tipicamente quando a nota no anexo se perdeu, mas os ficheiros ainda lá estão. • «não é legível» — danificado, JPEG em CMYK ou uma variante exótica. • «não é gravável» — verifica as permissões na pasta de uploads. • «formato não disponível neste servidor» — o AVIF exige PHP 8.1 ou mais recente com libavif, o WebP uma biblioteca GD com libwebp.

Duas coisas que são frequentemente tomadas por erros, mas não o são: uma segunda execução quase não mostra movimento, porque o que está feito não é repetido — uma marca no anexo regista para quantos ficheiros a remoção dos metadados já está concluída. E quem altera um nível de qualidade não renova com isso nenhum ficheiro já gerado; para isso, as derivadas teriam primeiro de desaparecer.