Bug #67130


Invalid loading order of packages with suggestions

Added by Xavier Perseguers almost 9 years ago. Updated about 6 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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:


    'constraints' => array(
        'depends' => array(
            'php' => '5.3.3-5.6.99',
            'typo3' => '6.2.0-7.99.99',
        'conflicts' => array(
        'suggests' => array(
            'realurl' => '',


  "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.


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

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #51069: Updating extension changes load orderClosedMarkus Klein2013-08-14

Actions #1

Updated by Andreas Allacher almost 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.

Actions #2

Updated by Riccardo De Contardi over 8 years ago

  • Category set to composer
Actions #3

Updated by Helmut Hummel about 6 years ago

  • Status changed from New to Resolved

Fixed since TYPO3 7.6

Actions #4

Updated by Helmut Hummel about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF