Bug #67130
closedInvalid loading order of packages with suggestions
0%
Description
When an extension is providing both a composer.json
and an ext_emconf.php
files, the suggestions are read from the composer file solely.
Problem, located within \TYPO3\CMS\Core\Package\PackageManager::getSuggestionArrayForPackage()
is that $this->packages
is an array containing only the extension key and not any possible combination of a vendor name and an extension key. This means that such definition:
ext_emconf.php¶
'constraints' => array( 'depends' => array( 'php' => '5.3.3-5.6.99', 'typo3' => '6.2.0-7.99.99', ), 'conflicts' => array( ), 'suggests' => array( 'realurl' => '', ), ),
composer.json¶
"require": { "php": ">= 5.3.3, <= 5.6.99", "typo3/cms-core": ">= 6.2.0, <= 7.99.99" }, "suggest": { "typo3-ter/realurl": "Allows total and indistinct blend of the reStructuredText documentation into the website" },
will take the suggestion as "typo3-ter/realurl" but this key does not exist in $this->package
and as such the suggestion is skipped.
Effect¶
This definition will have the effect, when coming from EXT:restdoc of wrongly ordering EXT:restdoc before EXT:realurl instead of after. This is fixed when you either remove the composer.json
or change the comparison in PackageManager (see below).
Vendor name "typo3-ter"¶
It is suggested on http://composer.typo3.org to use "typo3-ter" for extension coming from TER.
In a first attempt to fix this (see this patchset) it was suggested to change the check by simply "dropping" the vendor name when it is equal to "typo3-ter". This was not liked.
Actually extension authors start to ship a real composer.json
together with their extension and use their own vendor name so another idea would be to have a (second) array containing the standard "short" extension key and the vendor name + extension key, so that the check would then be done against that second array.
Why another array¶
- I fear that "polluting" the current array with duplicates would have side effects while reordering packages and writing the list to
typo3conf/PackageStates.php
so maybe modifying it at many places is not the best option. - The second array should naturally contain the official vendor key when an extension comes with a
composer.json
file, so that, e.g., a dependency to EXT:sphinx should be written as "causal/sphinx" and not "typo3-ter/sphinx". - Question is whether to support "typo3-ter" (somehow hardcoded in Core) or not
Updated by Andreas Allacher over 9 years ago
Regarding composer key that is not only suggestions but also dependencies.
And it is not really "loading" order but an issue with what key to use (and how to handle that key in PackageManager) in composer.json, so the title is a bit misleading.
The main issue is that extensions don't all have a composer.json and therefore not a "valid" composer name.
Because of "replace" with the extension key it would be possible to just use the extension key in suggest/depends but that certainly is not "nice"
If an extension has composer.json than the whole name would have to be used - especially in combination with the linked patchset.
Which might be a bit problematic on updates.
Maybe we should just ignore the vendor name completely for all of type typo3-cms-extension and adjust the name afterwards (- to _) ?
As typo3 extensions basically only have a "key" (cannot have two extensions with the same key but different vendor name anyway as installed to same directory) this should be enough to identify any TYPO3 extension.
That way if an extension has a link to e.g. "typo3-ter/realurl" and later realurl adds a composer.json with e.g. "dmitryd/realurl" it would still work.
Updated by Helmut Hummel over 6 years ago
- Status changed from Resolved to Closed