OFERTA DE LANZAMIENTO — LIMITADA Das Nest Lifetime 499 € 149 € Conseguir oferta →
KakapoWP KakapoWP
Centro de ayuda/Performance/Ejecutar el procesamiento por lotes sobre la biblioteca de medios existente

Ejecutar el procesamiento por lotes sobre la biblioteca de medios existente

Válido para: Kakapo Performance· 5 min de lectura

Qué hace la ejecución — y qué tiene que estar encendido antes

Los dos módulos de imagen de Kakapo Performance trabajan en el momento en que WordPress genera los tamaños de imagen: la compresión fija la calidad y elimina los marcadores EXIF, IPTC y XMP de los tamaños generados; el módulo de formato crea los derivados WebP y AVIF. Ambos surten efecto, por tanto, a partir de la próxima subida. Con las imágenes que ya están en la biblioteca de medios no pasa nada — y justo esa laguna la cierra la ejecución por lotes.

La pasada no se inventa trabajo. Aplica al material existente exactamente lo que has activado más arriba para las subidas nuevas: WebP y/o AVIF, y «Eliminar metadatos». Si no hay nada de eso activado, el botón de inicio queda bloqueado e indica el motivo — por ejemplo, que el servidor no puede escribir WebP o que sencillamente no hay ninguna opción activa. La tarjeta «Reprocesar la biblioteca de medios existente» la encuentras en el apartado «Imágenes», debajo de los ajustes de imagen; el orden en la interfaz corresponde al orden de manejo: primero configurar, después dejar que recorra el material existente.

Solo se tocan los adjuntos de tipo JPEG y PNG que no estén en la papelera. La fila «Imágenes JPEG/PNG en el inventario» te da la cifra antes de que empieces.

Iniciar, observar, detener

Un clic en «Iniciar pasada por lotes» crea la pasada y la arranca de inmediato. El trabajo ocurre en tandas con un presupuesto de tiempo de 8 segundos; después la tanda informa, la vista se actualiza y la siguiente arranca 200 milisegundos más tarde. Si al final de una tanda queda menos de 3,5 segundos de tiempo restante, ya no se empieza con otro adjunto — el módulo de formatos cuenta internamente con al menos tres segundos por imagen. En servidores con max_execution_time definido, el presupuesto se limita además al 80 por ciento de ese límite, para que la tanda no se corte en mitad de la petición.

La barra muestra el progreso real: número de adjuntos terminados dividido por el total. Debajo están las cifras en curso — derivados generados y omitidos, una línea para WebP y otra para AVIF, además de los archivos aligerados y los bytes liberados. Del todo abajo van pasando las últimas 14 líneas del registro, cada una con el nombre del archivo y lo que salió con ese archivo.

«Detener» para la ejecución. Después el botón se llama «Continuar», y el siguiente inicio sigue exactamente por el adjunto en el que se quedó. Lo mismo pasa si simplemente cierras la pestaña: la ejecución se detiene y no se pierde nada. Si vuelves a abrir la página, esta consulta el estado y hace avanzar por su cuenta una ejecución que siga abierta.

Cómo sobrevive la ejecución a una interrupción

El estado se guarda antes del trabajo en cada adjunto concreto, no después. Si una pasada muere a mitad de camino — límite de ejecución del servidor web, memoria de trabajo, un archivo con el que GD se atraganta —, la siguiente pasada sabe dónde se atascó. Si el mismo adjunto se queda tres intentos seguidos sin ningún progreso, se pasa por alto con una línea en texto claro en el registro, en lugar de retener la ejecución para siempre en un solo archivo.

Dos páginas de administración abiertas a la vez no pueden estorbarse: un bloqueo permite siempre una sola pasada. Si el servidor web mata una pasada y el bloqueo se queda ahí, a los 180 segundos se considera huérfano y se toma el relevo.

Al continuar, el total se vuelve a calcular en lugar de quedar congelado — entre detener y continuar se puede haber subido o borrado algo. Si en mitad de la ejecución apagas todos los ajustes de imagen, esta se detiene sola en lugar de hacer un trabajo que ya nadie ha encargado. «Restablecer» descarta el progreso y el informe; los archivos ya generados se quedan donde están.

Leer bien el informe

Al final hay una línea de cierre con tamaños de archivo medidos — no estimaciones. Para cada derivado generado, la ejecución compara el tamaño del original con el tamaño del resultado, ambos valores reales del momento de la generación. Solo se cuenta lo que ha surgido nuevo en esta ejecución; lo que ya se convirtió al subirlo no vuelve a aparecer.

Tres cosas están ahí así a propósito y no más bonitas: WebP y AVIF tienen filas separadas, porque del mismo original salen dos derivados — una suma común contaría el original dos veces. Por eso los porcentajes valen por fila y no se pueden sumar; un navegador siempre se lleva solo uno de los dos formatos. Y los archivos nuevos ocupan además espacio en el disco: el ahorro está en la transmisión al visitante. Espacio de almacenamiento solo lo libera de verdad la eliminación de los metadatos, y esos bytes aparecen en una fila propia.

Si no se ha generado nada, el informe también lo dice: o bien ya estaba todo hecho para el inventario, o ningún resultado era más pequeño que su original. Un resultado que no es más pequeño se descarta y se cuenta como «omitido» — nunca como ganancia.

Cuando algo se omite

Cada derivado que no se genera recibe un motivo en texto claro, y los motivos aparecen reunidos en la línea final:

• «no es más pequeño que el original» — es normal, el original se mantiene. • «demasiado grande para la memoria disponible» — el módulo de formatos comprueba las dimensiones de la imagen antes de descodificarla y la rechaza, en lugar de dejar que PHP se estrelle contra el límite de memoria. • «en el destino ya había un archivo» — no se sobrescribe. Eso ocurre normalmente cuando se ha perdido la nota del adjunto pero los archivos siguen ahí. • «no legible» — defectuoso, JPEG en CMYK o una variante exótica. • «no escribible» — comprueba los permisos de la carpeta de subidas. • «formato no disponible en este servidor» — AVIF requiere PHP 8.1 o posterior con libavif; WebP, una biblioteca GD con libwebp.

Dos cosas que a menudo se toman por errores, pero no lo son: una segunda ejecución apenas muestra movimiento, porque lo que ya está hecho no se repite — una marca en el adjunto anota para cuántos archivos ya está hecha la eliminación de los metadatos. Y quien cambia un nivel de calidad no renueva con ello ningún archivo ya generado; para eso habría que quitar antes los derivados.

¿Te ha resultado útil este artículo?