I dont understand the reasoning of this change and restricting the new features to a child template. I understand the benefit of having a child template in core and that this child is showcasing the new advanced features. I just dont see the benefit of removing those advanced features from the base template style. Maybe I am missing something?

Also is it really a good example of a child template? Typically a child template would use the root php files of the the parent template and its only the style params that change together with the addition of any template overrides. This child template replaces the root php files of the template which is not something a regular user can do with the ui when creating a child template

Doesnt this need an update sql to remove the extra params from the main cassiopeia template. I am aware that on a clean install they are not stored but if you have enabled either the advanced font or advanced color settings then the params are stored

Also is it really a good example of a child template? Typically a child template would use the root php files of the the parent template and its only the style params that change together with the addition of any template overrides. This child template replaces the root php files of the template which is not something a regular user can do with the ui when creating a child template

The power of child template is, that you can override any template file you need and are not restricted to the html folder. But if you still like something, you can let Joomla! use the parent template solution.

Doesnt this need an update sql to remove the extra params from the main cassiopeia template. I am aware that on a clean install they are not stored but if you have enabled either the advanced font or advanced color settings then the params are stored

The parameters were implemented in J!6, so they shouldn't be in a live system (yet). But if someone updates over the beta, the parameters are in the DB but are ignored, as they're not used in the main template.

I dont understand the reasoning of this change and restricting the new features to a child template. I understand the benefit of having a child template in core and that this child is showcasing the new advanced features. I just dont see the benefit of removing those advanced features from the base template style. Maybe I am missing something?

The power of child template is, that you can override any template file you need and are not restricted to the html folder. But if you still like something, you can let Joomla! use the parent template solution.

Is it even really a child template now

I applied the PR and ran the update sql

There is no template style created. I think you are missing an sql statement in the update sql to create the style

I applied the PR and ran the update sql

There is no template style created. I think you are missing an sql statement in the update sql to create the style

Thanks, didn't commit the last change. Fixed it now.

If you already have a child template called extended then you have a problem on update

The first sql to insert an extensions will fail (as intended) but the second one to insert a style will pass as there is no check and you end up with two styles called cassiopeia extended but with different options

Not really sure what to suggest to ensure the child template can be successfully installed into both db tables. Perhaps give it a more random name and take advantage of the language strings to be more meaningful

When you create a child template the entry in the extensions table contains data in the manifest_cache column. The sql in this PR does not create anything.

There was a discussion elsewhere about the purpose of this field and if it even did anything but in absence of any changes then the sql in this pr should also create the manifest cache.

When you create a child template the entry in the extensions table contains data in the manifest_cache column. The sql in this PR does not create anything.

There was a discussion elsewhere about the purpose of this field and if it even did anything but in absence of any changes then the sql in this pr should also create the manifest cache.

@brianteeman The manifest cache of an extension is updated after a new installation and after an update. It does not need to be in the SQL.

Might not need to be there but it sure looks odd when it's not

I have tested this item ✅ successfully on dfda667

Tested with the full package from Drone.

@dautrich Have you tested with a new installation or with an update? If update: Could you test again with the latest changes of the update SQL scripts? If new installation: Could you also check with an update?

Not really sure what to suggest to ensure the child template can be successfully installed into both db tables. Perhaps give it a more random name and take advantage of the language strings to be more meaningful

There is still a problem if you already have a child template called extended

I tested with the full package 6.0.0-beta3-dev+pr.46034 from Drone.
I can repeat my test starting from Joomla_6.0.0-beta2-Beta-Full_Package and updating via the Drone package.

I tested with the full package 6.0.0-beta3-dev+pr.46034 from Drone. I can repeat my test starting from Joomla_6.0.0-beta2-Beta-Full_Package and updating via the Drone package.

@dautrich Yes, that would be great.

Not really sure what to suggest to ensure the child template can be successfully installed into both db tables. Perhaps give it a more random name and take advantage of the language strings to be more meaningful

There is still a problem if you already have a child template called extended

@brianteeman Only if it is for the same parent, too, and with the latest changes that will be kept as it is. I think that is a very unlikely case.

My latest test (starting from 6.0.0-beta2 and updating via the Drone package of the PR) was successful.
@richard67 Should I report another positive test on the issue tracker?

What are the benefits of these changes at "beta" stage?

Not really sure what to suggest to ensure the child template can be successfully installed into both db tables. Perhaps give it a more random name and take advantage of the language strings to be more meaningful

There is still a problem if you already have a child template called extended

@brianteeman Only if it is for the same parent, too, and with the latest changes that will be kept as it is. I think that is a very unlikely case.

anyone since the release of joomla 4 can have created a child template of cassiopeia and extended would not be an reasonable name to have given it.

My latest test (starting from 6.0.0-beta2 and updating via the Drone package of the PR) was successful. @richard67 Should I report another positive test on the issue tracker?

@dautrich Yes please.

I have tested this item ✅ successfully on 277df2a

Second test (starting from 6.0.0-beta2 and updating via the Drone package of the PR) was successful.

What are the benefits of these changes at "beta" stage?

none #46034 (comment)

Wouldn't it be preferable to move those discussions to a higher management level?

Personally, I like the extensions to the Cassiopeia template. Will allow less technical to customize their websites without the need to change user.css.

I just tested an update on a site that did have a child template with the name extended. I know have multiple extra styles
#46034 (comment)

Personally, I like the extensions to the Cassiopeia template. Will allow less technical to customize their websites without the need to change user.css.

I agree - just dont see the need at all for this PR but if it has to be this way then it should be bulletproof

I just tested an update on a site that did have a child template with the name extended. I know have multiple extra styles

@brianteeman Have you tested with the latest changes on the update SQL scripts? There should not be any duplicate template styles.

P.S.: I've just updated the branch so Drone has built new packages which include the latest changes.

@richard67 thanks - that explains that - didnt happen with the new package

I have tested this item ✅ successfully on ce3364c

I've tested an update with the patched package created by Drone on PostgreSQL.

All worked as expected.

Only when trying to view images in the template editor I get an error. But I get that also on a clean 6.0-dev.

I will investigate if it is related to something on my environment, and if not I will create a new issue.

RTC

I think the unrelated issue I have mentioned in my test result was caused by my local environment missing some required PHP extensions. On my remote environment I did not have that issue.

Can I request that the maintainers make a decision on this PR and not rely on the test results alone. Also as this is changing the PR from @drmenzelit it would be good to get their feedback

@brianteeman the PR was already discussed in Production. Personally I would prefer to keep the parameters in Cassiopeia, but the decision was to go with a child template.

@brianteeman the PR was already discussed in Production. Personally I would prefer to keep the parameters in Cassiopeia, but the decision was to go with a child template.

thanks for responding. obviously I asked the question because there is nothing here about production department making a decision etc

Huge thanks to @drmenzelit who started this whole journey and helped all the way through. @bembelimen for the work he took on to take the child template from idea to part of Joomla 6.0, @richard67 for his sql magic and to all the testers and advisors who helped us to make this a great example of a child template.