Thanks for your contribution @dhuf !

Could you please edit your OP to give more context? I'm afraid your short intro doesn't say enough.

• Please edit to use the PR template. It's there for a reason.
• Please describe the problem clearly, including how to demonstrate it in existing DDEV and a TYPO3 project, probably using the TYPO3 quickstart
• Please give clear testing instructions with a demonstration TYPO3 project

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-linux-arm64.zip
• ddev-linux-amd64.zip
• ddev-windows-amd64.zip
• ddev-windows-amd64-installer.zip
• ddev-windows-arm64.zip
• ddev-windows-arm64-installer.zip

See Testing a PR.

@rfay hope that helps, the config is already there for all other filetypes. The svg is only missing

You're making progress, thanks.

You have a ways to go. Remember we aren't even familiar with the TYPO3 upgrade page or what might happen there. So you say

This can easily be seen on the TYPO3 Upgrade page

But you don't say how to see it. Maybe a screenshot of before and after?

In your testing instructions you say "It can easily be tested" but you don't say how to test or how to verify that the fix works.

If it's easier for you, just record a tiny screencast showing the problem and the fix, thanks.

Hi @rfay, sorry, I was on Holiday, I'll try to do it as soon as possible. Thanks so much

Detailed Manual Testing Strategy

Test Environment Setup

mkdir test-typo3-svg && cd test-typo3-svg
ddev config --project-type=typo3 --php-version=8.2
ddev start
ddev composer create "typo3/cms-base-distribution:^13"

Enable versionNumberInFilename

Create config/system/additional.php:

<?php
$GLOBALS['TYPO3_CONF_VARS']['BE']['versionNumberInFilename'] = 1;

Test Case: SVG File Timestamp Rewriting

1. Create test SVG file:

   ddev exec 'echo "<svg width=\"20\" height=\"20\"><circle cx=\"10\" cy=\"10\" r=\"5\" fill=\"red\"/></svg>" > public/_assets/test-icon.svg'

2. Test original file access:

   ddev exec curl -I localhost/_assets/test-icon.svg

   Expected: HTTP 200 OK

3. Test timestamped URL (demonstrates the bug without fix):

   ddev exec curl -I localhost/_assets/test-icon.3939393.svg

   Without fix: HTTP 404 Not Found
   With fix: HTTP 200 OK

Actual Test Results

Before applying the fix:

• Original URL: ✅ 200 OK
• Timestamped URL: ❌ 404 Not Found (demonstrates the bug)

After applying the nginx config change (adding svg to rewrite rule):

$ ddev exec curl -I localhost/_assets/test-icon.svg
HTTP/1.1 200 OK
Server: nginx
Content-Type: image/svg+xml
Content-Length: 77
ETag: "6893d398-4d"

$ ddev exec curl -I localhost/_assets/test-icon.3939393.svg  
HTTP/1.1 200 OK
Server: nginx
Content-Type: image/svg+xml
Content-Length: 77
ETag: "6893d398-4d"

Verification

• Both URLs return HTTP 200 OK ✅
• Identical ETag values (6893d398-4d) confirm same file served ✅
• Nginx correctly rewrites timestamped SVG URLs to original files ✅

Real-World Impact

This fix ensures TYPO3's versionNumberInFilename feature works correctly for SVG assets. When enabled, TYPO3 adds timestamps to asset URLs for cache busting (e.g., icon.1234567890.svg). Without this fix, such URLs return 404 errors, breaking SVG icons and graphics in TYPO3 sites using this caching strategy.

Code Change Validation

The modification is minimal and safe - only adds svg to the existing file extension pattern in the nginx rewrite rule:

- rewrite ^/(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ /$1.$3 last;
+ rewrite ^/(.+)\.(\d+)\.(php|js|css|png|jpg|gif|svg|gzip)$ /$1.$3 last;

LGTM 👍 This fix resolves a real issue with SVG asset handling in TYPO3 projects using timestamp-based cache busting.

Hi @rfay, thank you so much for the comments and reviewing.

Yes, that is probably also needed for Apache. Where is the configuration for TYPO3 in DDEV located ?
Could it be, that it takes the default .htaccess from TYPO3 ?

https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Typo3ConfVars/FE.html#confval-typo3-conf-vars-fe-versionnumberinfilename

This feature requires extra .htaccess rules to work (please refer to the EXT:install/Resources/Private/FolderStructureTemplateFiles/root-htaccess (GitHub) file shipped with TYPO3).

After copying that file to public/.htaccess, the feature started working with Apache.

We can copy or download the file, but maintaining it isn't ideal, especially with several active TYPO3 major versions. Pulling the latest version isn't reliable either, though pulling a tagged version is possible.

I don't think DDEV should manage this when using Apache, especially since it's an optional feature and clearly documented.

The nginx update makes sense, though.