My recommendation, please keep the database out of it. Just a normal override option would be great. I don't know why Joomla has deep integration with the database for all possible features except the most important Media Manager.

Thanks

My recommendation, please keep the database out of it

One way or another the db is involved here as it holds the style data

I don't know why Joomla has deep integration with the database

Very short answer: db is the only secure storage it got. Just don't ask me why the template style details (or any such data) needs any elevated security ?

Couple 2 note :)

First note.
I am not strong in English, but for me the property name inherits is a bit of controversial (Usually it means the children inherit parent.)

In current usage I would call it style_template, so the template style object will have 2 property:
Existing template the name of folder for parent template
New style_template the name of folder for override (for child template).

Second note.
I am not very understood why need parent property.
I think if the template has empty inherits it is parent automatically, or maybe I missed something?

I am not very understood why need parent property.
Check these lines in the HTMLHelper:

				$templaPath = JPATH_THEMES;

 				if ($template->parent || !empty($template->inherits))
 				{
 					$client     = $app->isClient('administrator') === true ? 'administrator' : 'site';
 					$templaPath = JPATH_ROOT . "/media/templates/$client";
 				}

Basically it's a switch for the new mode, the static files exist in the media/template/( administrator || site )/templateName. It can't be done with only the inherits value because then will not cover the parent template (or it can be done but I'm not that clever ?)

I am not strong in English, but for me the property name inherits is a bit of controversial

Inherits imply inherits from ..., that's why I picked it but naming is hard so anything else can go there, I don't have strong feelings for this

Basically it's a switch for the new mode, the static files exist in the media/template/( administrator || site )/templateName

I see now.
For switching we can just check if the folder exists, then do switch, something like:

$template = $app->getTemplate(true);
$templatePath = JPATH_THEMES;
$client = $app->isClient('administrator') === true ? 'administrator' : 'site';

if (is_dir(JPATH_ROOT . "/media/templates/$client/{$template->template}"))
{
	$templaPath = JPATH_ROOT . "/media/templates/$client";
}

So if original (parent) template has the styles/scripts in /media/templates, then HTMLHelper will take it

Inherits imply inherits from ...,

Exactly this part is confusing me ?
I read it like MyStyle inherits from Atum/Cassiopeia folder, but in the implementation it like MyStyle inherits from MyStyle folder,

For switching we can just check if the folder exists, then do switch, something like:

This is true we could have eliminated the parent attribute both from the db and the manifest but I'm against it I mean stretching the code you could make any template inheritable but it will be wrong. Most, current templates use something like this:

	$logo = '<img src="' . $this->baseurl . '/templates/' . $this->template . '/images/logo.svg" class="logo d-inline-block" alt="' . $sitename . '">';

which will fail miserable if you try to make a child from it (the $this->baseurl for the child will be a for the parent will be b, file not found will be the result)
Parent templates should always use the API for css,js,images like:

$logo = HTMLHelper::image('logo.svg', '', ['class' => 'logo d-inline-block'], true, 0);

in order to not break their children...

read it like MyStyle inherits from Atum/Cassiopeia folder, but in the implementation it like MyStyle inherits from MyStyle folder

Are you referring to the db names or the php ones?
I might be answering the wrong questions here ?

Are you referring to the db names or the php ones?

To both :)

$template  =  $app->getTemplate(true);

var_dump($template->inherits); 
//   ^^^^^^^^^
// This part, I expect it like: $template inherits from "inherits value". 
// But "inherits value" contain "own folder name"

Well, nevermind, maybe it just me.

But "inherits value" contain "own folder name"

Maybe I misunderstood you comment in the other PR:

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

I'm against it I mean stretching the code you could make any template inheritable but it will be wrong

I think that okay. Sure, it will not work for hard-coded paths, that is not our problem.

Maybe I misunderstood you comment in the other PR: <inherits>parent_name</inherits>

Yeah, I meant like this:
User create override called foobar that inherits cassiopeia, so dummy xml contain:

<name>foobar</name>
<inherits>cassiopeia</inherits>

Sorry for confusing :)

UPD: But I forgot that the template_styles table already contain template column, that holds the name of the parent template.

@Fedik how about instead of parent we use inheritable (means can have children) and instead of inherits we use parent where parent is just the parent template name?

@brianteeman any suggestions here?

how about instead of parent we use inheritable (means can have children) and instead of inherits we use parent where parent is just the parent template name?

That sounds good.

To be sure I right understood:

The dummy xml of child template will have something like:

<name>foobar</name>
<parent>cassiopeia</parent>

<name>foobar</name> will go to style_template column of database;
<parent>cassiopeia</parent> will go to template column of database;
and because we have a parent this will set inheritable = 0 in database

And parent template will have <inheritable>1</inheritable>

I am understood correctly? :)

Yup, you got it right. The pain is that I have to redo all the parent/child templates for the tests ?

Child themes are a great idea.
But I have one thing that confuses me.
<inherits> siteparent </inherits>

Usually child themes do not require their own manifest, but the name of the child theme directory indicates the link with the parent.

In the case of an example. The name of the child theme must be siteparent_sitechild, otherwise, to determine where is the parent and where is the child, you will have to look at the manifest of each template.

Usually child themes do not require their own manifest, but the name of the child theme directory indicates the link with the parent.

Technically a child template is an actual template but only with one file the manifest (templateDetails.xml). This way there are very few changes that need to be done in the core. Can it be done with a snake case naming? Well it's just code so it can be done but will bee extremely inefficient as you will end up scanning the templates dir and checking each folder. Now the data is coming from the db which one way or another Joomla is using it atm and has exactly 0 performance impact. Also it's not just to get something working in the core you have to think/see what's the code in com_templates. With the proposed approach the changes are minimal.

Technically a child template is an actual template but only with one file the manifest (templateDetails.xml). This way there are very few changes that need to be done in the core.

I recently did this for the yootheme template, I had to override a couple of classes.
The child template itself is selected in the parent's settings.

One way or another, I would still add a naming rule for the child template.
You can check during installation.

One way or another, I would still add a naming rule for the child template.

That's possible, eg prefix it with the parent name like parentName_childName but it's something that will be done in the com_templates and won't affect anything here

That's possible, eg prefix it with the parent name like parentName_childName but it's something that will be done in the com_templates and won't affect anything here

In the future, it will be possible to make a tree display.

But it is more necessary for developers to name their child templates correctly.

@Septdir by reviewing the code is this something that breaks yootheme templates? Is this something that will be useful for you/yootheme?

@Septdir by reviewing the code is this something that breaks yootheme templates? Is this something that will be useful for you/yootheme?

I haven't reviewed your PR code yet, and I don't think this will be a problem for YOOtheme.
In fact, you added what was missing to the core. This will be very useful, and most importantly, hello to the standardization that many developers are implementing.

My hack for YOOtheme template looks like this
https://github.com/SeptdirWorkshop/jYProExtra/blob/master/jyproextra.php#L191
And I would love to get rid of it in J4

@wilsonge any signal will be good here

We are in feature freeze for j4.0

@HLeithner so then I will close this one?

@dgrammatiko that was not my intention, it's more that we should focus on bugfixing and target new feature on 4.1 branch.

I would like to give a proper feedback on this feature too, but didn't had the time to look at the pr .

At a first glance I'm a bit confused about some decisions you made.

1. why do we need the database entry? or better why do we need both?
2. wouldn't it better to introduce a completely new "siteowner override concept", I didn't thought much about it but it's not only the template you may want to extend other parts of the cms like plugins or libraries (don't know if useful).
3. Did I saw right that you only can not have a chain of templates? base template -> company template -> site template. for example piwigo has exactly this type of template engine.
4. I'm a bit concerned about performance, every database query and every file exists check costs server resources

2. wouldn't it better to introduce a completely new "siteowner override concept"

I don't know what you mean by that but the child templates actually solve a very real problem: updates! (but not only that)

1,3,4

You have to check what I did here and also step through a bit in the lifecycle. The child template is a real template thus the only extra load is some lookups for layouts and static assets, there is no extra db query. The idea of chain able templates will not work well with Joomla simply because the lookups will grow exponentially per subfolder and thus it will be awfully slow. But you can deal with it in the com_templates (eg presentation).

I'm a bit concerned about performance, every database query and every file exists check costs server resources

It is reuse existing template style, so no extra cost

thanks for the explanation I would like to make some code suggestion, I hope it's ok for you I have reopened the pr.
beside my comments the pr should be rebased on 4.1

I have tested this item ✅ successfully on eec9d9a

One of the most useful things in J4 I've seen so far...

I really really shouldn't be pressing merge here - but I've seen several template clubs in favour of this so I'm going to break my own rules and hope I don't regret it. thankyou for this really nice feature @dgrammatiko