Bug #30749

EM always retrieves the latest version of an extension

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

Could have
Extension Manager
Target version:
Start date:
Due date:
% Done:


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


Yes, this sounds odd but I just found a special use case where this should not be the case :-)

When you install ks_sitemgr, you have this in the dependencies:

    'constraints' => array(
        'depends' => array(
            'be_acl' => '1.3.0-1.3.99',
        'conflicts' => array(
            'be_acl' => '1.4.0',
        'suggests' => array(),

And EM will effectively download the latest version of be_acl (currently 1.4.3) instead of the very latest version of the 1.3 branch.

Related issues

Related to TYPO3 Core - Bug #30750: EM should not suggest upgrade when it leads to conflictClosed2011-10-10

Related to TYPO3 Core - Feature #43178: Updates: Changelog and chooseable updateClosed2012-11-20

Related to TYPO3 Core - Bug #50347: ExtensionManager: Overwriting existing extensions with older versions without warningClosed2013-07-23


Updated by Martin Holtz about 9 years ago

it is not as special, that you need the possiblity to explicit select the version. If you update to an new version but it breaks something, you should be able to just switch back to the last version.


Updated by Stefan Neufeind about 8 years ago


Francois Suter:

If you right-click on the table row in the new EM, you get a

contextual menu leading you to a screen where you can choose the version
you want to download (some screen as in old EM). And it works for me
(with TYPO3 4.6, not tested with 4.5).


Updated by Ernesto Baschny about 8 years ago

  • TYPO3 Version changed from 4.6 to 4.5

Xavier is probably talking about the dependency resolution of the EM, which chooses the "latest version" automatically despite that version not being marked as "compatible" in the compatibility list.

So choosing a lower version manually is not the reported problem (if I understood Xavier correctly).

As we have a "new EM" in 6.0 now, we should check whether this bug also affects that EM. If this is the case, we should prioritize in fixing this issue in 6.0 first. Fixing that also in the "old New EM" is most certainly more difficult to tackle (and more frustrating, as we will be dropping it as soon as the last 4.x reaches EOL), and I would only do that if someone really fixes it in an understandable way. :)


Updated by Stefan Neufeind over 7 years ago

So which EM do we talk about? Number 1 (in 4.5) worked fine afaik. Number 2 (optional in 4.5, then in 4.6/4.7) we won't imho fix anymore?

But I still see a problem with always retrieving the latest version in the way EM number 3 (6.0+) handles things.


Updated by Philipp Gampe over 7 years ago

We should fix this in 6.x+ only.

The code also needs to check whether a newer version is already installed. In this case it must not be overridden with an older version.


Updated by Ernesto Baschny over 7 years ago

  • Status changed from New to On Hold

Dependency resolving in extensions is a quite complex topic, as there might be unresolvable conflicts or conflicts which could be resolved in different manners. If you know Debian you might know how "aptitude" works with this.

Since we haven't enforced that yet, dependencies the authors of extensions usually write in their ext_emconf are rather "informative" than mandatory and I wouldn't want the EM to trust them blindly.

The only dependency that the Core could check now is the TYPO3 Version compatibility, as this is the one that we now somehow "enforce" to be correct when uploading to TER. And being this only one dependency that returns "true/false" this should be rather easy to work with (to decide which version of an extension to install for example, or until which version to "upgrade").

But since this is not the problem described in this issue, this deserves a separate issue (which I consider even more important).


Updated by Mathias Schreiber about 6 years ago

  • Status changed from On Hold to Closed
  • Is Regression set to No

Taken into account in #63909.
The issues are not linked on purpose, so the refactoring ticket does not get bloated with relations.

Also available in: Atom PDF