This breaks all existing overrides with zero benefit

Please move all the layout files in the root of the module (ie: https://github.com/joomla/joomla-cms/tree/4.3-dev/administrator/components/com_categories/layouts). The root layout folder is supposed to be used for layouts that are global...

This breaks all existing overrides with zero benefit

I agree that it will break all existing overrides. Therefor I've created this PR based on 5.0-dev instead of the current 4.x

I do not agree about the "zero benefit"

This PR simplifies the implementation of the creation of linktype. Why put logic to create the $linktype in 8 files? Not very DRY is it? Therefor a JLayout to replace 8 blocks of the same code to just one.

The following code

if ($item->menu_icon) {
    // The link is an icon
    if ($itemParams->get('menu_text', 1)) {
        // If the link text is to be displayed, the icon is added with aria-hidden
        $linktype = '<span class="p-2 ' . $item->menu_icon . '" aria-hidden="true"></span>' . $item->title;
    } else {
        // If the icon itself is the link, it needs a visually hidden text
        $linktype = '<span class="p-2 ' . $item->menu_icon . '" aria-hidden="true"></span><span class="visually-hidden">' . $item->title . '</span>';
    }
} elseif ($item->menu_image) {
    // The link is an image, maybe with its own class
    $image_attributes = [];

    if ($item->menu_image_css) {
        $image_attributes['class'] = $item->menu_image_css;
    }

    $linktype = HTMLHelper::_('image', $item->menu_image, $item->title, $image_attributes);

    if ($itemParams->get('menu_text', 1)) {
        $linktype .= '<span class="image-title">' . $item->title . '</span>';
    }
}

to

    public static function getLinktype($item, $itemParams)
    {
        $attributes = [
            'title'     => $item->title,
            'menu_text' => $itemParams->get('menu_text', 1),
        ];

        if ($item->menu_icon)
        {
            $attributes['icon'] = LayoutHelper::render('joomla.menu.icon', $item);
        }
        elseif ($item->menu_image)
        {
            $attributes['image']    = LayoutHelper::render('joomla.menu.image', $item);
        }

        return LayoutHelper::render('joomla.menu.linktype', $attributes);
    }

Please move all the layout files in the root of the module. The root layout folder is supposed to be used for layouts that are global...

I've tried modules/layouts/menu, but didn't see the output. After using echo LayoutHelper::debug( instead of `echo LayoutHelper::render( I've noticed that the JLayouts in module where not used.
I'll try again... just to be sure

I'll try again... just to be sure

It needs an attribute more, let me find an example:

// instead of this
 return LayoutHelper::render('joomla.menu.linktype', $attributes);

// do
return LayoutHelper::render('joomla.menu.linktype', $attributes, JPATH_ADMINISTRATOR . '/modules/mod_menu');

// Coming from: render($layoutFile, $displayData = null, $basePath = '', $options = null)

Also there's a sublayout so you don't have to call LayoutHelper::render() inside a layout:

    /**
     * Render a layout with the same include paths & options
     *
     * @param   string  $layoutId     The identifier for the sublayout to be searched in a subfolder with the name of the current layout
     * @param   mixed   $displayData  Data to be rendered
     *
     * @return  string  The necessary HTML to display the layout
     *
     * @since   3.2
     */
    public function sublayout($layoutId, $displayData)

no its not dry and maybe it should have been created dry in the first place by the people that implemented it. but its here now and I still dont see where the change has any benefit at all. but i do see a lot of negatives

no its not dry and maybe it should have been created dry in the first place by the people that implemented it. but its here now and I still dont see where the change has any benefit at all. but i do see a lot of negatives

copied: maybe it should have been created dry in the first place

But it was not.. and I think that it should not hold us back to leave it as it is when we can make things DRY.

copied: i do see a lot of negatives

I think too.. This change has an impact on all mod_menu implementations.
Again... it should not hold the project back to improve the code.

once again - what are the benefits of this change and do they outweigh all the negatives.

once again - what are the benefits of this change and do they outweigh all the negatives.

To prevent changes like these: #40675
Eight files had to be changed to get a single thing done.
After merging this PR only one file need to be changed.

Does it outweigh all the negatives? i do not know. I hope it does.

Thanks hans for your contribution, I see your point. But I don't see the benefit. mod_menu has already a layout system and building a menu is already expensive (server resources) enough. Adding (more?) layouts to the mix doesn't make too much sense for me. I have another approach for my own templates, splitting the code into multiple template files so they are better override able but don't think it's really needed.

Especially all the layouts you created have tivial code which could sit in the template it self if needed and doesn't need to create an overhead loading the layout. ymmv

Thanks hans for your contribution, I see your point. But I don't see the benefit. mod_menu has already a layout system and building a menu is already expensive (server resources) enough. Adding (more?) layouts to the mix doesn't make too much sense for me. I have another approach for my own templates, splitting the code into multiple template files so they are better override able but don't think it's really needed.

Especially all the layouts you created have tivial code which could sit in the template it self if needed and doesn't need to create an overhead loading the layout. ymmv

Thank you for explaining the "no benefit" part with some excellent arguments. I like that. I see your point and will close this PR.