I have tested this item ✅ successfully on 366e43a

please confirm that this PR is made in accordance with our AI policy https://developer.joomla.org/generative-ai-policy.html

@Reda-Muhamed Please do so. Otherwise this PR will be closed.

The code is wrong and only a band aid, I would not merge this. Beside that you violated the AI policy. I'm closing this PR. If you violate again you get banned.

Please explain what is wrong with the code. I tested everywhere that is impacted and there were no breaks to existing uses of sections (eg fields) and everything that didn't work correctly before now works (eg categories).

(And I would have allowed more than 20 minutes before closing and threatening)

if (count($parts) > 1) {
    $section = $parts[1];
} else {
    $section = str_replace('com_', '', $component);
}

$inflector = Inflector::getInstance();

if (!$inflector->isPlural($section)) {
    $section = $inflector->toPlural($section);
}

$viewDir = JPATH_ADMINISTRATOR . '/components/' . $component . '/src/View/' . ucfirst($section);

if (!is_dir($viewDir)) {
    $section = null;

    try {
        $extensionObject           = Factory::getApplication()->bootComponent($component);
        $extensionNamespaceParts   = explode('\\', (new \ReflectionClass($extensionObject))->getNamespaceName());
        array_pop($extensionNamespaceParts);
        $displayControllerClass = implode('\\', $extensionNamespaceParts) . '\\Controller\\DisplayController';

        if (class_exists($displayControllerClass)) {
            $controllerDefaultProperties = (new \ReflectionClass($displayControllerClass))->getDefaultProperties();
            $section                     = $controllerDefaultProperties['default_view'] ?? null;
        }
    } catch (\Exception $e) {
        // Component could not be booted; leave $section as null
    }
}

Wanted to make this suggestion here, but now it is cloesd. If like me to make a PR please ping me @HLeithner
Not sure if this would be the right way?

I want to clarify that I used the AI only to write the PR description and format my text, did not use AI to write the code. I read the issue, understood the problem, wrote the code myself, and tested it on my local computer

I want to clarify that I used the AI only to write the PR description and format my text, did not use AI to write the code. I read the issue, understood the problem, wrote the code myself, and tested it on my local computer

@Reda-Muhamed Ok, accepted.

However, this PR is not really a good solution.

It fixes the issue for the core com_content component.

But com_categories shall also work for 3rd party components.

Doing a $section = str_replace('com_', '', $component); would replace the com_ also when it appears in the middle of the string, so if someone names their component com_telecom_blabla they would have a problem.

@LadySolveig suggested a solution which looks a bit complicated at a first glance but would be safer, as it tries to get the view name from the extension's controller.

I will re-open your PR now so you can improve it, but maybe it would be easier just to make a new one. If you make a new one, please close this one here again so we don't have duplicates.

Thanks for your understanding.

@Reda-Muhamed thank you for your contribution. Please try the suggestion posted by @LadySolveig. Also, kindly ensure that the PR template is followed and that the AI confirmation checkbox remains in place. Thanks.

Thank you @richard67 for the suggestion. I will close this PR and open a new one with the code

@Reda-Muhamed
In the end, however, my suggestion is actually unsuitable for a view and should, if anything, take place in a display controller.
Your first fix and also my suggestion obscures the underlying problem and opens up a new one. What about views that do not have a plural ‘s’ in the plural? They no longer work with this either.
So it makes sense to think about this a little longer. This is purely a band-aid solution and not a reasonable fix, which everyone should be aware of.
Thank you for addressing the issue and for your contribution.

@Reda-Muhamed In the end, however, my suggestion is actually unsuitable for a view and should, if anything, take place in a display controller. Your first fix and also my suggestion obscures the underlying problem and opens up a new one. What about views that do not have a plural ‘s’ in the plural? They no longer Arbeit with this either. So it makes sense to think about this a little longer. This is purely a band-aid solution and not a reasonable fix, which everyone should be aware of. Thank you for addressing the issue and for your contribution.

I agree with you about handling the controller logic inside the view violate the MVC and the irregular plurals edge case proves this needs a proper architectural fix, I have closed the PR, thanks for the explaination

@richard67 what if we add a long-term solution for the future versions and make the component itself is responsible for providing it is view name.
it will be something like adding a method called getItemViewName() to the category interface and the view will not need to guess anything or use reflection.
i know this is a B/C break right now, but what do you think about this approach for the future architecture?

@richard67 what if we add a long-term solution for the future versions and make the component itself is responsible for providing it is view name. it will be something like adding a method called getItemViewName() to the category interface and the view will not need to guess anything or use reflection. i know this is a B/C break right now, but what do you think about this approach for the future architecture?

@Reda-Muhamed I'm not really the architecture expert, so better don't ask me.

But if it is a new feature it has to be made for the 6.2-dev branch, and if it is a b/c break like a new method in the interface is, it has to be made for the 7.0-dev branch.

@richard67 Since Joomla 7 is still far away, I was just wondering about Joomla's general policy: Do we ever accept a 'band-aid' patch in the current version just to fix the broken UX for current users, while waiting for the major release? Or is it strictly preferred to leave the bug open until the proper MVC solution is ready?
I'm totally fine with leaving this closed, Just asking to understand how you balance temporary UX fixes vs technical debt

@richard67 Since Joomla 7 is still far away, I was just wondering about Joomla's general policy: Do we ever accept a 'band-aid' patch in the current version just to fix the broken UX for current users, while waiting for the major release? Or is it strictly preferred to leave the bug open until the proper MVC solution is ready? I'm totally fine with leaving this closed, Just asking to understand how you balance temporary UX fixes vs technical debt

@Reda-Muhamed Please don't ask me all these questions. I am not the only maintainer, and if a band aid is accepted or not might be a decision of the maintainer team. Sure we accept band aid fixes if there is no other way and if they are made well. But we don't accept such fixes if they can break something for 3rd party extensions which was working before, like your PR currently would do for extensions with a "com_" in the middle of their name.

You're already thinking ahead and are curious, which is great. I think basically it doesn't matter which project you join if you have both a band aid fix and are already preparing for a major fix and present the whole path, that's always a good thing. However, as Richard mentioned, the band aid fix should also be well thought out and not cause additional issues.

@LadySolveig Thank you so much for the encouragement and the great advice, I will definitely keep that in mind for my future contributions.
​@richard67 Understood completely. Thank you again for your time and patience with all my questions today