Joomla! Issue Tracker | Joomla! CMS #24414 - [4.0] ComponentHelper::getComponentName() returns wrong name in some cases

No Code Attached Yet J4 Issue

Closed
13 Nov 2022
Medium
Build: master
# 24414

NickSdot
30 Mar 2019

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.

NickSdot - open - 30 Mar 2019

joomla-cms-bot - change - 30 Mar 2019

Labels

Added: ?

joomla-cms-bot - labeled - 30 Mar 2019

franz-wohlkoenig - change - 30 Mar 2019

Category

Code style Components

⇒

Components

alikon - comment - 3 Feb 2020

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

alikon - close - 3 Feb 2020

alikon - change - 3 Feb 2020

Status	Information Required	⇒	Closed
Closed_Date	0000-00-00 00:00:00	⇒	2020-02-03 19:25:45
Closed_By		⇒	alikon

brianteeman - comment - 3 Feb 2020

@alikon what was the required information that was missing.

alikon - comment - 3 Feb 2020

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

alikon - change - 3 Feb 2020

Status	Closed	⇒	New
Closed_Date	2020-02-03 19:25:45	⇒
Closed_By	alikon	⇒

alikon - reopen - 3 Feb 2020

mbabker - comment - 3 Feb 2020

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 - comment - 3 Feb 2020

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

Harmageddon - comment - 9 Nov 2020

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:

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.
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 #21766, because there was a namespace field available in the database. The namespace field of the ComponentRecords is null at all times.
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?

Quy - change - 16 Feb 2022

Labels

Added: No Code Attached Yet
Removed: ? ?

Quy - unlabeled - 16 Feb 2022

joomdonation - change - 13 Nov 2022

Status	New	⇒	Closed
Closed_Date	0000-00-00 00:00:00	⇒	2022-11-13 14:11:37
Closed_By		⇒	joomdonation

joomdonation - close - 13 Nov 2022

joomdonation - comment - 13 Nov 2022

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 !

Add a Comment

Older
Newer

Joomla! Issue Tracker - CMS

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

Steps to reproduce the issue

Expected result

Actual result

System information (as much as possible)

Additional comments

Add a Comment

	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));
	}