Bug #105139: Extension Manager - Dependency Check - TYPO3 Core - TYPO3 Forge

Custom queries

Accessibility
Easy tasks
Forge Triage
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
My open issues
No feedback within 90 days
Open Bugs
Open issues of 10
Recently modified
Regressions
Stabilization Issues
Usability or UX

Watchers (1)

Garvin Hicking

Actions

Copy link

Bug #105139

open

Extension Manager - Dependency Check

Added by Harald Holzmann 23 days ago. Updated 19 days ago.

Status:

Needs Feedback

Priority:

Should have

Assignee:

Category:

Extension Manager

Target version:

Start date:

2024-09-27

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

8.3

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Hello,

i always got the following error, when try to open the "Extensions" Module in the backend:

Problem is that we have a local Package called "site", but without any dependencies. The full package was installable (composer setup) and everything works perfekt without conflicts (no composer conflicts), only it was not possible to open the "Extensions"-Module.

Issue is/was that in the tx_extensionmanager_domain_model_extension was an entry for this extension: https://extensions.typo3.org/extension/site

Solution was to remove this entry in the table and everything works again.

I know site-keys should be unique, but such a general extension-key i think is used in lot of installation for a custom site-Package.

I would recommend: If there are duplicate extension keys, the installed one should used.

Maybe do not let reserve sould general extension-keys like "site".

Files

clipboard-202409270913-sp8dx.png (70.4 KB) clipboard-202409270913-sp8dx.png

Harald Holzmann, 2024-09-27 07:13

History
Notes
Property changes

Actions

Copy link

Updated by Garvin Hicking 23 days ago

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)

Actions

Copy link

Updated by Harald Holzmann 23 days ago

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

Actions

Copy link

Updated by Garvin Hicking 23 days ago · Edited

Status changed from New to Needs Feedback

I see, thanks! In your composer.json with this:

"extra": {
    "typo3/cms": {
      "extension-key": "site" 
    }
  }

you actually mix+match with the officially registered extension key. I would suggest you to replace the 'site' key with 'mycompany-site' or something like that. Since 'site' is already registered, that will likely not change. And we cannot implement exemptions for specific names in the Extension Manager.

So a way forward would only be to make the EM ensure that a locally named package of the same name is preferred over a remote one.

I have two ideas about this.

I haven't tried that myself, but did you try to place this in composer.json:

  "replace": {
    "ter/site": "self.version",
    "fluidtypo3/site": "self.version" 
  },

maybe that could help to attribute the 'site' key to your extension instead of the 'TER' one?

The other way which you may not like to hear, would be to actually use a composer-based installation. There, due to the vendor prefix, a problem like this would be easily prevented, because you would have your own unique vendor domain... ;-)

Actions

Copy link

Updated by Harald Holzmann 23 days ago

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

Actions

Copy link

Updated by Garvin Hicking 23 days ago

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?

Actions

Copy link

Updated by Harald Holzmann 23 days ago

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

Actions

Copy link

Updated by Garvin Hicking 22 days ago

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.

Actions

Copy link