Contrato de generación de PDF

Fenómenus almacena diseños de PDF reutilizables como contenido privado de WordPress con revisiones habilitadas. Cada diseño contiene un documento completo con versión de esquema; los clientes deben preservar schemaVersion y enviar el documento completo al reemplazar un diseño.

API admitida

Los usuarios autenticados con las capacidades pertinentes de WordPress pueden usar estas rutas bajo pom-restaurant-menus/v1:

La creación de presets está reservada a los administradores. Las operaciones sobre diseños exigen capacidades coincidentes de edición o eliminación. La generación de PDF requiere además permiso de subida de archivos. Las proyecciones dinámicas están en una lista permitida; no se aceptan metadatos de entradas arbitrarios, estados, taxonomías, claves de ordenación ni activos remotos.

El repositorio de diseños impone un máximo de 15 diseños activos en todo el sitio, tanto en los formularios de administración como en la creación o duplicación mediante REST. La eliminación siempre es forzada y elimina el archivo estable de subidas más un adjunto de PDF heredado localizado de forma segura antes de borrar la entrada del diseño.

Una solicitud de vista previa del editor puede pasar limit: -1 para cargar todas las entradas legibles que coincidan. Un valor positivo actúa únicamente como límite de rendimiento de edición. El renderizado de impresión siempre resuelve la consulta completa de origen de datos guardada.

Las integraciones pueden registrar una definición explícita de origen de datos con pom_rm_menu_pdf_data_sources. Los observadores de generación pueden escuchar pom_rm_pdf_generation_result, que recibe el resultado generado o WP_Error, seguido del ID del diseño.

Modelo de documento y componentes

Un documento posee ajustes de página, tokens de tema, orígenes de datos, plantillas, secciones, activos y CSS personalizado opcional. Las secciones usan cover, content o back-cover. Una sección de contenido contiene un bloque de feed redimensionable y se convierte en tantas páginas físicas como sea necesario sin transformar cada página de desbordamiento en un feed editable de forma independiente.

Cada feed hace referencia a tres plantillas de componentes reutilizables:

• feed para el contenido anterior al bucle;
• category para los términos en cada nivel de jerarquía;
• item para cada entrada.

Cada componente tiene un lienzo en milímetros y bloques secundarios posicionados libremente. Las posiciones X y los anchos de los bloques secundarios se escalan proporcionalmente al ancho del componente renderizado; las posiciones Y, las alturas, el espaciado, la rotación y el orden de capas permanecen explícitos. Actualizar un componente actualiza todas sus instancias en todas las páginas.

Las plantillas de término almacenan reglas breakBeforeDepths independientes. Los bloques pueden dirigirse a profundidades de jerarquía, y sus márgenes y relleno contribuyen a la altura de paginación medida. Los bloques de contenedor de feed y de término también admiten reglas de repetición específicas del contexto.

Los elementos creados admitidos incluyen texto fijo, imágenes, iconos, formas, campos dinámicos y feeds. El texto y los campos dinámicos renderizados como texto pueden rellenar el ancho restante con una línea de puntos conductora. Los campos dinámicos de elemento pueden enlazar título, descripciones, precios, imagen destacada, meta expuesta, categorías y términos de alérgenos. Los enlaces de imagen pueden declarar alternativas ordenadas por campo y URL fija. Las colecciones de alérgenos admiten la visualización de icono o imagen cuando la carga del término expone un activo asignado.

El feed posee su identificador de origen de datos. Los enlaces de componentes reutilizables heredan ese origen: los campos del contenedor de feed exponen valores de feed, documento y sitio; los campos de término exponen además el término agrupado; los campos de elemento de bucle exponen además la entrada actual y sus valores de taxonomía proyectados. El editor aislado de componentes usa siempre texto, imagen, imagen de taxonomía, precio e icono representativos como marcadores de posición. Nunca vincula el diseño del componente a la primera entrada legible. Los datos reales siguen siendo visibles en la vista previa completa del feed y en el renderizado de impresión.

La validación del documento rechaza un segundo feed que haga referencia a un origen de datos ya utilizado por otro feed. Esta invariante se aplica tanto a las escrituras REST como a los controles del editor.

Renderizado y almacenamiento de archivos

La generación realiza el siguiente comportamiento público:

1. Valida el documento guardado y las capacidades del usuario actual.
2. Resuelve los datos de origen completos de cada sección habilitada mediante la lista permitida.
3. Renderiza el documento en una página de renderizado de WordPress firmada y de corta duración.
4. Usa Chrome o Chromium para imprimir esa página a PDF.
5. Valida que el archivo sea un PDF no vacío.
6. Rechaza salidas superiores a 150 MB y, a continuación, reemplaza atómicamente el archivo estable del diseño en el directorio de subidas del sitio activo sin crear un adjunto en la Biblioteca de medios.
7. Elimina los archivos temporales de renderizado y libera el bloqueo de generación.

El archivo permanente usa la base de subidas de WordPress del sitio activo seguida de pom-restaurant-menus/pdfs/catalog-{design-id}.pdf. En multisitio, WordPress proporciona la base de subidas específica del sitio antes de ese subdirectorio. La regeneración mantiene una copia en el servidor, devuelve una URL y un nombre de archivo con versión de caché e informa de un ID de adjunto de cero para la compatibilidad con los consumidores existentes de la API.

Los archivos temporales usan un directorio temporal privado con permisos de escritura y no son la ubicación de descarga. Solo puede ejecutarse una generación a la vez por instancia de aplicación; los clientes deben mostrar las respuestas de conflicto y volver a intentarlo más tarde.

Una vez iniciada una generación, el sitio activo rechaza nuevos intentos durante 120 segundos con datos de respuesta HTTP 429 y remainingSeconds/retryAfter. El bloqueo de generación sigue siendo la autoridad en pestañas simultáneas y devuelve HTTP 409 mientras otro proceso del navegador esté imprimiendo activamente.

Dependencias en tiempo de ejecución

La instalación de Composer del plugin proporciona chrome-php/chrome, que inicia y controla el navegador. El servidor debe proporcionar igualmente un ejecutable compatible de Chrome o Chromium. Composer no puede empaquetar un navegador de sistema portátil dentro de la librería PHP.

El ejecutable se descubre a partir de las rutas de plataforma admitidas o puede configurarse con POM_RM_PDF_CHROME_PATH. El proceso PHP debe poder ejecutar el navegador, acceder a la URL local de renderizado firmada del sitio, escribir en el directorio temporal y en las subidas de WordPress, y cargar los medios y fuentes locales permitidos del diseño. Cada proceso del navegador recibe directorios HOME y XDG privados con permisos de escritura bajo el directorio temporal de PDF configurado, de modo que los usuarios de servicio sin un directorio de inicio del sistema operativo con permisos de escritura puedan iniciar Chromium de forma segura. Esos directorios en tiempo de ejecución se eliminan después de que el navegador se cierre o PHP se apague. El informe de fallos está deshabilitado para estos procesos de renderizado de corta duración, y Chromium usa archivos temporales en lugar de un montaje de memoria compartida restringido.

El renderizador usa el JavaScript incluido en el plugin y la compilación de Paged.js. No depende de un servicio de renderizado externo. Las fuentes personalizadas seleccionadas entre los ajustes de tema admitidos deben exponer orígenes de fuentes legibles por el navegador.

Contrato de estilos

Las variables de tema expuestas por el editor son los colores del documento junto con las fuentes de encabezados y cuerpo. Las elecciones de fuentes seguras y las fuentes configuradas en el tema se copian en el documento como definiciones de fuente admitidas. Los tokens de espaciado almacenados siguen siendo compatibles con el esquema, mientras que el diseño creado usa los márgenes y rellenos explícitos en milímetros de cada bloque.

document.customCss lo comparten la vista previa del editor y el renderizador de impresión. El mismo campo está disponible en el panel CSS izquierdo y bajo la referencia del selector de la capa actual. El CSS guardado se sanea para eliminar importaciones, URL de activos remotos, expresiones ejecutables y comportamientos de navegador no seguros. Las clases estables incluyen .pom-rm-pdf-document, .pom-rm-feed, .pom-rm-feed-term, .pom-rm-feed-item, .block-{id}, .field-{id}, .term-depth-{n}, .is-featured y .has-allergen-{slug}.