Bug #101911
openTYPO3 composer mode does not properly respect installations in a subdirectory
0%
Description
This is a grouping ticket.
Several bugs can occur because TYPO3v12 introduced asset-collecting and at some places does not properly reference the directory, where those assets are retrieved, when in composer-mode.
This can lead to doubling parts of the actual path.
Example:
Composer project path: /var/www/html/typo3_v12/ TYPO3 public root: /var/www/html/typo3_v12/public/ DocumentRoot: /var/www/html TYPO3 Backend URI: https://example.com/typo3_v12/public/typo3/index.php
When assets are retrieved, the workflows may use combinations Environment::getPublicPath
and Environment::getAbsoluteWebPath
to i.e. first resolve a EXT:bootstrap_packages/Resources/Public/Css/bootstrap5-rte.min.css
file, and then later AGAIN prepend paths.
This would resolve the above to:
/var/www/html/typo3_v12/public/ -> /var/www/html/typo3_v12/public/typo3_v12/public/_assets/9b80d86a98af3ecc38aabe297d2c3695/Css/bootstrap5-rte.min.css
I am trying to set-up an installation to easily reproduce this.
External references:
Updated by Garvin Hicking 10 months ago
- Related to Bug #100661: Wrong resource links to symlinked _assets unsing base with appending path segment added
Updated by Garvin Hicking 10 months ago
- Related to Bug #100660: Wrong resources links when using env variable path_root added
Updated by Gerrit Code Review 10 months ago
- Status changed from New to Under Review
Patch set 1 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
Updated by Gerrit Code Review 10 months ago
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
Updated by Gerrit Code Review 10 months ago
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
Updated by Garvin Hicking 10 months ago
- Related to Task #96887: Allow only Resources/Public in PathUtility->getPublicResourceWebPath added
Updated by Garvin Hicking 10 months ago
- Related to Bug #101701: PathUtility::getAbsoluteWebPath() create wrong asset path in composer with TYPO3 12 added
Updated by Garvin Hicking 10 months ago
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
Updated by Garvin Hicking 4 months ago
- Related to Bug #103157: Image referenced by `EXT:` does not work in TYPO3 subfolder installation added
Updated by Benni Mack about 2 months ago
- Target version changed from 13.1 to 13.2
Updated by Markus Klein about 2 months ago
· Edited
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.
Updated by Markus Klein about 2 months ago
Same test with v12: works without issues.
Updated by Ayke Halder about 2 months ago
· Edited
@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.
Updated by Markus Klein about 2 months ago
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)
Updated by Markus Klein about 2 months ago
We are talking different setups:
- Mine is to have the full TYPO3 installation within the docroot.
- 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)
Updated by Markus Klein about 2 months ago
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.
Updated by Garvin Hicking about 2 months ago
- Related to deleted (Bug #101701: PathUtility::getAbsoluteWebPath() create wrong asset path in composer with TYPO3 12)
Updated by Ayke Halder about 2 months ago
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
Updated by Markus Klein about 2 months ago
@Ayke Halder Thanks for the pointer. Your conclusion there seems to match what I found here.
Updated by Garvin Hicking about 2 months ago
Link to a slack discussion about this: https://typo3.slack.com/archives/C028J3N83/p1715095754488409