TYPO3 Core

Could you please share your own 'site' extension's ext_emconf.php & composer.json file?

Also I wonder why the error mentions a flux package download, and how that is related to a 'site' extension at this point of the exception.

(Caveat: I use composer mode myself and haven't used the extension manager for a longer time, but I wonder why remote and local packages should be mixed up. But I'd want to try reproducing this)

Garvin Hicking wrote in #note-1:

Could you please share your own 'site' extension's ext_emconf.php & composer.json file?

Also I wonder why the error mentions a flux package download, and how that is related to a 'site' extension at this point of the exception.

(Caveat: I use composer mode myself and haven't used the extension manager for a longer time, but I wonder why remote and local packages should be mixed up. But I'd want to try reproducing this)

Hi,

sure, here is the composer.json:

{
  "name": "various/typo3-site",
  "type": "typo3-cms-extension",
  "title": "[Site] Various",
  "description": "TYPO3 Site Package",
  "autoload": {
    "psr-4": {
      "Various\\Site\\": "Classes/" 
    }
  },
  "extra": {
    "typo3/cms": {
      "extension-key": "site" 
    }
  }
}

and

ext_emconf.php

<?php

$EM_CONF[$_EXTKEY] = ['state' => 'stable'];

I think the issue is, we have in our project a dependency to flux 10 (but not in site package) and https://extensions.typo3.org/extension/site has a requirement in https://github.com/FluidTYPO3/site/blob/development/ext_emconf.php to TYPO3 7-8 and also flux (which i guess is only compatible in version 7.1 to typo3 7-8). I think it (or it is sure) it uses the wrong "site" extension to build dependency list.

Best regards,
Harald

Thanks Garvin - i hope you do not missunterstood the intention of this ticket - i have already solved it for myself (and yes it is a already a composer-based installation). I just thought it is useful to open a ticket to open an issue, because it may should be resolved in Extensions Manager - to prefer installed (via composer - check composer.install) package over not installed (or online extensions in the tx_extensionmanager_domain_model_extension table) listed packages.

So i solved it, if you do not think it is an issue of the extension manager and should not changed/resolved, please feel free to close the ticket.

Best regards,
Harald

Thanks for clarifying. Indeed I believed you were looking for a "proper" fix, because that row in the database will likely occur again, everytime the TER is synchronized.

So I believe there are two ways to approach this:

1. Not change anything in the Extension Manager code, but state that extension authors needs to provide unique keys as intended. Possibly overrides could be used.

2. Try to change the Extension Manager code and regard "local" extensions differently. While thinking about this - in the extension manager, it will not be able to differentiate if "site" is YOUR extension or if indeed it is the "site" extension of TER. Because both use the same key. How would you make the extension manager recognize a local extension then? It uses a key that is used on TER, you might just have uploaded it differently.

So the more I think about this, I believe you need to really ensure that you use a unique extension key for non-composer installations. But it's good to have this issue here for others to find.

(Sorry for me needing to take a few steps for recognizing this, I'm just learning to work with the Extension Manager after a long time of Composer-only ;))

What do you think?

All good - I just use the extension manager in composer installation to get a quick overview of installed extensions and versions.

I agree that we could let it as it is, the problem in this situation was that we made an update from a non-composer install to a composer-install - this was the reason extensions from the ter was in the table. Maybe a way would to ignore the ter in composer based installations (but i do not really know, if there is a necessity for it).

So i think we can let it as it is for now!

Thanks for your quick reply and help!

Best regards,
Harald

Did you by chance try out to modify your own 'site' package composer.json with that replace syntax?

I agree that in composer mode the extension manager should only regard the local extensions and not try to parse TER ones. Can't currently think of a reason where the TER data should matter in that case.

Yes it works, when changing my ext-key.

Thanks,
Harald

I meant if you do that "replace" syntax in composer.json, so that you replace the ter key but your actual extension key stays same.