Hi, can you please add more detailed information on how to test.

I don't understand this:

Download the intalling package at the end in the checks area (there is a download button) and install a copy of Joomla.

I cannot find any "checks area", so testing standard way (J!4 Dev, composer, npm, com_patchtester, ...), getting following error:

Thank you, Jan

The checks area refers to the tests at the bottom of the pr in the GitHub. There is a section called download with a link named details, clicking there will take you on a page with an installable package

The checks area refers to the tests at the bottom of the pr in the GitHub. There is a section called download with a link named details, clicking there will take you on a page with an installable package

Thank you, now I understand.

Testing now,

I get some notices:

Notice
: Undefined property: stdClass::$inherits in
...libraries\src\Document\HtmlDocument.php
on line
812

Notice
: Undefined variable: template in
...libraries\src\Document\HtmlDocument.php
on line
833

Notice
: Trying to get property 'template' of non-object in
...libraries\src\Document\HtmlDocument.php
on line
833

Notice
: Undefined variable: template in
...libraries\src\Document\HtmlDocument.php
on line
834

Notice
: Trying to get property 'template' of non-object in
...libraries\src\Document\HtmlDocument.php
on line
834

Notice
: Undefined variable: template in
...libraries\src\Document\HtmlDocument.php
on line
835

Notice
: Trying to get property 'inherits' of non-object in
...libraries\src\Document\HtmlDocument.php
on line
835

Notice
: Undefined property: stdClass::$parent in
...libraries\src\HTML\HTMLHelper.php
on line
443

Notice
: Undefined property: stdClass::$inherits in
...libraries\src\Helper\ModuleHelper.php
on line
338


Notice
: Undefined property: stdClass::$inherits in
...libraries\src\Helper\ModuleHelper.php
on line
349

Notice: Undefined property: stdClass::$inherits in ...libraries\src\MVC\View\HtmlView.php on line 506

Notice: Undefined property: stdClass::$inherits in ...libraries\src\MVC\View\HtmlView.php on line 513

Not translated string: COM_TEMPLATES_TEMPLATE_FORK

After I created the child, I was not able to close the edit:

But child template was successfully created. Both parent and child can have different parameters, so it works OK for me.

I have one question, because I don't work with the following features, I would be interested in the difference between:

• Copy template
• Duplicate template style
• Create Child

Thank you.

I have one question, because I don't work with the following features, I would be interested in the difference between: Copy template/Duplicate template style/Create Child

Copy template copies Everything inside a template folder in another given name folder and applies some changes in the xml so basically it becomes a forked template. About Duplicate I have no clue and haven't read the code to see what it does (I'm guessing it's a copy without the changes in the xml?). The huge difference with the child template is that the new template inherits the executable .php files and also the static assets. This is extremely important for the template authors as their updates will never overwrite any of the files the end user tweaked.

Btw sorry about the notices, I really didn't spent much time on the com_templates component, just enough so someone could demo and get a feeling of the RFC. Also thanks for testing

I think this is not a bad idea.

A couple notes from me:

• I would prefer to extend existing "Template Styles" feature (in similar way): User create a new style (as usual), and optionally can create a file override within this style (technically may be implemented similar as you did, maybe, not sure). But in the way as you made here it is also fine.
• I would suggest to not to copy the XML, but create a very basic dummy, and update the template model: the model should load the params form from the parent XML when you open the params editing. This will be safe when the parent template will be updated and XML changed.
• And fix all notices it makes a bad impression ;)

From a technical semver perspective I would expect that this could not go into 4.0 as we are passed the point where such a major piece can be added and that it would have to be 4.1

That in itself might require some additional b/c changes to your proposal so there are no breaks with 4.0

@brianteeman what are you talking about? This is a totally new mode that can go in 4.0 and also there is no B/C for the current templates so....

@Fedik

I would prefer to extend existing "Template Styles"

Actually that's how it works under the hood. A child template needs the template styles of the parent...

I would suggest to not to copy the XML

That's a good point, what I did with the com_templates was really something in a hurry just so that people could actually test this

And fix all notices it makes a bad impression

I'm not the best php dev around here, I'll admit that ?‍♂️

Actually that's how it works under the hood. A child template needs the template styles of the parent...

Yeah, under the hood ;)
I thought about a User view. From User perspective it a different thing, User will see it as next features: templates, template styles and now template child.

But can be as you did, will be need a good explanation in a docs.

what are you talking about? This is a totally new mode that can go in 4.0

What he probably meant is that a beta version usually means it is feature complete. We should not add new features to it at this stage.

I would support what Fedik proposes. I think it becomes a bit confusing when you have templates, templates styles and child templates. Template styles and child templates are basically the same thing from a user view (variants of the template), first one with different parameters and the child one for different files. It would be great if all could be done in one place.

Yes that is what I meant

@dgrammatiko yes @brianteeman is right, this can't go to 4.0 because Beta = feature freeze and no more b/c break

And i'm not totally confident that this is totally b/c

It would be great if all could be done in one place.

That's not up to me to decide how the GUI will be formed. Keep in mind though that all the big template clubs basically are overriding the current com_templates so although any changes in the UX area there will be very welcome we might end up all the template frameworks out there... To be clear here I'm not proposing how the child templates should be presented/edited/etc in the GUI, I just did a quick and dirty hack of the com_templates just for demo purposes.

What he probably meant is that a beta version usually means it is feature complete

Tools (semver) are not rules! Bootstrap 4 introduced breaking changes in the beta phase or VueJs is calling some features in the RC! phase as experimental (API might change) vuejs/rfcs#189 (comment) but you want to strictly translate the semever for whatever reason. The point here is that if this is done in any minor version then none of the current templates can be moved to the new mode because that will be a B/C break.

And i'm not totally confident that this is totally b/c

Your perception is wrong or you have to prove me wrong!

@dgrammatiko yes @brianteeman is right, this can't go to 4.0 because Beta = feature freeze and no more b/c break

@joeforjoomla can you point me where is the B/C break here, I'm curious to see what I missed here because I think the first line of the description here calls for an non B/C breaking and opt-in behaviour?
If you can't do that please don't spread false information, it's not helping anyone

I can't say that for sure, i just had a quick look at the code and noticed a lot of changes in the template architecture... so i'm afraid that most probably there will be something that will break b/c

so i'm afraid that most probably there will be something that will break b/c

@joeforjoomla sorry but this is unacceptable. Code is not about fear or brave or supernatural. Test it! Test all the possible cases you can think, did it broke? Then either my claim of non B/C breaks is false or there is a bug. But just because you read some lines of code and you think that this might not be ok it is really unprofessional and deeply offending the creator of the PR.

I don't want to offend anybody... just to point out that merging so much changes at a Beta 3 stage is too risky.

merging so much changes at a Beta 3 stage is too risky

Merging any code that didn't broke any existing unit and codeception tests and also has been extensively tested by users is not risky. Your claims are totally out of this world, please stop it you're harming your reputation with all these comments

@wilsonge before anyone spends any more time on this can you confirm or deny that this would be acceptable to be merged in 4.0 even though we are now passed beta 2

I think it is fine for 4.1, no need to hurry, it does not have a B/C problems.

It like this, you have a two pills:
1 ? make it fast, but dirty
2 ? make it good and shiny, but slow

It like this, you have a two pills:

There's a third option:

• break it to 3 PRs : core changes/com_template changes and actual template changes
  You can then commit 1,3 in 4.0 (minor changes in both PR's) and provide the UI for the new mode in 4.1

In such scenario you have the existing templates in the new mode which is something that could not happen in a minor as it's an actual B/C break. Also I don't think I will be interested to work on this for a year or so...

? Maybe Joomla! project should have some kind of "Wild Card" status for feature requests which do not break B/C to allow them to be implemented in Beta in case such feature is better to implement in large version than in minor (in this case because of template developers). But I would say, this feature needs to be properly discussed especially among the leading template developers.

feature requests which do not break B/C

B/C isn't the issue here. Also it's not about SemVer.
It's about getting a release ready and when you're still adding features into betas you never get that J4 out of the door. Especially if said feature isn't yet polished.

B/C isn't the issue here. Also it's not about SemVer.
It's about getting a release ready and when you're still adding features into betas you never get that J4 out of the door. Especially if said feature isn't yet polished.

Yes, that sounds reasonable.

My comment about b/c was to highlight that if this was bumped to 4.1 then there might be a b/c issue with 4.0

I think the child template could be an amazing feature of Joomla 4. And, should be implemented in 4.0 instead of 4.1. If anyone cares from the leadership team should seriously consider giving it a try.

Thanks

Guys, you all see this PR is an RFC and far from being ready to be merged.
It's absolutely out of scope for Joomla 4.0 in its current state. So that discussion is pointless.

If someone brings it to a polished state within a few weeks and people are testing it, then that discussion could start. But now it's a waste of time.

Personally I like the suggestion by @dgrammatiko to break it up into multiple PRs.
Eg moving the template assets out of the template folder into media which could be done fast and could well go into 4.0. And that would lay one of the foundations for this proposal.

personally speaking i really don't care about strict rules
if there is a chance to do something better or even to do something to embrace the most user base desiderata
IMHO strict rules are not a dogma.....
f..of... b/c...

Suggestion about UI:

1 Move button "Create Child" to a template style form, and rename to "Override template files" (or something similar)

2 When User click this button the system will create a dummy template with only templateDetails.xml (with <inherits>parent_name</inherits>), similar to what is made in this PR.
After new template are created, the button "Override template files" hides, and appears the button to "edit files", which basically a link to "template edit".
Suggested xml :

<extension type="template_style" client="site">
  <inherits>parent_name</inherits> (or <parent_name>{blabla}</parent_name>) 
</extension>

3 This "new template" should not be visible in "templates list", only via template style. (this need to avoid confusing between all these template things)

What need to keep in mind:

User must be able to copy his/her fresh override to another site without hacking around a database.
So templateDetails.xml should contain <inherits>parent_name</inherits> (or <parent_name>{blabla}</parent_name>) instead of style_id, and "extension discovery" method should "register" this template as "template style" for "parent_name" template, and if "parent_name" not exist then it should crash and burn.

This "new template" should not be visible in "templates list"

That's extremely easy, it's an extra sql join in the templates list view and another one in the styles view and yes I like the idea as presented (also not to bad in terms of the needed code) ?.

So templateDetails.xml should contain parent_name (or <parent_name>{blabla}</parent_name>) instead of style_id

This a great point, also should be extremely easy to fix

Eg moving the template assets out of the template folder into media which could be done fast and could well go into 4.0

@Bakual we would have half the payload here if couple years ago we had gone by my proposal for the static media: #21294
It seems that most here see my proposal as madness but there is always some logic in them (ok sometimes too many things need to happen before the ideas are more digestible)

@dgrammatiko That other PR imho was to big and changed to much things at once. That's never a good idea.
This one here isn't that big, but it may benefit from splitting it up as well.

I think the idea is good. To late for 4.0 but certainly something to look at for 4.1. So if there is something that needs to go into 4.0 to prevent B/C issues in 4.1, we should look if that smaller part could be done.

If the idea is that users should only modify child templates base_html lookup is not needed.

To late for 4.0

I really don't understand this, why is it too late for 4.0? Are you in the process of releasing 4.0 in the coming week? If not then why is it too late? I didn't ask for people to do any coding here all I'm asking is if there are things that the project wants in a particular way to be implemented/named/etc. I'll do the code, will not take months or weeks so all I'm asking is for some feedback and then once the real PR is landed to be properly tested. I'm not asking for any favours or assigning any of the coders/creating a working group or anything between. The tracker counts over 400 open issues for the 4.0-dev branch https://github.com/joomla/joomla-cms/issues?page=1&q=is%3Aissue+is%3Aopen+%5B4.0%5D but you keep saying it's too late for any meaningful improvement. I think I have to throw the towel here...

why is it too late for 4.0?

i've the same question, plus, in some way this is a bug fix

There is no way any template to provide safe, self owned overrides and also allow the user to use/create their own ones

I really don't understand this, why is it too late for 4.0?

Afaik there was a decision to set the focus on the release blockers so it can be released soonish. Adding new features will throw that goal back for sure. But ultimately George has to decide, I have no say.
Realistically speaking, it's far to early to discuss if this may or may not go into 4.0. It has to be written first and then tested. And then comes the decision part.

Imho best approach is to split the PR. So parts that are working fine can already be merged and other parts which may be more controversial or need more love (eg UX things) could be delayed to 4.1 without any issues.

The tracker counts over 400 open issues for the 4.0-dev branch

Just on a sidenote, only 24 of those are release blockers. If those are fixed, J4 will be released regardless of the 400 others.

#30192 is just the core changes and it's open for tests, so please go and test