Project

General

Profile

Actions

Bug #101911

open

TYPO3 composer mode does not properly respect installations in a subdirectory

Added by Garvin Hicking 8 months ago. Updated 15 days ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
composer
Target version:
Start date:
2023-09-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
13
PHP Version:
8.2
Tags:
Complexity:
medium
Is Regression:
Yes
Sprint Focus:

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:

Related issues 4 (3 open1 closed)

Related to TYPO3 Core - Bug #100661: Wrong resource links to symlinked _assets unsing base with appending path segmentClosed2023-04-19

Actions
Related to TYPO3 Core - Bug #100660: Wrong resources links when using env variable path_rootNew2023-04-19

Actions
Related to TYPO3 Core - Task #96887: Allow only Resources/Public in PathUtility->getPublicResourceWebPathUnder Review2022-02-14

Actions
Related to TYPO3 Core - Bug #103157: Image referenced by `EXT:` does not work in TYPO3 subfolder installationUnder Review2024-02-20

Actions
Actions #1

Updated by Garvin Hicking 8 months ago

  • Related to Bug #100661: Wrong resource links to symlinked _assets unsing base with appending path segment added
Actions #2

Updated by Garvin Hicking 8 months ago

  • Related to Bug #100660: Wrong resources links when using env variable path_root added
Actions #3

Updated by Gerrit Code Review 8 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

Actions #4

Updated by Gerrit Code Review 8 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

Actions #5

Updated by Gerrit Code Review 8 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

Actions #6

Updated by Garvin Hicking 8 months ago

  • Related to Task #96887: Allow only Resources/Public in PathUtility->getPublicResourceWebPath added
Actions #7

Updated by Garvin Hicking 8 months ago

  • Related to Bug #101701: PathUtility::getAbsoluteWebPath() create wrong asset path in composer with TYPO3 12 added
Actions #8

Updated by Garvin Hicking 8 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

Actions #9

Updated by Benni Mack 4 months ago

  • Target version changed from 13.0 to 13.1
Actions #10

Updated by Garvin Hicking 2 months ago

  • Related to Bug #103157: Image referenced by `EXT:` does not work in TYPO3 subfolder installation added
Actions #11

Updated by Benni Mack 21 days ago

  • Target version changed from 13.1 to 13.2
Actions #12

Updated by Markus Klein 15 days 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.

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

Actions #13

Updated by Markus Klein 15 days ago

Same test with v12: works without issues.

Actions #14

Updated by Ayke Halder 15 days 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.

Actions #15

Updated by Markus Klein 15 days 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)

Actions #16

Updated by Markus Klein 15 days ago

@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)

Actions #17

Updated by Markus Klein 15 days 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.

Actions #18

Updated by Garvin Hicking 15 days ago

  • Related to deleted (Bug #101701: PathUtility::getAbsoluteWebPath() create wrong asset path in composer with TYPO3 12)
Actions #19

Updated by Ayke Halder 15 days 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

Actions #20

Updated by Markus Klein 15 days ago

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

Actions #21

Updated by Garvin Hicking 15 days ago

Actions

Also available in: Atom PDF