Novedades Ehundu

Ehundu 0.15.0

2026-10-17T00:00:00+02:00

El contrato, repasado antes de congelarlo. La 0.15 no trae funciones nuevas: es la versión en la que se ha leído el contrato entero contra el código, para que lo que la 1.0 vaya a prometer sea cierto. Salen de ahí las decisiones 128 a 140 de docs/formato.md (se abre en una pestaña nueva). Lo que el motor hacía y solo estaba en el código queda escrito (las reglas exactas de los atajos, qué es un enlace a otro dominio, el orden de los textos, la tabla de letras del filtro slug, lo que el motor escribe en salida/), y lo que se tomaba a ciegas, por ser peligroso o ambiguo, ahora se avisa o detiene el build. Compilados con la 0.14.0 y con esta, los veintitrés sitios de prueba dan los mismos ficheros, uno a uno, sin avisos nuevos.

Lo que ahora detiene el build (con el fichero y la línea, en el error). Un formato que no es un entero mayor que cero ("2" entre comillas, 0): antes se avisaba y se tomaba por 1, y podía hacer pasar por bueno un proyecto de otro formato. Una url de sitio.yml con ruta o con parámetros (https://ejemplo.com/sub/): el motor la aceptaba y dejaba el sitio a medias, y la url es la del dominio, con o sin la barra final (decisiones 130 y 136). Un punto en el nombre de una página, de un fichero de datos/ o de un _datos.yml cuando lo que va tras el último punto no tiene forma de código de idioma (guia.v2.md, 2024.10.01-titulo.md): antes se saltaba el fichero con un aviso y el siguiente despliegue borraba la página del servidor (decisión 135).

Lo que ahora avisa. Una fecha (fecha, publicar) escrita con hora o con zona avisa y se toma solo el día, desde su medianoche en la zona del sitio: una fecha es un día (decisión 129). Los cinco campos que el motor escribe siempre en pagina (ruta, contenido, markdown, encabezados y traducciones) avisan si el front matter los usa, y el campo se ignora, como ya hacía idioma; antes los tapaban en silencio (decisión 133). componentes, reservado desde hace tiempo, avisa si un sitio lo usa como campo propio, aunque sigue llegando a la plantilla (decisión 138).

Lo que cambia en la salida. Una imagen enlazada a otro dominio lleva target="_blank" y rel, como cualquier enlace escrito en Markdown: la figura de una imagen sola enlazada y el atajo imagen con enlace. La plantilla imagen recibe dos variables nuevas, externo y rel; una plantilla imagen del sitio que no las use queda como la escribió (decisión 131). La carpeta publico/ deja de copiar lo que dejan el sistema y Git (.DS_Store, .gitkeep, Thumbs.db, desktop.ini y cualquier .git), y contenido/ ignora Thumbs.db y desktop.ini; .htaccess y .well-known/ se siguen copiando (decisión 138). Ninguno de los sitios de prueba cambia.

La compilación incremental persistida, más segura. La huella que decide si la memoria de .ehundu/ sirve para este motor mira ahora el contenido de los ficheros del motor y las versiones de sus dependencias instaladas (y la versión menor de PHP), no solo la fecha de los ficheros: un composer update que cambia Twig o CommonMark ya no reaprovecha páginas hechas con la versión anterior. Cada huella de un fichero anota cuándo se tomó, para que un fichero modificado mientras se compilaba no se dé por visto. La espera al cerrojo de .ehundu/ tiene un tope de un minuto, y un presupuesto de tiempo enorme en avanzar o en el despliegue ya no acaba tras la primera tarea. Ordenar por texto calcula la clave de cada página una vez, en vez de en cada comparación. Al actualizar, la primera compilación es completa (la memoria de la 0.14 no vale para esta): ocurre una vez.

Lo que la 1.0 promete y lo que no. La compilación por lotes (CompiladorPorLotes y su estado en .ehundu/lote.json) pasa a @internal: lo que se promete para repartir una compilación en llamadas es CompiladorIncrementalEnProceso::avanzar, que devuelve el mismo Lote. Si la usabas, sigue funcionando; solo deja de estar prometida (decisión 128). docs/biblioteca.md precisa los parámetros por nombre de Desplegador::desplegar y lo que hay dentro de Pagina::$campos y de Lectura::$datos. El contrato promete el mismo HTML con la misma versión del motor y de sus dependencias, y no entre versiones: lo que cambie al actualizar se anotará aquí (decisión 137).

Para quien incruste la biblioteca. Formato::leer ya no recibe los avisos: lanza ErrorDeProyecto si el valor no vale. Informe::$rehechas vale siempre un número (en una compilación completa, el de páginas), no null. Para un despliegue propio, Configuracion::abrir abre el destino que dice la configuración, y PlanDeDespliegue::deSalida y PlanDeDespliegue::ficheros trazan o leen los ficheros de salida/ sin repetir el código del despliegue. Y Manifiesto::leer rechaza las rutas que salen del sitio (.., una barra inicial, una letra de unidad): el manifiesto vive en el destino, y quien pudiera escribirlo allí no debe poder hacer que Ehundu borre otra cosa. Con --todo se rehace.

Documentación. El registro de decisiones pasa al final de formato.md, como apéndice A, para que quien lee el contrato encuentre la norma antes que su historia (las secciones no se renumeran). El esquema de los editores tiene su documento, docs/esquema.md (se abre en una pestaña nueva), que separa lo que es formato de cómo se comporta un editor. La documentación seguirá en español, como el formato: no se promete en inglés. Y ehundu --version (o -V) dice qué versión es.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.16.0

2026-10-17T00:00:00+02:00

La relectura final del contrato. La 0.16 no trae funciones nuevas: es la versión en la que tres lectores independientes comprobaron el contrato, línea a línea, contra el código (unas 250 afirmaciones, de las que unas 200 eran ciertas tal cual). Salen de ahí las decisiones 141 a 148 de docs/formato.md (se abre en una pestaña nueva): unos noventa retoques del texto, que deja escrito lo que el motor hacía sin decirlo (los ficheros de texto son UTF-8, un [nombre] registrado es siempre una llamada, qué es pagina.ruta en una página generada, cómo comparan donde y orden, qué cuenta como vacío en el esquema…), la regla 7 de nombres, y unos pocos arreglos del código para que cumpla lo que el contrato ya decía. Compilados con la 0.15.0 y con esta, los veintitrés sitios de prueba dan los mismos ficheros, uno a uno, sin avisos nuevos.

Lo que ahora detiene el build. Un nombre con la extensión de un fichero que se quiere generar (robots.txt.twig, sitemap.xml.twig, llms.txt.md, tabla.csv.yml): antes se saltaba con un aviso y un código de salida 0, y el siguiente despliegue borraba el robots.txt publicado. El error dice cómo hacerlo: una página robots.twig con url: /robots.txt (decisión 143). Un código de idioma que el sitio no declara (contacto.fr.md) sigue siendo un aviso.

Lo que ahora avisa. Un atajo registrado con los atributos mal escritos ([imagen fichero=a.png], sin comillas), que se quedaba en la página como texto sin que nadie lo notara. Un feed.coleccion que ninguna página usa, que daba un feed vacío con la fecha de 1970. Una página con la extensión en mayúsculas o .markdown (LEEME.MD), que se copia tal cual (decisión 147).

Lo que cambia en la salida. Un día sin hora y sin comillas en un campo propio, en datos/ o en sitio.yml es ese día en la zona del sitio: con zonaHoraria: America/Mexico_City, |fecha escribía el 18 de marzo para el 19 (decisión 144). Los atajos imagen, video y archivo ya no leen un fichero de fuera de publico/: avisan y no insertan nada. svg() quita la declaración XML y el DOCTYPE aunque un comentario los separe. Un enlace a https://EJEMPLO.com ya es del sitio aunque el dominio vaya en mayúsculas. slugify vale también en el patrón de agrupar y de paginar, y paginar avisa de una url sin barra final aunque todo quepa en un trozo. Una url de solo espacios es una en blanco. Ninguno de los sitios de prueba cambia.

La memoria de la incremental, por registros. .ehundu/memoria.bin se guarda y se lee registro a registro, sin construir una cadena entera de la memoria, que en un sitio grande eran cien megas de más (decisión 141). En el sitio más pesado de los de prueba (1.204 páginas, 97 MB de memoria guardada) el pico de memoria de PHP baja de 332 a 170 MB en la primera compilación, de 352 a 190 al cambiar una página y de 416 a 252 al cambiar una plantilla; en dos sitios de 27 y 29 MB, de 102-134 a 50-82 MB. Y si la memoria guardada no cabe en el memory_limit de PHP (tres veces lo que mide el fichero más 16 MB), compilar compila entero sin tocarla y avisa a cuánto subirlo, y avanzar, que sin ella no puede repartir el trabajo, falla con ese mismo texto en vez del error de PHP. docs/compilacion.md lleva las medidas y lo que cabe con 128, 256 y 512 MB.

Para quien use la biblioteca. paginacion.cantidad se llama paginacion.entradas, sin alias, porque ningún sitio usa paginar todavía y el nombre no decía de qué (decisión 142; total sigue siendo el de páginas). Desplegador::desplegar con $todo ignora $segundos: repartido, no terminaba nunca. Version::ACTUAL se promete. Lote::progreso() de un lote ocupado() vale 0. La carpeta de destino de un despliegue carpeta se crea al subir el primer fichero y no al abrirla, así que --simular no deja nada (si tu código contaba con que abrir la creara, créala tú). Un volcado de Configuracion tampoco enseña dónde está la clave privada, y el sitemap.xml y el feed.xml de cada idioma se suben los últimos. docs/biblioteca.md gana lo que se promete y no estaba escrito: las firmas de Destino, ErrorDeProyecto, trazar, anotar y quitar, la semántica de Proyecto y de Pagina::$campos, los códigos de salida de la consola y el formato del manifiesto del despliegue.

Al actualizar. La primera compilación de cada sitio que tenga memoria guardada es completa, porque cambia cómo se guarda (una vez). El HTML de los sitios no cambia, así que no hay que volver a publicarlos. Si usabas pagina.paginacion.cantidad en una plantilla, cámbialo por entradas: Twig no avisa de un nombre que no existe.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.11.0

2026-10-16T00:00:00+02:00

Las imágenes con varios anchos salen con su srcset. Ehundu sigue sin procesar imágenes, pero ahora lee las variantes que otra herramienta (un editor al subir la foto, un programa aparte) deja en publico/. Con la sección imagenes de sitio.yml (anchos: [480, 960, 1600], formatos: [avif, webp] y un sizes si hace falta), la función variantes('img/foto') da src, ancho, alto, srcset y fuentes para escribir el <img> o el <picture>, y el atajo [imagen …] y las figuras del Markdown lo hacen solos. El srcset lleva el ancho real de cada fichero, porque quien genera las variantes no amplía una foto estrecha; una imagen sin variantes sale como antes, sin aviso; cada fichero que se busca, exista o no, es una dependencia de la página en la compilación incremental, y el feed pasa a direcciones completas las de cada srcset (docs/formato.md (se abre en una pestaña nueva), §2, §7.3 y §8.2, decisión 120).

Y una lista larga se parte en páginas con paginar. La propia página es la primera, en su dirección, y el motor genera las demás: paginar: {coleccion: blog, porPagina: 10, orden: fecha desc}. Cada una ve las entradas de su trozo en pagina.paginas y dónde está en pagina.paginacion (actual, total, anterior, siguiente, enlaces…). Por defecto salen en /blog/pagina/2/, y paginar.url con {{ numero }} cambia la forma para quien migra y no quiere perder direcciones. Una entrada nueva que desborde la última abre la siguiente sola. Las páginas que genera no entran en colecciones ni en el sitemap. Partir cada grupo de agrupar queda reservado (§6.4, decisión 121).

Los sitios de la 0.10 compilan igual: no cambia nada que no use imagenes ni paginar. Compilados desde cero con la 0.10.0 y con esta, los veintitrés sitios de prueba (PDF incluidos) dan los mismos ficheros, uno a uno.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.11.1

2026-10-16T00:00:00+02:00

Actualiza symfony/yaml a la 8.1.9, que corrige el CVE-2026-109413. La recursión sin límite del lector de YAML en línea permite que un solo documento tumbe el proceso. El ehundu.phar de la 0.11.0 llevaba dentro la 8.0.15: el composer.json de Ehundu calculaba su composer.lock como si el PHP fuera el 8.4.0, y la 8.1 pide el 8.4.1 o superior. Ahora el platform es 8.4.1 y el .phar lleva la 8.1.9.

No cambia nada del motor ni del formato: compilados desde cero con la 0.11.0 y con esta, los veintitrés sitios de prueba (PDF incluidos) dan los mismos ficheros, uno a uno. El mínimo sigue siendo PHP 8.4. Quien instala Ehundu con Composer y PHP 8.4.1 o superior ya recibía la 8.1.x; si tu proyecto tiene un composer.lock con la 8.0, composer update symfony/yaml.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.12.0

2026-10-16T00:00:00+02:00

Un sitio grande se compila y se sube en varias llamadas. Un proceso web tiene un límite de tiempo, y compilar de golpe un sitio de mil páginas no cabe. La interfaz nueva CompiladorPorLotes (con CompiladorPorLotesEnProceso y Lote como resultado) hace una parte del trabajo por llamada, con un presupuesto de segundos que da quien llama: iniciar($proyecto) empieza, avanzar($proyecto, 20.0) hace tareas hasta agotar el presupuesto, y siempre al menos una, y cuando completo() el informe() es el de una compilación entera y salida/ queda igual que si se hubiera compilado de una vez. Por dónde va se guarda en .ehundu/lote.json, dentro del proyecto, con su propio .gitignore para que no ensucie un repositorio; si el proyecto cambia a mitad, el lote empieza de nuevo y lo dice. La subida también se reparte: Desplegador::desplegar() acepta un presupuesto ($segundos) y una compilación ya hecha ($compilado), y InformeDeDespliegue dice si terminó ($completo) y cuántos ficheros quedan ($pendientes). Cada página se escribe al hacerla, así que salida/ mezcla páginas nuevas y viejas hasta el último lote. La orden ehundu no cambia (docs/formato.md (se abre en una pestaña nueva), §10.4 y decisiones 124 y 125; docs/compilacion.md (se abre en una pestaña nueva)).

Un proyecto declara para qué versión del formato está escrito: formato: 1. En sitio.yml (§2), y "formato": 1 en el esquema.json de un editor (§11). Sin la clave, el formato es el 1 y no se avisa, así que ningún proyecto de la 0.11 tiene que cambiar; un valor que no es un entero mayor que cero se avisa y se toma como 1; y uno mayor que el que entiende el motor detiene el build con un error claro, en lugar de compilar a ciegas un formato que no conoce. Es solo la versión mayor, porque dentro de una el formato únicamente crece (decisión 122; clase Ehundu\Formato).

Y por fin está escrito qué promete la biblioteca. docs/biblioteca.md (se abre en una pestaña nueva) lista la orden de consola y las clases PHP que se mantendrán estables dentro de una versión mayor: compilar, leer un proyecto, los avisos y los errores, Slug y el despliegue. Las demás clases llevan @internal y pueden cambiar en cualquier versión menor. Lo que va a dejar de valer avisa durante, al menos, una versión menor antes de quitarse (decisión 123). La 1.0 congelará el formato, la orden y esa lista.

Los sitios de la 0.11 compilan igual: no cambia nada que no use formato ni los lotes. Compilados desde cero con la 0.11.1 y con esta, los veintitrés sitios de prueba (PDF incluidos) dan los mismos ficheros, uno a uno, y compilados por lotes dan los mismos que de golpe.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.13.0

2026-10-16T00:00:00+02:00

La compilación incremental sale del proceso. Hasta ahora solo ehundu servir compilaba de forma incremental, porque lo que recuerda una compilación no sobrevivía al proceso que la hizo; quien incrustaba el motor en un proceso web, como un panel de edición, tenía que compilar el sitio entero en cada guardado. La clase nueva CompiladorIncrementalEnProceso (compilar, avanzar y olvidar, docs/biblioteca.md (se abre en una pestaña nueva)) guarda lo que recuerda en .ehundu/memoria.bin, dentro del proyecto, y la siguiente compilación, aunque sea de otro proceso, lo aprovecha: en el sitio más grande de los de prueba, 1.204 páginas, cambiar una página rehace una y tarda unos 3 s, frente a los 35-45 s de una compilación completa. El resultado es siempre el de una compilación completa: los mismos ficheros y los mismos avisos.

Y se puede repartir en llamadas. avanzar($proyecto, $segundos) rehace páginas hasta agotar el presupuesto y guarda lo hecho; la llamada siguiente sigue. No hace falta un estado aparte, como en la compilación por lotes: una memoria con la mitad de las páginas es una memoria a la que le faltan páginas, y el plan de la incremental rehace las que faltan y aprovecha las que valen, también si el proyecto cambia entre dos llamadas. El Informe de la llamada que termina cuenta la compilación entera, no solo su parte. Los lotes de la 0.12 siguen como estaban, para quien quiera repartir una compilación completa sin guardar nada del sitio.

La memoria se ignora sin error si no vale. Si falta, está dañada o cortada, la escribió otra versión de la memoria o del motor (lleva una huella del tamaño y la fecha de su código, así que actualizar el motor hace que la primera compilación sea entera), o es de otro proyecto, se hace una compilación completa. Solo se guarda cuando una llamada sale bien, y no se vuelve a escribir si no se ha rehecho ninguna página. Una llamada que llega mientras otra está compilando el mismo proyecto no la estropea: avanzar devuelve ocupado() y compilar espera. La memoria pesa del orden de salida/ más lo leído (97 MB en el sitio de 1.204 páginas) y el proceso que la carga necesita unos 350 MB en ese sitio; .ehundu/ lleva su propio .gitignore, y se puede borrar cuando se quiera (docs/formato.md (se abre en una pestaña nueva), §10.5, decisión 126; docs/compilacion.md (se abre en una pestaña nueva)).

Los sitios de la 0.12 compilan igual: no cambia nada que no use la clase nueva, y la orden ehundu no la usa. Compilados desde cero con la 0.12.0 y con esta, los veintitrés sitios de prueba (PDF incluidos) dan los mismos ficheros, uno a uno; y compilados con la incremental persistida, repartida en llamadas y después sin cambios, dan lo mismo que de golpe.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.14.0

2026-10-16T00:00:00+02:00

Las páginas llevan una marca de Ehundu. El motor añade <meta name="generator" content="Ehundu"> al <head> de cada página HTML que escribe, para que se reconozcan los sitios hechos con él, como hacen otros generadores. La etiqueta va justo antes del primer </head>, en su propia línea y con la sangría de esa línea más dos espacios (pegada a él, si el HTML está minificado). Se quita con una clave de sitio.yml:

generador: no

Sin versión, a propósito. El contenido es siempre Ehundu, sin el número de versión: con él, cada actualización del motor cambiaría todas las páginas de todos los sitios y obligaría a volver a subirlas, y quien mira el código de una web no tendría por qué saber qué versión exacta la hizo.

Lo que no cambia. Una página que ya trae su propia etiqueta generator en la plantilla se queda como está: manda la plantilla. Tampoco cambia lo que no tiene </head> (un fragmento, un .txt, un XML), ni el PDF de una página, ni el sitemap.xml ni el feed.xml. sí o no poner la clave es lo mismo; cualquier valor que no sea sí ni no avisa y se toma como sí. Cambiar la clave rehace todas las páginas, como cualquier otro cambio de sitio.yml (docs/formato.md (se abre en una pestaña nueva), §2, decisión 127).

Al actualizar. Es la primera vez que el motor toca el HTML que sale de las plantillas, y por eso cada página de cada sitio gana una línea al compilar con la 0.14: hay que volver a publicar los sitios una vez. No volverá a pasar de una versión a otra, porque la etiqueta no cambia con ella. Compilados con la 0.13.0 y con esta, los veintitrés sitios de prueba dan los mismos ficheros, uno a uno, salvo esa línea.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.10.0

2026-10-11T00:00:00+02:00

El texto con formato de un campo se convierte a HTML con el filtro markdown. Hasta ahora solo el cuerpo de una página se podía convertir de Markdown: un titular con una palabra en cursiva, o un resumen con una negrita, no tenía forma de llegar a la plantilla como HTML. Con titular: "Una cocina que *viaja*", {{ pagina.titular|markdown }} da Una cocina que <em>viaja</em>. Sin argumento es de línea: el Markdown sin bloques, sin <p>, con énfasis, negrita, tachado, código, enlaces, enlaces automáticos y HTML escrito a mano (<mark>, <br>); un salto de línea con una barra invertida o dos espacios al final de la línea sale como <br> (docs/formato.md (se abre en una pestaña nueva), §7.3, decisión 113).

Y de bloque, con markdown('bloque'). Para un texto con varios párrafos dentro de un bloque que pone la plantilla: se convierte como el cuerpo, con párrafos, listas, citas y encabezados. Sigue sin atajos, y no hace figuras de las imágenes, ni convierte tablas ni notas al pie, ni da id a los encabezados: eso es del cuerpo (decisión 114).

En los dos modos, los enlaces a otros dominios se tratan como en el cuerpo (target, rel y el aviso de enlacesExternos), el resultado no se escapa de nuevo, un valor vacío no da nada, un número se toma como texto, y una lista, un mapa o un sí o un no avisan. Un modo que no existe avisa y se usa el de línea.

Salió de rehacer un sitio con páginas de aterrizaje que se editan desde un panel: el esquema (§11) ya ofrecía el tipo markdown para cualquier campo, pero el motor no tenía cómo pintarlo.

Los sitios de la 0.9 compilan igual: son filtros nuevos y no cambian nada que no los use. Compilados desde cero con la 0.9.0 y con esta, los dieciséis sitios de prueba que compilan con la 0.9 dan los mismos ficheros, uno a uno.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.5.0

2026-10-10T00:00:00+02:00

Una página por cada valor. Una página con agrupar es una plantilla de páginas: el motor la repite por cada valor de un campo de las páginas de una colección, que es lo que hace falta para tener una página por etiqueta sin escribirla a mano, en un blog donde la siguiente entrada puede traer una etiqueta nueva. Agrupa por slug, así que Cultura pop y cultura-pop son un grupo; da a la plantilla grupo (la variante más usada) y paginas (las del grupo, con la forma de las que da coleccion()); no genera página para un grupo sin páginas publicadas; y con etiquetas: [temas] las páginas generadas forman una colección que sirve de índice. No ejecuta código del sitio, no es paginación (que sigue fuera de la v1) y la compilación incremental sabe de ella: una etiqueta nueva es una página nueva, y editar el cuerpo de una entrada no rehace las páginas de sus etiquetas (docs/formato.md (se abre en una pestaña nueva), §6.3, decisión 105).

Publicar en su fecha. Una fecha futura sigue sin ocultar nada, como la de un evento en una agenda. Para un blog que se escribe por adelantado, publicarEnSuFecha: sí en el _datos.yml de su carpeta hace que una página no se publique antes de su fecha: es lo mismo que escribir publicar con esa fecha, sin repetirla en cada fichero. Una subcarpeta lo quita con no, un publicar explícito manda sobre él y borrador sobre los dos. Una página retenida no genera fichero ni sale en colecciones, sitemap, feed ni traducciones, y sale cuando el sitio se vuelve a compilar después de su día (§4, decisión 106).

pagina.markdown. El Markdown de una página tal como está escrito, sin el front matter y sin convertir, para un llms-full.txt que reúna el texto de varios artículos. También lo tienen las páginas que da coleccion(). Quien lo lee depende del fichero de esa página (§7.2, decisión 104).

El formato, para los editores. El esquema (§11) describe ahora el orden manual de un tipo, las páginas fijas (unico), el menú lateral en secciones (grupo, rotulo, excluir), los borradores y la programación de páginas desde el editor (decisiones 99 a 103). El motor no lee ninguno de estos atributos: son cosas de los editores.

Los sitios de la 0.4 compilan igual, fichero a fichero. Lo único que cambia es que agrupar y publicarEnSuFecha son ahora campos reservados del front matter, y que grupo y paginas solo existen en las páginas que genera agrupar.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.6.0

2026-10-10T00:00:00+02:00

Las páginas de una carpeta, sin la carpeta en la URL. El patrón de url tiene ahora {{ nombreDeFichero }}: el nombre del fichero de la página, sin carpeta, sin extensión y sin el código de idioma. Con url: "/{{ nombreDeFichero }}/" en el _datos.yml de contenido/posts/, el fichero mi-entrada.md sale como /mi-entrada/ y no como /posts/mi-entrada/, y una entrada nueva no tiene que escribir nada. Admite |slug, en una página con agrupar es el nombre del fichero que genera las páginas, y manda sobre un campo que se llame igual. Es lo que hacía falta para migrar un blog cuyas direcciones nunca llevaron la carpeta (docs/formato.md (se abre en una pestaña nueva), §5.1, decisión 107).

El aviso de los enlaces que abren otra pestaña. Un enlace a otro sitio escrito en Markdown ya salía con target="_blank" y rel="noopener". La nueva sección enlacesExternos de sitio.yml añade a esos enlaces noreferrer (noreferrer: sí) y un texto oculto para los lectores de pantalla, que avisa de que se abre otra pestaña (aviso: (abre en ventana nueva)). En un sitio con varios idiomas, el aviso lleva un texto por idioma, con su código como clave, y cada página usa el suyo. La clase del texto es visually-hidden o la que diga clase: el motor no trae CSS, así que el sitio define la suya. Un enlace que solo envuelve una imagen, que es una figura, no lo lleva, y el HTML escrito a mano y los enlaces de las plantillas no se tocan. Sin la sección, los enlaces salen como antes (§2 y §8, decisión 108).

Los sitios de la 0.5 compilan igual, fichero a fichero. Lo único que cambia es que nombreDeFichero vale ahora en los patrones de url, donde antes no existía, y que enlacesExternos es una clave de sitio.yml con significado.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.7.0

2026-10-10T00:00:00+02:00

Un id para los encabezados del Markdown, y un índice con ellos. La nueva sección encabezados de sitio.yml da un id a los encabezados del Markdown de los niveles que se indiquen (niveles: [2], y por defecto del 2 al 6): el slug de su texto, con -2, -3… si se repite en la página, y seccion si no deja nada. Con enlace: ¶ cada uno termina en un enlace permanente a su apartado, con la clase que defina el sitio y una etiqueta para lectores de pantalla (Enlace a «{texto}», con un texto por idioma en un sitio con varios). Las plantillas leen la lista en pagina.encabezados, con nivel, texto e id de cada uno, para construir un índice; también la tienen las páginas de una colección. Actúa al convertir el Markdown y no recorre después el HTML ya generado: no toca los encabezados de un atajo que envuelve contenido, ni los del HTML escrito a mano, ni los que ponen las plantillas. Sin la sección, el Markdown sale como antes (docs/formato.md (se abre en una pestaña nueva), §2, §7.2 y §8, decisión 109).

El slug conoce ș y ț. La tabla tenía ş y ţ, con cedilla, pero no las letras rumanas con coma debajo, así que Ceaușescu daba ceau-escu. Ahora da ceausescu (§5.2).

Los sitios de la 0.6 compilan igual, fichero a fichero. Lo único que cambia es que encabezados es una clave de sitio.yml con significado, que encabezados es ahora una variable de página que tapa un campo del front matter del mismo nombre, y las direcciones o ids de los textos con ș o ț.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.8.0

2026-10-10T00:00:00+02:00

Los textos se ordenan sin contar ¿ ni ¡. Al ordenar con orden(), los signos de apertura de pregunta y de exclamación ya no cuentan: «¿Cómo llegar?» se ordena como «Cómo llegar?», entre las «c», y no al principio de la lista, que es donde lo mandaba el orden de los caracteres. Dos textos que solo se distinguen por esos signos empatan y quedan en el orden que tenían. El resto de la puntuación cuenta como hasta ahora, y las mayúsculas, las tildes y la ñ siguen igual (docs/formato.md (se abre en una pestaña nueva), §6.2, decisión 110).

Los sitios de la 0.7 compilan igual, fichero a fichero, salvo los que ordenen por un texto que lleve esos signos: en ellos solo cambia la posición de esas páginas en la lista.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.9.0

2026-10-10T00:00:00+02:00

El CSS y el JavaScript de una página se pueden enlazar como un fichero. css_fichero() y js_fichero() hacen con lo que la página ha declarado lo mismo que css() y js(), pero en lugar de incrustarlo escriben la etiqueta que enlaza un fichero con ese mismo contenido: <link rel="stylesheet" href="/css/3fa9c1d2ab.css"> o <script src="/js/7c01e4b9d3.js" defer></script>. El motor escribe el fichero en salida/css/ o salida/js/ con la huella de su contenido en el nombre (los 10 primeros caracteres del SHA-256), así que las páginas que declaran lo mismo lo comparten y el navegador puede guardarlo un año sin riesgo de servir uno viejo tras un cambio. Es para el CSS largo, que incrustado se repite en cada página. css() y js() no cambian, y el motor sigue sin minificar ni procesar nada (docs/formato.md (se abre en una pestaña nueva), §9.1, decisión 111).

version(ruta) da la dirección de un fichero de publico/ con la huella de su contenido, /css/estilo.css?v=3fa9c1d2ab, para enlazar con una caducidad larga las tipografías, el JavaScript suelto y lo demás que no pasa por css() (§7.3, decisión 112).

Los sitios de la 0.8 compilan igual, fichero a fichero. Solo cambia el texto del aviso que sale cuando una página declara CSS y ninguna plantilla lo escribe, que ahora nombra las dos formas.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.3.2

2026-09-29T00:00:00+02:00

Las fechas, también en alemán. fecha() escribe los meses y los días en alemán en las páginas en ese idioma, con mayúscula, como se escriben, y «18. März 2025» por defecto; fecha('l j F Y') da «Dienstag 18 März 2025». Hasta ahora salían en inglés, y un sitio con idioma: de avisaba de ello en cada compilación (docs/formato.md (se abre en una pestaña nueva), §15.9, decisión 89).

Una fecha imposible dentro de una lista de varias líneas ya no detiene la compilación. Desde la 0.3.1, una fecha sin comillas que no existe, como 2026-13-01, se lee como el texto que es. Faltaba un caso: dentro de una lista o un mapa entre corchetes que ocupa varias líneas, la lectura del YAML entero seguía fallando, con un error que señalaba el corchete de cierre («Cerca de «]»»). Ahora se lee como texto también ahí, y la misma fecha escrita dentro de un texto no se toca (§4, decisión 88).

Un feed sin entradas ya no cambia en cada compilación. Su fecha (updated) era el momento de la compilación, así que un feed vacío salía distinto cada vez: se volvía a escribir en salida/ y se volvía a subir en cada despliegue, y la previsualización podía dar un feed distinto del de una compilación completa. Ahora lleva siempre el 1 de enero de 1970 en la zona horaria del sitio. Con entradas no cambia nada: lleva la fecha de la más reciente (§10.2, decisión 90).

Los sitios de la 0.3 compilan igual, fichero a fichero, salvo en dos cosas: en las páginas en alemán, las fechas que escribe fecha() salen en alemán y no en inglés, y un feed sin entradas lleva la fecha de 1970.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.4.0

2026-09-29T00:00:00+02:00

El PDF de una página. Una página con pdf: sí sale también como PDF, además de como HTML. Lo maqueta su propia plantilla, <plantilla>.pdf.twig, con los mismos datos que la de la web pero con HTML y CSS sencillos (el PDF no admite flex ni rejilla). Sale en la dirección de la página con .pdf en lugar de la barra final, y las plantillas lo enlazan con pagina.pdf. Es una salida más de la compilación, declarada por la página, y no un procesador sobre el HTML de otra (docs/formato.md (se abre en una pestaña nueva), §10.3, decisiones 96 y 97).

El PDF lo genera dompdf, que es opcional. Es PHP puro, sin programas externos ni GD, y se instala con composer require dompdf/dompdf (hace falta la extensión dom). El motor solo lo pide si una página declara pdf: sí; si falta, la compilación se detiene con un error que lo dice. El ehundu.phar no lo trae: para generar PDF hay que usar el motor por Composer.

El mismo proyecto da siempre los mismos bytes. El PDF lleva la fecha de la página (o el 1 de enero de 1970 si no tiene), un identificador sacado de su contenido y la caché de tipografías en la carpeta temporal del sistema, así que no escribe fuera de salida/ y solo lee de publico/. Un PDF que no cambia no se vuelve a subir en el despliegue, y la compilación incremental lo tiene en cuenta: lo que dompdf lee de publico/ cuenta como dependencia de la página.

Los ficheros PHP detienen la compilación. Un fichero PHP en publico/ o en contenido/ (.php, .php3 a .php8, .pht, .phtml, .phar, y también foto.php.jpg, que algunos servidores ejecutan) ya no se copia: el error dice cuál es. Un sitio estático no tiene por qué llevarlos, y en uno infectado son lo primero que se cuela (§9, decisión 98). Es lo único que puede impedir compilar un sitio de la 0.3.

El formato, para los editores. El esquema (§11) admite una lista dentro de una lista de campos simples, campos traducible con un texto por idioma, el tipo seleccion-multiple con las opciones en datos/, recuerda (lo que un editor guarda de las filas de una lista) y ficheros de datos/ editables desde el esquema (§11.1 a §11.5, decisiones 91 a 95). El motor no lee ninguno de estos atributos: son cosas de los editores, y el motor solo lee lo que ellos escriben en el proyecto.

Los sitios de la 0.3 compilan igual, fichero a fichero, salvo que lleven ficheros PHP en publico/ o contenido/.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.3.1

2026-09-28T00:00:00+02:00

Una fecha imposible sin comillas ya no detiene la compilación. fecha: 2026-13-01 o publicar: 2026-01-32, sin comillas, hacían fallar la lectura del YAML entero («El YAML no es válido»). Ahora avisan con fichero y línea y el campo cuenta como si no estuviera, igual que ya pasaba con fecha: 2025-02-31, en el front matter y en _datos.yml. En un campo que no es reservado, esa fecha llega a la plantilla como el texto que es, sin aviso (docs/formato.md (se abre en una pestaña nueva), §4, decisión 88).

El despliegue por FTP ya no se atasca en ciertos tamaños de fichero. Algunos servidores FTPS cortan siempre la subida de algunos tamaños exactos de fichero, sea cual sea su contenido, y repetirla no servía de nada. Ahora, como último recurso, un fichero que no sube entero se sube en dos partes, la segunda añadida al final (APPE), y se comprueba que llega con su tamaño; queda dicho en un aviso (docs/despliegue.md (se abre en una pestaña nueva)).

El esquema para un editor, en el formato. esquema.json (§11) describe ya lo que necesita un editor de verdad: carpetas con comodín y en lista, campos con ayuda y con rol, el tipo enlace, grupos y listas de un nivel, el nombre de fichero de las páginas nuevas y el cuerpo con su rótulo (decisiones 82 a 87). El motor no lo lee; es para los programas que lo incrustan.

La marca, aparte de la licencia. La licencia MIT cubre el código y la documentación, pero no el logotipo ni las ilustraciones de marca/ (marca/README.md (se abre en una pestaña nueva)); las ilustraciones tampoco van en el paquete de Composer. Ehundu es un proyecto de Paigar.

Los sitios de la 0.3 compilan igual, fichero a fichero, sin cambiar nada.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.2.0

2026-09-27T00:00:00+02:00

orden y donde ven también url y ruta, con los mismos valores que las plantillas: donde('url', '/contacto/') encuentra una página aunque su URL salga de la ruta del fichero y no esté escrita en el front matter. contenido no cuenta, para no convertir el cuerpo de todas las páginas de la lista (decisión 71 de docs/formato.md (se abre en una pestaña nueva)).

El despliegue guarda en el manifiesto la url del sitio y se detiene antes de tocar nada, también al simular, si el destino es de otro sitio: con varios sitios en el mismo servidor, una ruta equivocada borraría lo que subió el otro. --todo confirma que es el mismo sitio con otra dirección. Un manifiesto de la 0.1, sin url, se acepta y la gana en el siguiente despliegue (decisión 70; docs/despliegue.md (se abre en una pestaña nueva)).

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.3.0

2026-09-27T00:00:00+02:00

Sitios en varios idiomas, con un fichero por idioma en el mismo árbol: contacto.md y contacto.eu.md son la misma página en castellano y en euskera, sin declararlo en ningún sitio. Los idiomas se declaran en idiomas de sitio.yml, y el primero es el predeterminado. Un sitio en un solo idioma no escribe nada de esto y compila igual que con la 0.2 (docs/formato.md (se abre en una pestaña nueva), §15, decisiones 72 a 81).

Cada idioma con su prefijo en la URL, que Ehundu pone también a la URL escrita en url y a la de un patrón: url: /instalazioak/ en instalaciones.eu.md da /eu/instalazioak/, y el patrón de un _datos.yml vale para todos los idiomas.

Las traducciones, en las plantillas: pagina.idioma, pagina.traducciones (las versiones publicadas de la página, ella incluida) y sitio.idiomas, con lo que una plantilla escribe los hreflang y un selector de idioma que nunca enlaza a una página que no existe. Traducir solo una parte del sitio es lo normal: no hay respaldo automático ni avisos por las traducciones que faltan.

Colecciones y datos de cada idioma. coleccion() da las páginas del idioma de la página que la pide, o de otro con coleccion('blog', 'eu') o 'todos'. datos/menus.eu.yml se mezcla con datos/menus.yml en las páginas en euskera, _datos.eu.yml va encima del _datos.yml de su carpeta, y lo que no se traduce de una página puede ir en un .yml con su nombre, común a todas sus versiones.

fecha() en el idioma de la página, con castellano, euskera («2025eko martxoaren 18a») e inglés; también en los sitios de un solo idioma que no están en castellano.

Un sitemap con todos los idiomas y un feed por idioma (/feed.xml, /eu/feed.xml).

La compilación incremental de ehundu servir sabe qué traducciones mira cada página y sigue dando siempre lo mismo que una compilación completa (docs/compilacion.md (se abre en una pestaña nueva)).

Cambios para los sitios de la 0.2: sitio.idioma vale es si sitio.yml no lo dice, y el feed lleva siempre xml:lang; un .yml dentro de contenido/ con el nombre de una página deja de copiarse a salida/, porque son sus campos comunes; idioma pasa a ser un campo reservado; y dos ficheros de la misma página en el mismo idioma (contacto.md y contacto.twig) detienen la compilación.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.

Ehundu 0.1.0

2026-09-26T00:00:00+02:00

Primera versión utilizable de Ehundu: compila sitios de Markdown y Twig, los previsualiza con compilación incremental y los publica en una carpeta, por FTP, por SFTP o en un almacenamiento compatible con S3.

Esta versión en GitHub (se abre en una pestaña nueva), con el ehundu.phar.