Skip to content

Comments

[BUGFIX] Improve package name resolving#704

Open
IchHabRecht wants to merge 2 commits intoTYPO3:mainfrom
IchHabRecht:bugfix/improve-package-name-resolving
Open

[BUGFIX] Improve package name resolving#704
IchHabRecht wants to merge 2 commits intoTYPO3:mainfrom
IchHabRecht:bugfix/improve-package-name-resolving

Conversation

@IchHabRecht
Copy link
Contributor

@IchHabRecht IchHabRecht commented Feb 22, 2026

We had problems with local extensions having functional tests which results in non-existing extension in the test instance. Some further debugging showed that the problem relies in package name resolving. Our repository has the same name as our vendor and the extension key doesn't match the package name. Due to some path resolving the package name in $testExtensionsToLoad was resolved incorrectly and couldn't be linked anymore.

This change may resolves #665 and #683

@oliverklee
Copy link
Contributor

I propose this goes to: Releases: main, 9, 8

public function getPackageInfo(string $name): ?PackageInfo
{
return self::$packages[$this->resolvePackageName($name)] ?? null;
return self::$packages[$name] ?? self::$packages[$this->resolvePackageName($name)] ?? null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to fix resolvePackageName() instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't any need to resolve known package names.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are both right and wrong.

If vendor/package-name is handed over it's okay to short-ciruit here and solving the issue in that case.

But when extkey or a folder with extkey is passed, for example in extensions from older days having:

  • typo3conf/ext/<my_ext_key> or /extension-root-path/typo3conf/ext/<my_ext_key>
  • typo3/sysext/<sys_ext_key or /extension-root-path/typo3conf/ext/<my_ext_key>

it fallbacks to resolvePackageName. Could be that this still leads to an issue. Not tested yet.

I had in mind to rework the resolve logic to create "candidates" for the different forms and doing lookups instead of simply returning only "one" value form resolvePackageName() or similar.

I guess that we could do that as a first fix even if it only fixes it for a subset of cases.

Removing the basename() thingy - not sure about that, there was a reason why I added it back then for 12.5.0 release ... need to check my notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

core functional tests does not work if checkout directory is called 'typo3'

3 participants