Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Document silverback:api-components:imagine:generate (pre-generating imagine variants)

Cerrado Apto para principiantes
#213 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
kubernetes, php

Línea de trabajo

Empieza en la sección uploads / imagine dentro de content/4.api/ y documenta, según los detalles del issue, el comando, sus opciones, la salida y el flujo de trabajo posterior al despliegue. Explica cuándo ejecutarlo, su seguridad y su comportamiento al terminar, así como el paso para purgar la caché HTTP. La tarea estará terminada cuando la página describa con precisión el comando y el flujo de trabajo indicados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The API bundle adds a console command to generate missing imagine variants ahead of requests: components-web-app/api-components-bundle#416 (issue components-web-app/api-components-bundle#413).

Please document it in the bundle's uploads / imagine section (content/4.api/).

What to document

Why it exists. When an app adds an imagine filter to an existing field, every existing image needs a new variant. Without this command, each variant is generated the first time the API serialises a resource holding the image, inside a visitor's request. A page with many images then generates many variants in one request, within the web pod's memory limit. A variant skipped over the memory budget is retried on every request.

The command.

bin/console silverback:api-components:imagine:generate [--filter=<filter> ...] [--class=<FQCN> ...] [--dry-run] [-v]
  • Walks every uploadable entity and field, drafts included. A field's filters are its UploadableField imagineFilters plus, for an entity implementing ImagineFiltersInterface, getImagineFilters($property, null). Only raster images are processed (SVG and non-images are left out).
  • Generates, one at a time, each variant that is not stored yet, and saves its file info. Originals and stored variants are not touched, so it is safe to re-run after an interruption: a second run generates nothing.
  • --filter (repeatable) only generates those filters; a name that is not a configured LiipImagine filter set exits 2 before anything runs. --class (repeatable) only walks that uploadable class or its subclasses; a class that is not uploadable exits 2.
  • Variants are written with the field's imagineCacheControl (from #[UploadableField]), falling back to silverback_api_components.uploadable.cache_control.imagine, exactly as variants generated during a request.
  • --dry-run counts what is missing and generates nothing.
  • Output: counts of generated, already stored, skipped over the memory budget, failed, and original missing (a dry run prints "To generate" instead of "Generated"). -v lists each variant.
  • Exit code 1 if any variant failed, so a Kubernetes Job shows as failed. Variants skipped over the memory budget, and originals whose file is missing, are reported but exit 0.
  • It uses the same memory budget as request-time generation (silverback_api_components.imagine.memory_limit), and a CLI with memory_limit=-1 is never checked. A variant over the budget is logged and skipped.
  • Only registered when LiipImagineBundle is enabled.

How to run it after a deploy that adds a filter.

  1. Run the command as a one-off Kubernetes Job from the API (php) image, so the image processing stays out of the web pods. Optionally run --dry-run first to see how many variants are missing.
  2. Then purge the HTTP cache (bin/console silverback:api-components:purge-http-cache, or POST /_/http_cache/purge), so cached API responses and pages list the new variants.
Lenguaje dominante
Vue
Estrellas
0
Forks
0
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de components-web-app/docs

Todos los issues de components-web-app/docs

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.