[4.0] ComponentHelper::getComponentName() returns wrong name in some cases

[NickSdot]

I run into an issue which results in making some problems and extra effort required to use the old element name of a component in J!4.

In an edit view of a component is no $this->option set by default. So the used \Joomla\CMS\MVC\Controller\FormController is using ComponentHelper::getComponentName($this, $this->getName()) in it's constructor to get the element name for the url to redirect to the view.

Now the 'problem' is that getComponentName() is using getNamespaceName() which results in a different name than the real element name.

Steps to reproduce the issue

Use a component named 'com_brand_component_name' (with underscores) and namespace 'BrandComponentName'. Click edit/new to go to an item.

Expected result

getComponentName() returns 'com_brand_component_name'.

You should end up on this link: 'index.php?option=com_brand_component_name&view=name&layout=edit'.

No 404 error.

Actual result

getComponentName() returns 'com_brandcomponentname'.

You will end up on this link: 'index.php?option=com_brandcomponent name&view=name&layout=edit'.

With message 404 – component not found.

System information (as much as possible)

Joomla 4.0 Alpha 8 Nightly, PHP 7.2

Additional comments

I am aware of that by setting $this->option in my view controller to 'com_brand_component_name' the issue is solvable.

Just wondering whether or not this is an expected behavior or if it would be worth to think about to have a fallback for that special case to avoid setting the option hardcoded in every controller manually.

[ghost]

@infograf768 can you please comment?

[infograf768]

A better person to ask would be @mbabker

[alikon]

Closing this due to not receiving required information to determine if this is a bug or not. If you feel this still needs review, please open a new tracker entry with as much information as possible to ensure it can be reviewed properly

[brianteeman]

@alikon what was the required information that was missing.

[alikon]

Mar 30, 2019 and no action so what is the point ?
but maybe you are right

[mbabker]

Did anyone even take the time to attempt to reproduce the issue or understand what the code is currently doing to cause this bug report to be submitted in the first place? Or was everyone just hoping I might peak at it and answer and realize that 9 months later I never did and decided the item should go unactioned?

[alikon]

it seems that my view on issues management it is far away from yours....
but that's Ok

[Harmageddon]

I can confirm this issue while migrating an own third-party component to the new structure of J4.

This code only considers namespaces that contain the segment ...\Component\...:

joomla-cms/libraries/src/Component/ComponentHelper.php

Lines 480 to 493 in e893aab

	public static function getComponentName($object, string $alternativeName): string
	{
	$reflect = new \ReflectionClass($object);
	if (!$reflect->getNamespaceName() || \get_class($object) === ComponentDispatcher::class || \get_class($object) === ApiDispatcher::class)
	{
	return 'com_' . strtolower($alternativeName);
	}
	$from = strpos($reflect->getNamespaceName(), '\\Component');
	$to = strpos(substr($reflect->getNamespaceName(), $from + 11), '\\');
	return 'com_' . strtolower(substr($reflect->getNamespaceName(), $from + 11, $to));
	}

Considering https://docs.joomla.org/J4.x:Namespace_Conventions_In_Joomla, this only applies to core components. The desired namespace structure for 3rd-party components is <CompanyName>\<ComponentName>\<ClientName>.

In my point of view, there are three options, every one with their own drawbacks:

1. Guess the component name by picking the second part of <CompanyName>\<ComponentName>\<ClientName>.
   [+] Simple solution
   [-] Enforces this particular namespace structure. In some cases, the second part of the namespace might not be identical to the com_<something> of the component name. For example, one might use com_companycomponent combining company and component name for the com_<something> identifier.
2. Backtrace from the namespace to the extension.
   [+] Extensions can have a <namespace> tag in their XMLs (or maybe even several? don't know). If we get this information, we could build a reverse lookup table that maps namespaces to their extensions. The ComponentHelper manages a list of ComponentRecords, which have a namespace field. This would need to be filled with the respective values and used here.
   [-] Needs to build a large lookup table. Would have been easier before [4.0] Generate the classmap from the manifest files #21766, because there was a namespace field available in the database. The namespace field of the ComponentRecords is null at all times.
3. Don't rely on ComponentHelper::getComponentName.
   [+] In ComponentDispatcher::dispatch, the value of the option parameter is passed to a $config array that is passed down to the FormController constructor. Using $this->option = $config['option'];, we could avoid this particular bug.
   [-] It would need to be checked in which other places ComponentHelper::getComponentName is used and if it can be avoided there.

IMO, the most versatile options would be 2. But as I just recently started migrating this component to J4, maybe someone else with more experience in J4 namespacing and similar things has a suggestion here? Respectively, if someone already migrated their component to J4 successfully, maybe you can post a solution here?

[joomdonation]

I just reviewed the documentation from this page https://docs.joomla.org/J4.x:Namespace_Conventions_In_Joomla again, the namespace for third party extensions has been updated to CompanyName\Component\ComponentName\ClientName
With this namespace structure, the current code works well. Further more, since the day Joomla 4 released, no-one else complains about this anymore, so I assume the current code works well and will close this issue.

If you still have this issue, feel free to re-open. Thanks !