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

[CybotTM]

Problem

A <project version="0.10"> in guides.xml renders as version 0.1, and version="1.0" as 1. The digit is lost before anything downstream can object.

Cause

XmlUtils::convertDomElementToArray() runs phpize() on every attribute value. That is right for the <guides> attributes that want coercion — links-are-relative, max-menu-depth — and wrong for <project>, whose four attributes are all strings.

There was a workaround: write version="'3.0'" and let a beforeNormalization callback strip the quotes again. It runs after phpize has already discarded the digit, so it can restore a quoted 3.0 but never an unquoted 0.10.

Fix

Read the <project> attributes straight from the DOM and detach the element before the conversion, so phpize never sees them. The version is correct at the source instead of being coerced and patched up afterwards.

Two consequences that are easy to miss:

• The element is looked up among the direct children. The schema lets an <extension> carry arbitrary children, and a subtree search would take a <project> nested in one for the project configuration and remove it from that extension.
• Detaching <project> can leave a root with no children, for which convertDomElementToArray() returns null rather than an empty array. That is handled rather than asserted, so the outcome does not depend on zend.assertions.

The config tree keeps the other half of the removed callback. It preserved the literal of a non-string value, and that half serves every caller, not the XML one: ContainerFactory::loadExtensionConfig() feeds a raw PHP array straight in, where a native float reaches a bare (string) cast and (string) 3.0 is "3" — the same lost zero, reached without any XML. null now passes through instead of becoming the literal string "NULL".

Scope, stated rather than implied: title and copyright take the same cast on the same path and are not guarded, matching what the callback covered. Only version and release carry the "always a string" contract and a real-world float shape. The other two writers of a version — ComposerSettingsLoader and VersionFieldListItemRule — already guard with is_string.

Backward compatibility

Projects that adopted the quoted workaround may still have <project version="'3.0'">. To keep those rendering 3.0 and not the literal '3.0', the single quotes are still stripped — now in XmlFileLoader, where the quotes come from, and for version and release only. New files need nothing: write version="0.10".

Before / after

Before	After

Tests

Three integration fixtures, guarding different things. version-from-guides-xml uses the unquoted 0.10 it could not express before, and version-from-guides-xml-nested-project pins the direct-child lookup; both fail against main. version-from-guides-xml-quoted cannot fail against main — the quoted form worked there, which is its whole point. It guards the other direction and fails as soon as the quote stripping is dropped.

XmlFileLoaderTest is new: guides-cli's unit suite covered Command and Logger only, so the loader was reachable exclusively through fixtures that render a whole site. Eight cases, each seen failing on a defect built for it — DOM reading removed, trim widened to every attribute, trim dropped, the direct-child search degraded to a subtree search, the project key withheld when empty, and the project key set unconditionally.

The case with no coverage anywhere: the quote stripping is backward compatibility for two attributes, not a general unquoting rule — a title that really is quoted keeps its quotes.

GuidesExtensionTest gains the programmatic-path cases; the float one fails without the fix with '3' against '3.0', the null one with 'NULL' against ''.

One baseline entry had to go

Adding a unit test for the loader turned the (8.4, lowest) cell red on an error that is not an assertion:

PHPUnit\Runner\Baseline\FileDoesNotHaveLineException:
File "vendor/symfony/config/Loader/FileLoader.php" does not have line 0

Declaring a subclass of that vendor class makes PHP 8.4 raise the implicit-nullable deprecations of the inherited signatures while linking. Those are attributed to the parent file with no line, so PHPUnit reports the issue at line 0; the baseline looks the file up, tries to read line 0 to hash it, and throws. A baseline entry pins a line number in third-party code, and for this shape of issue no line number can match.

Reproduced in a php:8.4-cli container after composer update --prefer-lowest, then narrowed by removing one baseline block at a time. Moving the test to another suite does not help — verified with the same test under functional. The deprecations the entry covered are now displayed, and failOnDeprecation="false" keeps them from failing anything. The other 39 vendor files in the baseline carry the same fragility and are worth a separate look.

Verified

Four commits, each green on its own (831 → 834 → 834 → 842 tests). On the locked set: PHPUnit 842, PHPStan level max, PHPCS and deptrac clean, and all 100 guides.xml in the tree validate against the schema. In a php:8.4-cli container with --prefer-lowest: unit 495, functional 117, integration 230.

Context

• Reported downstream at Version numbers like 0.10 are mangled to 0.1 (guides.xml attribute float coercion) TYPO3-Documentation/render-guides#1293

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.

[linawolf]

This PR fixes trailing-zero loss (3.0 -> "3") by moving version/release handling out of XML normalization into XmlFileLoader, but the beforeNormalization callback removed here wasn't XML-specific -- it also caught non-string scalars reaching this config tree from anywhere else.

ContainerFactory::loadExtensionConfig() feeds a raw PHP array straight into this same tree, bypassing XmlFileLoader entirely. Before this PR, beforeNormalization's !is_int && !is_string branch caught that case; after, nothing does, so ['project' => ['version' => 3.0]] -- a native PHP float -- hits a bare (string) cast downstream and loses its trailing zero again ((string) 3.0 -> "3"), just via the programmatic path instead of XML.

GuidesExtensionTest.php already has the right harness for this (it calls $extension->load($configs, $container) with raw arrays) -- just missing a case for it:

yield 'project version as float' => [
    [['project' => ['version' => 3.0]]],
    static function (ContainerBuilder $container): void {
        self::assertSame('3.0', $container->getParameter('phpdoc.guides.project.version'));
    },
];

[CybotTM]

After some back-and-forth, I haven't managed to significantly reduce the scope of this PR. I’ve tried to structure the PR logically based on the commits, hopefully, that makes the review easier.

[jaapio]

Small note, I noticed that the referenced issue is pointing to something different. Which makes it harder to see if this was an issue. Given the fact code changes are made I assume there was an issue. But I could not find it. If you have the correct issue I can read up from the beginning.

I will continue to review your changes step by step.

[CybotTM]

Hi @jaapio ,

thanks for taking care of.

Small note, I noticed that the referenced issue is pointing to something different.

my fault, I mixed something while working on different issues.

Correct: TYPO3-Documentation/render-guides#1293

you can see the issue here for example: https://docs.typo3.org/p/netresearch/nr-llm/0.10/en-us/