Skip to content

fix(mod_submenu): hide disabled components in mod_submenu#32539

Closed
sawmurai wants to merge 3 commits intojoomla:4.0-devfrom
sawmurai:fix/mod_menu/hide-disabled-components-in-panel
Closed

fix(mod_submenu): hide disabled components in mod_submenu#32539
sawmurai wants to merge 3 commits intojoomla:4.0-devfrom
sawmurai:fix/mod_menu/hide-disabled-components-in-panel

Conversation

@sawmurai
Copy link

@sawmurai sawmurai commented Feb 27, 2021

Pull Request for Issue #32456 .

Summary of Changes

The changes introduced hide menu items for disabled components from the cpanel.

Testing Instructions

  1. Disable the CSP extension

Actual result BEFORE applying this Pull Request

The menu item "Content Security Policy" is still available in the cpanel.

Expected result AFTER applying this Pull Request

The menu item "Content Security Policy" is not available in the cpanel anymore.

Documentation Changes Required

@sawmurai sawmurai force-pushed the fix/mod_menu/hide-disabled-components-in-panel branch from 1c460c7 to e22e93f Compare February 27, 2021 11:45
* @since 4.0.0
*/
public static function preprocess($parent)
public static function preprocess($parent, array $disabledExtensions)
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably you should set an empty array as default, so it's not braking if some extension using this call...

Copy link
Author

Choose a reason for hiding this comment

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

Good idea, thank you!

@bembelimen
Copy link
Contributor

@SharkyKZ could you please elaborate why you gave a thumb down? Probably there is room for improvement in this PR based on you feedback. Thanks.

@richard67
Copy link
Member

I don't know if this is the right approach or not, but it contains a few mistakes:

  1. The extension name is not unique in the extensions table, so there may be several extensions of different types having the same name value. What has to be unique is the combination of element, folder and client_id for extensions of type "plugin", and element and client_id for extensions of other types. But the database query here doesn't contain any restrictions ("WHERE ...") for the extension type and client_id:

$query->select($db->quoteName('e.name'))
->from($db->quoteName('#__extensions', 'e'))
->where($db->quoteName('e.enabled') . ' = 0');

As far as I understand the purpose of this PR, only extensions of type "component" should be fetched with that query, and they should be restricted also to the right client_id here (1 for admin).

  1. The property "element" is checked to be in the array, which contains the "name" values and not the "element" values, as you could see by the query mentioned above. See here the check:

if ($item->type === 'component' && in_array($item->element, $disabledExtensions, true))

For lucky circumstances, the "name" and "element" values are the same for (core) components, but that might not always be granted, so it can happen we compare apples and pears here. Therefore at least from a formal point of view the above check is wrong.

  1. Beside the above 2 points my knowledge about the submenu is too little to say if the approach chosen here is right or wrong. Hoping for more detailed feedback e.g. from @SharkyKZ .

@richard67
Copy link
Member

richard67 commented Feb 27, 2021

P.S. to my above comment's items 1 and 2: For the reasons stated there, I would expect the query to be:

		$query->select($db->quoteName('e.element'))
			->from($db->quoteName('#__extensions', 'e'))
			->where($db->quoteName('e.type') . ' = ' . $db->quote('component'))
			->where($db->quoteName('e.client_id') . ' = 1')
			->where($db->quoteName('e.enabled') . ' = 0');

And later below it should be:

$names[] = $item->element;

@sawmurai
Copy link
Author

@richard67 Thank you so much for the comments! I updated the PR. Let's see what @SharkyKZ's feedback is.

This would be my first contribution to joomla despite having used it for the past couple of years, so I would not be surprised if I misunderstood something and my approach is totally wrong.

The idea behind my approach is basically:
Since the menu is rendered from the preset-xml files (in the error case) my only information are the element and type of the menu item, so I know that its a component of "type" com_csp. To link that to the state of the component (enabled, disabled) I have to query the database beforehand and pass that information to the precheck function, which already appears to be hiding menu items under certain conditions.

@alikon
Copy link
Contributor

alikon commented Mar 1, 2021

humm....
too much code imho see #32555 too...

@sawmurai
Copy link
Author

sawmurai commented Mar 1, 2021

Agreed! Did not know about the ComponentHelper

@richard67
Copy link
Member

@sawmurai If you agree that PR #32555 shall replace this PR here: Can we close your PR here? Of course you can do that yourself, too.

@sawmurai
Copy link
Author

sawmurai commented Mar 2, 2021

Yep, I will close it :)

@sawmurai sawmurai closed this Mar 2, 2021
@sawmurai sawmurai deleted the fix/mod_menu/hide-disabled-components-in-panel branch March 2, 2021 12:32
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.

5 participants