I still cannot replicate the reported problem. What am i missing

@brianteeman It mainly affects templates that use your own child template workflow, like Yootheme Pro.

well thats an issue for yootheme to fix then

at this point fixed that also templates with underscore in the name, like "mytheme_business" -> "mytheme_business_child" and that without B/C break.

at this point fixed that also templates with underscore in the name, like "mytheme_business" -> "mytheme_business_child" and that without B/C break.

Repeated my tests and this time with a parent template called brian_default and a child therefore of brian_default_child

I still cannot replicate the reported problem

Sorry, my mind was on something else.
You are right, with child templates created by Joomla there is no problem, because $template->template == $layoutTemplate.

But there are other ways to use child templates, see Yoothe Pro, which already offered this before Joomla knew what it is.
Here $template->template == 'yootheme' and $layoutTemplate == 'yootheme_childname'.

In $this->_path['template'] the paths are already correct, until Search and Replace.

The search string is not structured in a way that it only considers complete template paths.

JPATH_THEMES . DIRECTORY_SEPARATOR . 'yootheme' is therefore also used in JPATH_THEMES . DIRECTORY_SEPARATOR .'yootheme_childname'.

The result is then replacing 'yootheme' with 'yootheme_childname' in JPATH_THEMES . DIRECTORY_SEPARATOR .'yootheme_childname' and that ends in JPATH_THEMES . DIRECTORY_SEPARATOR .'yootheme_childname_childname'.

This change ensures that this no longer happens.

At this point it should be mentioned, not the template/template framework loads the overrides, they are just provided.
The override is loaded by the component from the HtmlViewer, this cannot be intercepted via the template.
At least I am not aware of any way.

I have never used a yootheme template not will I ever use a yootheme template. If their template doesnt work with core joomla then they should change their code. This is why Joomla releases nightly builds of development builds as well as multiple alpha, beta and release candidates. < /rant>

@degobbis can you give me access to a test site please? I would like to have a look at directly, I can't follow the reason why this only happens with a 3rd party pagebuilder.

I can give you access tomorrow evening :-) thank you

why this only happens with a 3rd party pagebuilder.

@HLeithner I suspect that it would happen with any template that has _ in the name (ie cassi_opeia). I would prefer another way to deal with the parts of the path, ie in the application lifecycle when the template is selected there's a query that fetches all the non disabled templates. We could store a simple array $app->templates with the name, path, legacy or not, etc. Then all the path resolvers could just search the array and pick/skip. In sort no guessing...

At least I am not aware of any way.

@degobbis the way to override the paths exists since forever:

Actually you could override many things. It's very weird that none of the good templates out there is not using it.

@degobbis showed me what's happening, and ignoring if it's right or not what yootheme does, we should replace the complete path ant not only a part of it, so from my side this pr ok.

@HLeithner I suspect that it would happen with any template that has _ in the name (ie cassi_opeia).

My test above showed that it works fine with a _ in the name

My test above showed that it works fine with a _ in the name

@brianteeman you didn't tested the failing case, ie parent === some_thing child: some_thing_child_name

Also I'm pretty sure that Yootheme are still legacy templates (ie not supporting the child templates) so not so sure that the tests are representative

@HLeithner I suspect that it would happen with any template that has _ in the name (ie cassi_opeia).

My test above showed that it works fine with a _ in the name

It's not the underscore, the reason is that the str_replace an older "replaced" string replaces a second time, then you have yootheme_elisa_elisa and in this case joomla should not replace wrong pathes which are not relevant to replace.

@HLeithner thanks for the explanation of the real issue

joomla should not replace wrong pathes which are not relevant to replace

I see. FWIW the code is like that since before v4 so it's weird that this was never came up.

Hopefully @coolcat-creations could convince them to embrace the modern templates structure...

you are right you changed something on this but that shouldn't be relevant for this issue, the original code already solved a similar issue it seems ddf93d2

did this ever worked? @coolcat-creations for example in joomla 4.0 before child templates has been introduced?

did this ever worked? @coolcat-creations for example in joomla 4.0 before child templates has been introduced?

@HLeithner all versions of Joomla 4.+ (since beta.4: #30192) had support for child templates. 4.1 just brought the missing UI. Basically the question is if it ever worked in 3.x?

I'm asking if yootheme had worked with the old joomla version.

I made an override for the category list I never had this task before inside YT so I can't say if it worked before. I just wonder why we discuss so much if the fix is quite easy and existing ? Does it cause problems? I don't know. Does it solve problems? Yes it does.

. I just wonder why we discuss so much if the fix is quite easy and existing

At the beginning it took a long time to identify where the problem was because it was not in joomla child template but in something from yootheme with the same name. None of your initial reports on github mentioned yootheme

Because yootheme (or a user of yootheme) has not (until now) reported an issue with this code so it is was unclear where the problem arises. In general we cant just make changes in core because of the behaviour of an extension as it would be impossible to test and impossible to ensure that the code was not reverted as it had no apparent effect or putpose

I made an override for the category list

Have you made overrides of anything else before. The problem should be the same

Yes I did overrides of modules in YT before and it works everywhere without issues. In J3 and J4

so what is different this time

Probably the way how the category list template is loaded. If you compare the category list view to Joomla 3 category list views a Layout was introduced into the view which calls again the views. I don't know what are the reasons behind that change.

Let's leave third party extensions aside.

The code is already existing since Joomla 3 (https://github.com/joomla/joomla-cms/blob/3.10-dev/libraries/src/MVC/View/HtmlView.php#L663-L671), when childthemes were not considered yet.

According to the comment, it was used to use layouts from other templates by exchanging the path of the active template with the path of the alternative template.

Let's analyse what this code is supposed to do:

Let's assume the properties are set as follows:

• $template->template = 'originaltheme'
• $layoutTemplate = 'originaltheme_myclone'

This results in the following values for the str_replace:
Search pattern: <path-to-joomla-root>/templates/originaltheme
Replace with: <path-to-joomla-root>/templates/originaltheme_myclone
In path: <path-to-joomla-root>/templates/originaltheme_myclone/html/category/mycat_article.php

The error here is that the search pattern is found even if it is part of the wrong path.

It should only replace if the path is <path-to-joomla-root>/templates/originaltheme/html/category/mycat_article.php.

Now the search pattern is found in <path-to-joomla-root>/templates/originaltheme_myclone/html/category/mycat_article.php and converted to <path-to-joomla-root>/templates/originaltheme_myclone_myclone/html/category/mycat_article.php, and that is wrong.

So it is necessary to make the search pattern more precise so that it does not swap subpaths, and thus does correctly what it was originally conceived to do.

This PR takes care of that.

The YooTheme Pro template was just the trigger that led us to this BUG.

So please let's stop outsourcing the fix of this BUG to third party extension developers when it's clear that it's mishandled in core.

Translated with www.DeepL.com/Translator (free version)

@HLeithner can this be merged then ?

I head not the time to check this again in deep. I'm also not sure if it gets in to beta2 (no matter if 4.4 or 5.0) since that's tomorrow. for 4.3 no further releases are planned.

@HLeithner can it go into the next beta? It has successful tests?

didn't had time to look more in deep in this problem, rebasing for 4.4 at least make sense.

@laoneo and @MacJoom

can you please have a look at this

I have tested this item ✅ successfully on 02abfdc

Actually this should be merged much earlier in the release lifecycle to identify some regressions, as I think it has the potential to break templates. Nevertheless, I'm merging it for now, so hopefully people test it with 3rd party templates. When problems will occur, I will not hesitate to revert it during the release candidate phase of 4.4.

Thanks for all the help here from so many people and for the understanding that it took so long till we maintainers could care about it.