TYPO3 Core

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81014

Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81014

While not completely related, the following issues also stem from problematic file path resolving:

https://forge.typo3.org/issues/98545
https://forge.typo3.org/issues/100021
https://forge.typo3.org/issues/101350
https://forge.typo3.org/issues/101921

I just did a test-setup with ddev and v11 and composer-installers v4@RC

Folders:

• .ddev
• t3
  • config
  • public
  • composer.json

ddev config.yaml:

docroot: .
composer_root: t3

(no special config in composer.json)

Site config:

base: 'https://example.ddev.site/t3/public/'

First Install and accessing the BE works just fine.

BE url: https://example.ddev.site/t3/public/typo3/

Same test with v12: works without issues.

@Markus Klein Thank you for looking into this.

In your test cases the public web-root is actually https://DOMAIN/ and not https://DOMAIN/t3/public
So .ddev, t3, t3/composer.json and t3/vendor etc. are all in the public web-root. This is not desired for a productive and security-conscious install:

https://example.ddev.site/t3/public/

• upper-directory <-- this is the public web-root
  • .ddev
  • t3
    • config
    • public <-- here is the TYPO3 FE entry point
    • vendor
    • composer.json

Instead we try to get the following structure running:

https://example.ddev.site/t3/

• upper-directory
  • .ddev
  • config
  • public <-- this is the public web-root
    • t3 <-- here is the TYPO3 FE entry point
  • vendor
  • composer.json

With older TYPO3 versions there were different options to make this work:

• some combinations of symlinks

• composer.json

{
  "extra": {
    "typo3/cms": {
      "web-dir": "public/t3" 
    }
}

• maybe even other options

About DDEV composer_root

.ddev/config.yaml:

composer_root: t3

See https://ddev.readthedocs.io/en/stable/users/usage/developer-tools/#ddev-and-composer

This just tells DDEV where to find/create the composer.json file. It does not influence the install itself in any other way.

I can reproduce the issue with v12 in FE.

The LocalDriver is called with the public URL for a file instead of the correct path.

Testcase:

some.cObject = IMG_RESOURCE
some.cObject.file = EXT:foo/Resources/Public/Images/image.jpg

will finally call \TYPO3\CMS\Core\Resource\ResourceFactory::retrieveFileOrFolderObject with argument 'EXT:foo/Resources/Public/Images/image.jpg'
which will internally call GeneralUtility::getFileAbsFileName(...) which generates:
/var/www/html/t3/vendor/reelworx/foo/Resources/Public/Images/image.jpg

which is wrong! (mind the t3/ in the path)

@Ayke Halder

We are talking different setups:

1. Mine is to have the full TYPO3 installation within the docroot.
2. Your's is to have the public folder only in a subdirectory.

We are investigating 1) here.

For 2) you should only need to change the composer web-dir. (related https://github.com/TYPO3/CmsComposerInstallers/pull/146#issuecomment-2055970691)

It seems the issue boils down to \TYPO3\CMS\Core\Resource\Driver\LocalDriver::getAbsolutePath

which is called in the testcase with: '/t3/public/_assets/777de778c19d749686b8a2330fffe037/Images/image.jpg'

there the storage's basePath (storageUid=0,basePath=/var/www/html/t3/public/) is prepended.

That's why we end up with /var/www/html/t3/public/t3/public/_assets/777de778c19d749686b8a2330fffe037/Images/image.jpg

So the conceptual issue seem to be that any EXT:* reference is resolved to the path relative to the docroot, whereas FAL expects paths for the fallback storage (uid=0) to be relative to the public directory.

About this \TYPO3\CMS\Core\Resource\ResourceFactory::retrieveFileOrFolderObject with argument 'EXT:foo/Resources/Public/Images/image.jpg'

Please have a look if this issue is also fixed by https://review.typo3.org/c/Packages/TYPO3.CMS/+/83043

@Ayke Halder Thanks for the pointer. Your conclusion there seems to match what I found here.

Link to a slack discussion about this: https://typo3.slack.com/archives/C028J3N83/p1715095754488409