`validate --fix` no longer repairs missing leading slashes in src after 13.9.x fix for #778

[MacGyer]

Bug description

The fix introduced in 13.9.x for #778 over-corrects: srcMatchesPublicUrl() now treats fileadmin/x and /fileadmin/x as equivalent, which prevents validate --fix from detecting and repairing paths that are missing their leading slash.

Prior to 13.9.x, upgrade:run would incorrectly strip the leading slash from RTE image src attributes (e.g. /fileadmin/image.jpg → fileadmin/image.jpg). The rte_ckeditor_image:validate --fix command was the intended repair tool. With 13.9.x this repair no longer works.

The root cause is in:

t3x-rte_ckeditor_image/Classes/Service/RteImageReferenceValidator.php

Lines 392 to 399 in 394582c

	private function srcMatchesPublicUrl(string $src, string $publicUrl): bool
	{
	if ($src === $publicUrl) {
	return true;
	}
	return '/' . ltrim($src, '/') === $publicUrl;
	}

Because $publicUrl is already normalised to always carry a leading slash (via normalizePublicUrl()), the second condition makes fileadmin/x pass as equivalent to /fileadmin/x. Paths broken by older versions of the wizard are no longer detected as mismatches and validate --fix silently does nothing. The updateNecessary() check in ValidateRteImageReferencesWizard returns false for the same reason.

Steps to reproduce

1. Have one or more tt_content records whose bodytext contains RTE images with src="fileadmin/..." (no leading slash) — e.g. as produced by running upgrade:run with a version prior to 13.9.x.
2. Upgrade the extension to 13.9.x.
3. Run bin/typo3 rte_ckeditor_image:validate --fix --table=tt_content.
4. Observe that the command reports no issues and exits successfully without modifying any records.
5. Confirm the broken src attributes are still missing their leading slash in the database.

Expected behavior

validate --fix should detect src="fileadmin/image.jpg" as a SrcMismatch and repair it to src="/fileadmin/image.jpg".

The fix for srcMatchesPublicUrl() is straightforward: since normalizePublicUrl() already guarantees that $publicUrl always has a leading slash, a strict equality check is sufficient and correct:

private function srcMatchesPublicUrl(string $src, string $publicUrl): bool
{
    return $src === $publicUrl;
}

This correctly flags fileadmin/x as a mismatch against /fileadmin/x, while correctly accepting /fileadmin/x as matching /fileadmin/x — which is exactly what the original #778 fix intended.

Screenshots or logs

No additional logs. The command exits without output or errors — the issue is the absence of any detected mismatch, not an exception.

Environment

• TYPO3 version: 13.4.x
• PHP version: 8.3
• Extension version: 13.9.1

Documentation

Have you checked the readme/documentation?

• Yes, but I couldn't find anything helpful

[github-actions]

Thanks for opening your first issue! We appreciate you taking the time to report this.
A maintainer will review your issue soon.