[BUGFIX] Read project version from the DOM so "0.10" is not coerced to 0.1

[CybotTM]

Problem

A guides.xml with <project version="0.10"> is rendered with the version 0.1 (title, objects.inv, every |version| substitution). Any round / trailing-zero two-part version is mangled:

guides.xml	parsed as
0.10	0.1
1.0	1
1.10	1.1
13.0	13
0.9, 13.4, 1.2.3, main	unchanged

It surfaced on docs.typo3.org for netresearch/nr-vault and netresearch/nr-llm, whose 0.10 / 0.12 releases were published under 0.1.

Cause

XmlFileLoader parses guides.xml with XmlUtils::convertDomElementToArray(), which runs phpize() on every attribute value. phpize("0.10") returns the float 0.1 (it is is_numeric), which then stringifies to "0.1".

There was already a workaround — an escaped version syntax (version="'3.0'", single-quoted to dodge phpize) plus a beforeNormalization that stripped the quotes again. But that runs after phpize has already discarded the digit (0.10→0.1), so it can never recover it.

Fix

Read the <project> attributes (all strings) directly from the DOM, and detach the element before convertDomElementToArray() so phpize never touches them. The version is read correctly at the source, instead of being coerced and patched up afterwards. The <guides> attributes that genuinely want coercion (links-are-relative, max-menu-depth, …) are unaffected.

Because the root cause is fixed, the beforeNormalization workaround in the Symfony config is removed — escaping is no longer needed to write a correct version.

Backward compatibility

Projects that adopted the escaped version workaround for this very bug may still have <project version="'3.0'"> in their guides.xml. To keep those rendering 3.0 (and not the literal '3.0'), the surrounding single quotes are still stripped for version and release — the same trim($value, "'") the removed beforeNormalization did, now applied in XmlFileLoader when the attributes are read. New files don't need it: write the version directly, version="0.10" / version="3.0".

Before / after

<project version="0.10"> as loaded by XmlFileLoader:

Before

After

Tests

Two integration fixtures under tests/Integration/tests/meta/:

• version-from-guides-xml — unescaped version="0.10" (with release="3.0.0" as a non-coerced control); asserts the rendered |version| stays 0.10. Passes with the fix and fails without it (without it: version 0.1).
• version-from-guides-xml-quoted — the legacy quoted form version="'3.0'" / release="'3.0.0'"; asserts it still renders 3.0 / 3.0.0, covering the backward-compatibility path above.

Integration suite passes locally (228 tests). CI is green across PHP 8.1–8.3 (highest / locked / lowest): unit, integration, functional, Coding Standards, PHPStan and architecture checks.

Update: two defects in the first commit

A review of this branch found two problems with reading <project> from the DOM, both reproduced before fixing and both addressed in the second commit.

Detaching <project> can leave an empty root element behind, and XmlUtils::convertDomElementToArray() returns null rather than an empty array for one. assert(is_array($rootConfig)) then fails for any guides.xml that holds nothing but a project — which both fixtures above are. It stays invisible under the default and the CI php.ini, both of which run with zend.assertions=-1, where the following write to $rootConfig['project'] auto-vivifies null; with -d zend.assertions=1 four integration data sets fail. The assertion is now an is_array() check.

getElementsByTagName('project') searches the whole subtree, and the schema lets an <extension> carry arbitrary child elements (xsd:any processContents="lax"). A nested <project> was therefore read as the project configuration and removed from that extension, while the real one at root level was dropped. Only direct children are considered now.

The new version-from-guides-xml-nested-project fixture covers the second defect and fails against the previous state of this branch. The first is only observable with assertions enabled, where the two existing fixtures already cover it — worth knowing that CI does not gate it.

Assisted by claude-code:claude-opus-5 — Session

[garvinhicking]

Thanks - I can't really judge the impact of this and hope @jaapio can give some feedback. I remember having stabbed at this and not being able to resolve this.