Not exactly what I was thinking and now that I see it - it makes no sense to do it this way as the font sizes should not be related to the colour scheme.

My idea was to keep the two new fieldsets (as in the other proposal) but only to display them if you have set a flag in the templatedetails.xml

I think requiring users to touch the .xml is a bad idea. Thats a dev feature not user feature.

I think requiring users to touch the .xml is a bad idea. Thats a dev feature not user feature.

That's not what I said

I'm not sure, if I should modify the database on updates (insert the new parameters in the template style).

@drmenzelit In past (before J5) we did not do that because we had to use risky string modifications for the params, but since 5.0 we can use json functions to add values, so we could do that with an update SQL script, e.g. "6.0.0-2025-06-19.sql". If you want I can make a PR for your branch with that.

@drmenzelit What I don't understand yet is why we have the params in both the extensions table and the template styles table for the Cassiopeia template.
For Atum we have emty params in the extensions table and have only params in the template styles table.
Maybe in case of Cassiopeia it's a remainder from early development and can be cleaned up in the extensions table?

For front-end template:
We should not modify existing template under any circumstances, unless there a bug. It will break many exiting installations that uses this template.

There 2 options:

• new style: but only when it is compatible with template file, and both old and new style will work without extra work from User side.
• new template

For back-end template:
We can just override existing template parameters with new, and call it a "new".

UPD.

We should not modify existing template

I meant the "template parameters"

We can add the new fieldsets to cassiopeia with the default option for them to be disabled and then only enabled by the user. This would not be changing any existing paramaters. There would no need for the db to be updated. Only when a user enables the fields and saves will any changes be written to the db.

That also can work, yes.

But for new installations it need to be enabled somehow :)

@richard67

If you want I can make a PR for your branch with that.

What I don't understand yet is why we have the params in both the extensions table and the template styles table for the Cassiopeia template.

When we finally find the best way to modify the template, I will be grateful if you can help with the DB part

@Fedik

We should not modify existing template under any circumstances, unless there a bug.

We have introduced changes in the template already (e.g. font schema).

I hope we can bring this into 6.0, it is an improvement.
Found an issue:
Set advanced colour settings to no and advanced font setting to yes. nothing happens.
Set advanced colour settings to yes, the font settings are applied, it they are activated or not.

What do you think about a note on the colour settings tab "please be aware that colour contrast is essential for accessibility of your site. You can test your colours for example here .. link to the WAVE tools"?

What do you think about a note on the colour settings tab "please be aware that colour contrast is essential for accessibility of your site. You can test your colours for example here .. link to the WAVE tools"?

I agree with the sentiment of the message but I wouldn't link to any specific 3rd party test

I have tested this item ✅ successfully on 7eb732e

I had a clean Joomla 6 Nightly (alpha4-dev) installation that I just installed and installed the Update PR:
Joomla_6.0.0-alpha4-dev+pr.45624-Development-Update_Package.zip

As soon as the installation was finished, I came to a screen with this:

An error has occurred.
0 Cannot instantiate abstract class Joomla\Module\Popular\Administrator\Helper\PopularHelper
Return to Dashboard

that seems that it should be something needing fixing?

thats because your method of testing is flawed and can often create problems. In this case its because you are updating to a version of joomla below your current version and is nothign to do with the code in this pull resuest

thats because your method of testing is flawed and can often create problems. In this case its because you are updating to a version of joomla below your current version and is nothign to do with the code in this pull resuest

OK, thanks I will use the Full Package instead.

thats because your method of testing is flawed and can often create problems. In this case its because you are updating to a version of joomla below your current version and is nothign to do with the code in this pull resuest

OK, thanks I will use the Full Package instead.

better yet - learn how to use git - its not hard and will save a lot of time

I have tested this item ✅ successfully on 451c008

I have successfully tested this (after some help from Brian).

Thanks @drmenzelit

I've restored @chmst 's test result as the commit which invalidated the count was just a clean branch update.

RTC