Ehundu News

Ehundu 0.15.0

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

The contract, reviewed before freezing it. 0.15 brings no new features: it is the version in which the whole contract was read against the code, so that what 1.0 is going to promise is true. Decisions 128 to 140 of docs/formato.md (opens in a new tab) come out of it. What the engine did and was only in the code is now written down (the exact rules of shortcodes, what a link to another domain is, the order of texts, the table of letters of the slug filter, what the engine writes in salida/), and what was taken blindly, because it was dangerous or ambiguous, now warns or stops the build. Built with 0.14.0 and with this one, the twenty-three test sites give the same files, one by one, with no new warnings.

What now stops the build (with the file and the line, in the error). A formato that is not an integer greater than zero ("2" in quotes, 0): before it was warned about and taken as 1, and it could pass off a project of another format as good. A url in sitio.yml with a path or with parameters (https://ejemplo.com/sub/): the engine accepted it and left the site half done, and the url is that of the domain, with or without the trailing slash (decisions 130 and 136). A dot in the name of a page, of a datos/ file or of a _datos.yml when what follows the last dot is not shaped like a language code (guia.v2.md, 2024.10.01-titulo.md): before, the file was skipped with a warning and the next deployment deleted the page from the server (decision 135).

What now warns. A date (fecha, publicar) written with a time or a zone warns and only the day is taken, from its midnight in the zone of the site: a date is a day (decision 129). The five fields that the engine always writes in pagina (ruta, contenido, markdown, encabezados and traducciones) warn if the front matter uses them, and the field is ignored, as idioma already was; before, they covered them silently (decision 133). componentes, reserved for some time, warns if a site uses it as a field of its own, although it still reaches the template (decision 138).

What changes in the output. An image linked to another domain carries target="_blank" and rel, like any link written in Markdown: the figure of a single linked image and the imagen shortcode with enlace. The imagen template receives two new variables, externo and rel; an imagen template of the site that does not use them stays as it was written (decision 131). The publico/ folder stops copying what the system and Git leave behind (.DS_Store, .gitkeep, Thumbs.db, desktop.ini and any .git), and contenido/ ignores Thumbs.db and desktop.ini; .htaccess and .well-known/ are still copied (decision 138). None of the test sites changes.

The persisted incremental build, safer. The fingerprint that decides whether the memory in .ehundu/ is good for this engine now looks at the content of the engine's files and the versions of its installed dependencies (and the minor version of PHP), not only at the date of the files: a composer update that changes Twig or CommonMark no longer reuses pages made with the previous version. Each file fingerprint notes when it was taken, so that a file modified while building is not taken as seen. The wait for the lock on .ehundu/ has a limit of one minute, and an enormous time budget in avanzar or in the deployment no longer ends after the first task. Sorting by text calculates the key of each page once, instead of in every comparison. When updating, the first build is a full one (the memory from 0.14 is not valid for this one): it happens once.

What 1.0 promises and what it does not. Batch building (CompiladorPorLotes and its state in .ehundu/lote.json) becomes @internal: what is promised for spreading a build over calls is CompiladorIncrementalEnProceso::avanzar, which returns the same Lote. If you used it, it still works; it is just no longer promised (decision 128). docs/biblioteca.md specifies the named parameters of Desplegador::desplegar and what is inside Pagina::$campos and Lectura::$datos. The contract promises the same HTML with the same version of the engine and its dependencies, and not between versions: what changes when updating will be noted here (decision 137).

For whoever embeds the library. Formato::leer no longer receives the warnings: it throws ErrorDeProyecto if the value is not valid. Informe::$rehechas is always a number (in a full build, that of pages), not null. For a deployment of your own, Configuracion::abrir opens the destination the configuration says, and PlanDeDespliegue::deSalida and PlanDeDespliegue::ficheros trace or read the files in salida/ without repeating the deployment code. And Manifiesto::leer rejects paths that leave the site (.., a leading slash, a drive letter): the manifest lives at the destination, and whoever could write it there must not be able to make Ehundu delete something else. With --todo it is rebuilt.

Documentation. The record of decisions moves to the end of formato.md, as appendix A, so that whoever reads the contract finds the rule before its history (the sections are not renumbered). The schema for editors has its own document, docs/esquema.md (opens in a new tab), which separates what is format from how an editor behaves. The documentation will stay in Spanish, like the format: it is not promised in English. And ehundu --version (or -V) says which version it is.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.16.0

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

The final reading of the contract. 0.16 brings no new features: it is the version in which three independent readers checked the contract, line by line, against the code (about 250 claims, of which about 200 were true as they stood). Decisions 141 to 148 of docs/formato.md (opens in a new tab) come out of it: some ninety touch-ups to the text, which writes down what the engine did without saying so (text files are UTF-8, a registered [nombre] is always a call, what pagina.ruta is on a generated page, how donde and orden compare, what counts as empty in the schema…), rule 7 on names, and a few fixes to the code so that it does what the contract already said. Built with 0.15.0 and with this one, the twenty-three test sites give the same files, one by one, with no new warnings.

What now stops the build. A name with the extension of a file you want to generate (robots.txt.twig, sitemap.xml.twig, llms.txt.md, tabla.csv.yml): before, it was skipped with a warning and an exit code of 0, and the next deployment deleted the published robots.txt. The error says how to do it: a robots.twig page with url: /robots.txt (decision 143). A language code that the site does not declare (contacto.fr.md) is still a warning.

What now warns. A shortcode registered with badly written attributes ([imagen fichero=a.png], without quotes), which stayed on the page as text without anybody noticing. A feed.coleccion that no page uses, which gave an empty feed with the date of 1970. A page with its extension in capitals or .markdown (LEEME.MD), which is copied as it is (decision 147).

What changes in the output. A day without a time and without quotes in a field of your own, in datos/ or in sitio.yml is that day in the zone of the site: with zonaHoraria: America/Mexico_City, |fecha wrote 18 March for 19 March (decision 144). The imagen, video and archivo shortcodes no longer read a fichero from outside publico/: they warn and insert nothing. svg() removes the XML declaration and the DOCTYPE even if a comment separates them. A link to https://EJEMPLO.com is already internal even if the domain is in capitals. slugify also works in the pattern of agrupar and paginar, and paginar warns about a url without a trailing slash even if everything fits in one chunk. A url of only spaces is a blank one. None of the test sites changes.

The memory of the incremental build, by records. .ehundu/memoria.bin is saved and read record by record, without building a whole string of the memory, which on a large site was a hundred megabytes too many (decision 141). On the heaviest of the test sites (1,204 pages, 97 MB of saved memory) the peak of PHP memory goes down from 332 to 170 MB on the first build, from 352 to 190 when changing a page and from 416 to 252 when changing a template; on two sites of 27 and 29 MB, from 102-134 to 50-82 MB. And if the saved memory does not fit in the memory_limit of PHP (three times the size of the file plus 16 MB), compilar builds everything without touching it and warns how far to raise it, and avanzar, which cannot spread the work without it, fails with that same text instead of the PHP error. docs/compilacion.md carries the measurements and what fits with 128, 256 and 512 MB.

For whoever uses the library. paginacion.cantidad is now called paginacion.entradas, with no alias, because no site uses paginar yet and the name did not say what of (decision 142; total is still the one for pages). Desplegador::desplegar with $todo ignores $segundos: spread out, it never finished. Version::ACTUAL is promised. Lote::progreso() of a batch that is ocupado() is 0. The destination folder of a carpeta deployment is created when the first file is uploaded and not when it is opened, so --simular leaves nothing behind (if your code counted on opening it to create it, create it yourself). A dump of Configuracion no longer shows where the private key is either, and the sitemap.xml and feed.xml of each language are uploaded last. docs/biblioteca.md gains what is promised and was not written: the signatures of Destino, ErrorDeProyecto, trazar, anotar and quitar, the semantics of Proyecto and Pagina::$campos, the exit codes of the console and the format of the deployment manifest.

When updating. The first build of each site that has saved memory is a full one, because how it is saved changes (once). The HTML of the sites does not change, so they do not have to be published again. If you used pagina.paginacion.cantidad in a template, change it to entradas: Twig does not warn about a name that does not exist.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.11.0

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

Images with several widths come out with their srcset. Ehundu still does not process images, but now it reads the variants that another tool (an editor when you upload the photo, a separate program) leaves in publico/. With the imagenes section of sitio.yml (anchos: [480, 960, 1600], formatos: [avif, webp] and a sizes if needed), the variantes('img/foto') function gives src, ancho, alto, srcset and fuentes to write the <img> or the <picture>, and the [imagen …] shortcode and the figures in Markdown do it by themselves. The srcset carries the real width of each file, because whoever generates the variants does not enlarge a narrow photo; an image without variants comes out as before, without a warning; every file that is looked for, whether it exists or not, is a dependency of the page in the incremental build, and the feed turns the addresses in each srcset into complete ones (docs/formato.md (opens in a new tab), §2, §7.3 and §8.2, decision 120).

And a long list is split into pages with paginar. The page itself is the first one, at its address, and the engine generates the rest: paginar: {coleccion: blog, porPagina: 10, orden: fecha desc}. Each one sees the entries of its chunk in pagina.paginas and where it is in pagina.paginacion (actual, total, anterior, siguiente, enlaces…). By default they come out at /blog/pagina/2/, and paginar.url with {{ numero }} changes the form for whoever migrates and does not want to lose addresses. A new entry that overflows the last page opens the next one by itself. The pages it generates do not enter collections or the sitemap. Splitting each agrupar group is reserved (§6.4, decision 121).

0.10 sites build the same: nothing changes that does not use imagenes or paginar. Built from scratch with 0.10.0 and with this one, the twenty-three test sites (PDFs included) give the same files, one by one.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.11.1

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

Updates symfony/yaml to 8.1.9, which fixes CVE-2026-109413. The unbounded recursion of the inline YAML reader lets a single document bring the process down. The ehundu.phar of 0.11.0 carried 8.0.15 inside: Ehundu's composer.json calculated its composer.lock as if PHP were 8.4.0, and 8.1 asks for 8.4.1 or higher. Now the platform is 8.4.1 and the .phar carries 8.1.9.

Nothing changes in the engine or the format: built from scratch with 0.11.0 and with this one, the twenty-three test sites (PDFs included) give the same files, one by one. The minimum is still PHP 8.4. Whoever installs Ehundu with Composer and PHP 8.4.1 or higher was already receiving 8.1.x; if your project has a composer.lock with 8.0, composer update symfony/yaml.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.12.0

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

A large site is built and uploaded in several calls. A web process has a time limit, and building a thousand-page site in one go does not fit. The new CompiladorPorLotes interface (with CompiladorPorLotesEnProceso and Lote as the result) does part of the work per call, with a budget of seconds given by the caller: iniciar($proyecto) starts, avanzar($proyecto, 20.0) does tasks until the budget runs out, and always at least one, and when completo() the informe() is that of a whole build and salida/ is left the same as if it had been built in one go. Where it has got to is saved in .ehundu/lote.json, inside the project, with its own .gitignore so that it does not clutter a repository; if the project changes halfway, the batch starts again and says so. The upload is also spread out: Desplegador::desplegar() accepts a budget ($segundos) and an already finished build ($compilado), and InformeDeDespliegue says whether it finished ($completo) and how many files are left ($pendientes). Each page is written as it is made, so salida/ mixes new and old pages until the last batch. The ehundu command does not change (docs/formato.md (opens in a new tab), §10.4 and decisions 124 and 125; docs/compilacion.md (opens in a new tab)).

A project declares which version of the format it is written for: formato: 1. In sitio.yml (§2), and "formato": 1 in the esquema.json of an editor (§11). Without the key, the format is 1 and there is no warning, so no 0.11 project has to change; a value that is not an integer greater than zero is warned about and taken as 1; and one greater than the one the engine understands stops the build with a clear error, instead of blindly building a format it does not know. It is only the major version, because within one the format only grows (decision 122; class Ehundu\Formato).

And at last it is written down what the library promises. docs/biblioteca.md (opens in a new tab) lists the console command and the PHP classes that will remain stable within a major version: building, reading a project, warnings and errors, Slug and deployment. The other classes carry @internal and may change in any minor version. What is going to stop being valid warns for at least one minor version before being removed (decision 123). 1.0 will freeze the format, the command and that list.

0.11 sites build the same: nothing changes that does not use formato or batches. Built from scratch with 0.11.1 and with this one, the twenty-three test sites (PDFs included) give the same files, one by one, and built in batches they give the same ones as in one go.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.13.0

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

The incremental build leaves the process. Until now only ehundu servir built incrementally, because what a build remembers did not survive the process that made it; whoever embedded the engine in a web process, such as an editing panel, had to build the whole site on every save. The new CompiladorIncrementalEnProceso class (compilar, avanzar and olvidar, docs/biblioteca.md (opens in a new tab)) saves what it remembers in .ehundu/memoria.bin, inside the project, and the next build, even from another process, takes advantage of it: on the largest of the test sites, 1,204 pages, changing one page rebuilds one and takes about 3 s, against the 35-45 s of a full build. The result is always that of a full build: the same files and the same warnings.

And it can be spread over calls. avanzar($proyecto, $segundos) rebuilds pages until the budget runs out and saves what it has done; the next call carries on. No separate state is needed, as in batch building: a memory with half the pages is a memory with pages missing, and the plan of the incremental build rebuilds the missing ones and reuses the valid ones, also if the project changes between two calls. The Informe of the call that finishes counts the whole build, not just its part. The 0.12 batches stay as they were, for whoever wants to spread a full build without saving anything about the site.

The memory is ignored without an error if it is not valid. If it is missing, damaged or cut off, was written by another version of the memory or of the engine (it carries a fingerprint of the size and date of its code, so updating the engine makes the first build a full one), or belongs to another project, a full build is done. It is only saved when a call ends well, and it is not written again if no page has been rebuilt. A call that arrives while another is building the same project does not spoil it: avanzar returns ocupado() and compilar waits. The memory weighs about the same as salida/ plus what was read (97 MB on the 1,204-page site) and the process that loads it needs about 350 MB on that site; .ehundu/ carries its own .gitignore, and can be deleted whenever you like (docs/formato.md (opens in a new tab), §10.5, decision 126; docs/compilacion.md (opens in a new tab)).

0.12 sites build the same: nothing changes that does not use the new class, and the ehundu command does not use it. Built from scratch with 0.12.0 and with this one, the twenty-three test sites (PDFs included) give the same files, one by one; and built with the persisted incremental build, spread over calls and then without changes, they give the same as in one go.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.14.0

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

Pages carry an Ehundu mark. The engine adds <meta name="generator" content="Ehundu"> to the <head> of every HTML page it writes, so that sites made with it can be recognised, as other generators do. The tag goes just before the first </head>, on its own line and with the indentation of that line plus two spaces (attached to it, if the HTML is minified). It is removed with a key in sitio.yml:

generador: no

Without a version, on purpose. The content is always Ehundu, without the version number: with it, every update of the engine would change all the pages of all the sites and force them to be uploaded again, and whoever looks at the code of a website has no reason to know which exact version made it.

What does not change. A page that already carries its own generator tag in the template stays as it is: the template rules. Nor does anything change for what has no </head> (a fragment, a .txt, an XML), the PDF of a page, the sitemap.xml or the feed.xml. sí or not putting the key is the same; any value that is neither sí nor no warns and is taken as sí. Changing the key rebuilds all the pages, like any other change to sitio.yml (docs/formato.md (opens in a new tab), §2, decision 127).

When updating. It is the first time the engine touches the HTML that comes out of templates, and that is why every page of every site gains a line when building with 0.14: sites have to be published again once. It will not happen again from one version to the next, because the tag does not change with it. Built with 0.13.0 and with this one, the twenty-three test sites give the same files, one by one, except for that line.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.10.0

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

Formatted text in a field is converted to HTML with the markdown filter. Until now only the body of a page could be converted from Markdown: a headline with an italic word, or a summary with some bold, had no way of reaching the template as HTML. With titular: "A kitchen that *travels*", {{ pagina.titular|markdown }} gives A kitchen that <em>travels</em>. Without an argument it is inline: Markdown without blocks, without <p>, with emphasis, bold, strikethrough, code, links, automatic links and hand-written HTML (<mark>, <br>); a line break with a backslash or two spaces at the end of the line comes out as <br> (docs/formato.md (opens in a new tab), §7.3, decision 113).

And block-level, with markdown('bloque'). For a text with several paragraphs inside a block that the template provides: it is converted like the body, with paragraphs, lists, quotes and headings. It still has no shortcodes, and it does not turn images into figures, nor convert tables or footnotes, nor give headings an id: that is for the body (decision 114).

In both modes, links to other domains are treated as in the body (target, rel and the enlacesExternos notice), the result is not escaped again, an empty value gives nothing, a number is taken as text, and a list, a map or a yes or a no warn. A mode that does not exist warns and the inline one is used.

It came out of rebuilding a site with landing pages that are edited from a panel: the schema (§11) already offered the markdown type for any field, but the engine had no way to paint it.

0.9 sites build the same: they are new filters and change nothing that does not use them. Built from scratch with 0.9.0 and with this one, the sixteen test sites that build with 0.9 give the same files, one by one.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.5.0

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

One page for each value. A page with agrupar is a template of pages: the engine repeats it for each value of a field of the pages of a collection, which is what you need to have one page per tag without writing it by hand, on a blog where the next post may bring a new tag. It groups by slug, so Cultura pop and cultura-pop are one group; it gives the template grupo (the most used variant) and paginas (those of the group, with the shape of the ones coleccion() gives); it generates no page for a group with no published pages; and with etiquetas: [temas] the generated pages form a collection that serves as an index. It runs no code from the site, it is not pagination (which stays outside v1) and the incremental build knows about it: a new tag is a new page, and editing the body of a post does not rebuild the pages of its tags (docs/formato.md (opens in a new tab), §6.3, decision 105).

Publish on its date. A future fecha still hides nothing, like that of an event in a calendar. For a blog that is written in advance, publicarEnSuFecha: sí in the _datos.yml of its folder makes a page not be published before its fecha: it is the same as writing publicar with that date, without repeating it in every file. A subfolder removes it with no, an explicit publicar overrides it and borrador overrides both. A held-back page generates no file and does not appear in collections, sitemap, feed or translations, and it comes out when the site is built again after its day (§4, decision 106).

pagina.markdown. The Markdown of a page as it is written, without the front matter and unconverted, for an llms-full.txt that gathers the text of several articles. The pages that coleccion() gives have it too. Whoever reads it depends on the file of that page (§7.2, decision 104).

The format, for editors. The schema (§11) now describes the manual order of a type, fixed pages (unico), the side menu in sections (grupo, rotulo, excluir), drafts and the scheduling of pages from the editor (decisions 99 to 103). The engine reads none of these attributes: they are matters for editors.

0.4 sites build the same, file by file. The only thing that changes is that agrupar and publicarEnSuFecha are now reserved fields of the front matter, and that grupo and paginas only exist on the pages that agrupar generates.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.6.0

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

The pages of a folder, without the folder in the URL. The url pattern now has {{ nombreDeFichero }}: the file name of the page, without folder, without extension and without the language code. With url: "/{{ nombreDeFichero }}/" in the _datos.yml of contenido/posts/, the file mi-entrada.md comes out as /mi-entrada/ and not as /posts/mi-entrada/, and a new post has nothing to write. It accepts |slug, in a page with agrupar it is the name of the file that generates the pages, and it overrides a field with the same name. It is what was needed to migrate a blog whose addresses never carried the folder (docs/formato.md (opens in a new tab), §5.1, decision 107).

The notice for links that open another tab. A link to another site written in Markdown already came out with target="_blank" and rel="noopener". The new enlacesExternos section of sitio.yml adds noreferrer to those links (noreferrer: sí) and a hidden text for screen readers, which warns that another tab opens (aviso: (opens in a new window)). On a site with several languages, the notice takes one text per language, with its code as the key, and each page uses its own. The class of the text is visually-hidden or the one clase says: the engine brings no CSS, so the site defines its own. A link that only wraps an image, which is a figure, does not carry it, and hand-written HTML and the links in templates are not touched. Without the section, links come out as before (§2 and §8, decision 108).

0.5 sites build the same, file by file. The only thing that changes is that nombreDeFichero now works in url patterns, where it did not exist before, and that enlacesExternos is a key of sitio.yml with a meaning.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.7.0

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

An id for Markdown headings, and a contents list built from them. The new encabezados section of sitio.yml gives an id to the Markdown headings of the levels you indicate (niveles: [2], and by default from 2 to 6): the slug of their text, with -2, -3… if it repeats on the page, and seccion if nothing is left. With enlace: ¶ each one ends in a permanent link to its section, with the clase the site defines and an etiqueta for screen readers (Link to «{texto}», with one text per language on a site with several). Templates read the list in pagina.encabezados, with the nivel, texto and id of each one, to build a contents list; the pages of a collection have it too. It acts when converting the Markdown and does not afterwards walk the HTML already generated: it does not touch the headings of a shortcode that wraps content, nor those of hand-written HTML, nor those that templates put in (docs/formato.md (opens in a new tab), §2, §7.2 and §8, decision 109).

The slug knows ș and ț. The table had ş and ţ, with a cedilla, but not the Romanian letters with a comma below, so Ceaușescu gave ceau-escu. Now it gives ceausescu (§5.2).

0.6 sites build the same, file by file. The only things that change are that encabezados is a key of sitio.yml with a meaning, that encabezados is now a page variable that covers a front matter field of the same name, and the addresses or ids of texts with ș or ț.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.8.0

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

Texts are sorted without counting ¿ or ¡. When sorting with orden(), the opening question and exclamation marks (the inverted ones that Spanish uses) no longer count: “¿Cómo llegar?” is sorted as “Cómo llegar?”, among the “c”s, and not at the start of the list, which is where the order of the characters sent it. Two texts that differ only by those marks tie and stay in the order they had. The rest of the punctuation counts as before, and capitals, accents and ñ stay the same (docs/formato.md (opens in a new tab), §6.2, decision 110).

0.7 sites build the same, file by file, except those that sort by a text that carries those marks: in them, only the position of those pages in the list changes.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.9.0

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

The CSS and JavaScript of a page can be linked as a file. css_fichero() and js_fichero() do with what the page has declared the same as css() and js(), but instead of embedding it they write the tag that links a file with that same content: <link rel="stylesheet" href="/css/3fa9c1d2ab.css"> or <script src="/js/7c01e4b9d3.js" defer></script>. The engine writes the file in salida/css/ or salida/js/ with the fingerprint of its content in the name (the first 10 characters of the SHA-256), so pages that declare the same thing share it and the browser can keep it for a year with no risk of serving an old one after a change. It is for long CSS, which embedded is repeated on every page. css() and js() do not change, and the engine still minifies and processes nothing (docs/formato.md (opens in a new tab), §9.1, decision 111).

version(ruta) gives the address of a file in publico/ with the fingerprint of its content, /css/estilo.css?v=3fa9c1d2ab, to link with a long expiry the fonts, loose JavaScript and anything else that does not go through css() (§7.3, decision 112).

0.8 sites build the same, file by file. The only thing that changes is the text of the warning that appears when a page declares CSS and no template writes it, which now names both ways.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.3.2

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

Dates, in German too. fecha() writes months and days in German on pages in that language, capitalised as they are written, and “18. März 2025” by default; fecha('l j F Y') gives “Dienstag 18 März 2025”. Until now they came out in English, and a site with idioma: de warned about it on every build (docs/formato.md (opens in a new tab), §15.9, decision 89).

An impossible date inside a multi-line list no longer stops the build. Since 0.3.1, a date without quotes that does not exist, such as 2026-13-01, is read as the text it is. One case was missing: inside a list or a map in square brackets that spans several lines, the reading of the whole YAML still failed, with an error that pointed at the closing bracket (“Cerca de «]»”). Now it is read as text there too, and the same date written inside a text is left alone (§4, decision 88).

A feed with no entries no longer changes on every build. Its date (updated) was the moment of the build, so an empty feed came out different every time: it was rewritten in salida/ and uploaded again on every deployment, and the preview could give a different feed from the one of a full build. Now it always carries 1 January 1970 in the time zone of the site. With entries nothing changes: it carries the date of the most recent one (§10.2, decision 90).

0.3 sites build the same, file by file, except in two things: on pages in German, the dates that fecha() writes come out in German and not in English, and a feed with no entries carries the date of 1970.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.4.0

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

The PDF of a page. A page with pdf: sí also comes out as a PDF, as well as HTML. Its own template lays it out, <plantilla>.pdf.twig, with the same data as the web one but with simple HTML and CSS (the PDF supports neither flex nor grid). It comes out at the address of the page with .pdf instead of the trailing slash, and templates link to it with pagina.pdf. It is one more output of the build, declared by the page, and not a processor over the HTML of another (docs/formato.md (opens in a new tab), §10.3, decisions 96 and 97).

The PDF is generated by dompdf, which is optional. It is pure PHP, with no external programs or GD, and is installed with composer require dompdf/dompdf (the dom extension is needed). The engine only asks for it if a page declares pdf: sí; if it is missing, the build stops with an error that says so. The ehundu.phar does not bring it: to generate PDFs you have to use the engine through Composer.

The same project always gives the same bytes. The PDF carries the date of the page (or 1 January 1970 if it has none), an identifier taken from its content and the font cache in the system's temporary folder, so it writes nothing outside salida/ and only reads from publico/. A PDF that does not change is not uploaded again in the deployment, and the incremental build takes it into account: what dompdf reads from publico/ counts as a dependency of the page.

PHP files stop the build. A PHP file in publico/ or in contenido/ (.php, .php3 to .php8, .pht, .phtml, .phar, and also foto.php.jpg, which some servers run) is no longer copied: the error says which one it is. A static site has no reason to carry them, and in an infected one they are the first thing that gets in (§9, decision 98). It is the only thing that can prevent a 0.3 site from building.

The format, for editors. The schema (§11) admits a list inside a list of simple fields, traducible (“translatable”) fields with one text per language, the seleccion-multiple (“multiple choice”) type with the options in datos/, recuerda (“remembers”: what an editor keeps from the rows of a list) and datos/ files editable from the schema (§11.1 to §11.5, decisions 91 to 95). The engine reads none of these attributes: they are matters for editors, and the engine only reads what they write into the project.

0.3 sites build the same, file by file, unless they carry PHP files in publico/ or contenido/.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.3.1

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

An impossible date without quotes no longer stops the build. fecha: 2026-13-01 or publicar: 2026-01-32, without quotes, made the reading of the whole YAML fail (“El YAML no es válido”). Now they warn with the file and the line and the field counts as if it were not there, just as fecha: 2025-02-31 already did, in the front matter and in _datos.yml. In a field that is not reserved, that date reaches the template as the text it is, without a warning (docs/formato.md (opens in a new tab), §4, decision 88).

Deployment over FTP no longer gets stuck on certain file sizes. Some FTPS servers always cut the upload of some exact file sizes, whatever their content, and repeating it did not help. Now, as a last resort, a file that does not upload whole is uploaded in two parts, the second one appended at the end (APPE), and it is checked that it arrives with its size; a warning says so (docs/despliegue.md (opens in a new tab)).

The schema for an editor, in the format. esquema.json (§11) now describes what a real editor needs: folders with wildcards and in a list, fields with help and with a role, the enlace type, groups and one-level lists, the file name of new pages and the body with its label (decisions 82 to 87). The engine does not read it; it is for the programs that embed it.

The brand, apart from the licence. The MIT licence covers the code and the documentation, but not the logo or the illustrations in marca/ (marca/README.md (opens in a new tab)); the illustrations are not in the Composer package either. Ehundu is a Paigar project.

The 0.3 sites build the same, file by file, without changing anything.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.2.0

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

orden and donde also see url and ruta, with the same values as the templates: donde('url', '/contacto/') finds a page even if its URL comes from the path of the file and is not written in the front matter. contenido does not count, so as not to convert the body of every page in the list (decision 71 of docs/formato.md (opens in a new tab)).

The deployment saves the url of the site in the manifest and stops before touching anything, also when simulating, if the destination belongs to another site: with several sites on the same server, a wrong ruta would delete what the other one uploaded. --todo confirms that it is the same site with another address. A manifest from 0.1, with no url, is accepted and gets one on the next deployment (decision 70; docs/despliegue.md (opens in a new tab)).

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.3.0

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

Sites in several languages, with one file per language in the same tree: contacto.md and contacto.eu.md are the same page in Spanish and in Basque, without declaring it anywhere. The languages are declared in idiomas in sitio.yml, and the first one is the default. A site in a single language writes none of this and builds the same as with 0.2 (docs/formato.md (opens in a new tab), §15, decisions 72 to 81).

Each language with its prefix in the URL, which Ehundu also applies to the URL written in url and to the one from a pattern: url: /instalazioak/ in instalaciones.eu.md gives /eu/instalazioak/, and the pattern of a _datos.yml works for all languages.

The translations, in the templates: pagina.idioma, pagina.traducciones (the published versions of the page, itself included) and sitio.idiomas, with which a template writes the hreflang and a language selector that never links to a page that does not exist. Translating only part of the site is the normal case: there is no automatic fallback and no warnings for the translations that are missing.

Collections and data for each language. coleccion() gives the pages in the language of the page that asks for it, or in another with coleccion('blog', 'eu') or 'todos'. datos/menus.eu.yml is merged with datos/menus.yml on the pages in Basque, _datos.eu.yml goes on top of the _datos.yml of its folder, and what is not translated in a page can go in a .yml with its name, common to all its versions.

fecha() in the language of the page, with Spanish, Basque (“2025eko martxoaren 18a”) and English; also in single-language sites that are not in Spanish.

One sitemap with all the languages and one feed per language (/feed.xml, /eu/feed.xml).

The incremental build of ehundu servir knows which translations each page looks at and keeps giving the same as a full build (docs/compilacion.md (opens in a new tab)).

Changes for 0.2 sites: sitio.idioma is es if sitio.yml does not say otherwise, and the feed always carries xml:lang; a .yml inside contenido/ with the name of a page is no longer copied to salida/, because it holds its common fields; idioma becomes a reserved field; and two files for the same page in the same language (contacto.md and contacto.twig) stop the build.

This version on GitHub (opens in a new tab), with the ehundu.phar.

Ehundu 0.1.0

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

The first usable version of Ehundu: it builds Markdown and Twig sites, previews them with incremental builds and publishes them to a folder, over FTP, over SFTP or to S3-compatible storage.

This version on GitHub (opens in a new tab), with the ehundu.phar.