Bug #101590
closedComposer package vendors for TYPO3 extensions ending with "ext" don't get symlinked into public/_assets
100%
Description
this has been reported at stackoverflow at https://stackoverflow.com/questions/76829256/composer-package-vendors-for-typo3-extensions-ending-with-ext-dont-get-symlin
When the composer package vendor of a TYPO3 extension ends with "ext", the "Resources/Public" directory of the extension does not get symlinked into public/_assets.
Example: typo3_ext/my_extension
This is because of this line:
vendor/typo3/cms-core/Classes/Composer/PackageArtifactBuilder.php:264
if (str_contains($path, 'ext/' . $extensionKey) || !file_exists($fileSystemResourcesPath)) { continue; }
When it is changed to this, it works for me:
if (str_contains($path, '/ext/' . $extensionKey) || !file_exists($fileSystemResourcesPath)) { continue; }
Since $path
contains the full path, I guess that change should be OK?
TYPO3 12.4.4
Updated by Garvin Hicking about 1 year ago
Looks good to me, I'd +1 this patch - or I can offer to create one based on this issue? ;-)
Extensions could be called "SuperText" or something like that, many things could end in "text", "next" - or even people shorting their names to "mycoolext".
Updated by Stefan Bürk about 1 year ago
only from reading the issue, I'm not happy with the suggested sulution at all.
Without debugging and just opend the `PackageArtifactBuilder` I guess following
would be amore proper check for the if condition:
// skip non-composer installation extension paths and if resource paths does not exists.
if (str_ends_with($path, '/typo3conf/ext/' . $extensionKey) || !file_exists($fileSystemResourcesPath)) {
continue;
}
This check is to rule `legacy` installation extension paths out. As $fileSystemResourcePath is directly
defined before the if as
$fileSystemResourcesPath = $path . '/Resources/Public';
and therefore the end with should be safe.
Updated by Garvin Hicking about 1 year ago
Good catch, and yes, I believe being restrictive on the legacy syntax like this should work out.
I did a small check on the packagist repository, currently these public extensions would be affected by the bug:
aoe/t3deploy-ext beewilly/form-element-linked-text bitpatroon/bpn-variable-text clickstorm/go-maps-ext cron/eu-cron-context kitzberger/form-mailtext localizationteam/localizer-supertext nreach/nreach-t3-text teufels/form-element-linked-text
I don't want to hijack things, shall I create a patch based on this?
Updated by Gerrit Code Review 12 months ago
- Status changed from Accepted 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/+/81716
Updated by Garvin Hicking 12 months ago
I initially misunderstood the issue, I thought the extension name would be the culprit, while in fact it is the vendor name (like described).
So a vendor like "next" or "Agencytext" would trigger this.
I implemented Stefans suggestion in a patch, and we could also re-use the existing constant here.
Updated by Gerrit Code Review 12 months ago
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81782
Updated by Garvin Hicking 12 months ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset e0daf995add883df137ce70e95d245162360d27e.