Provided the topic would fit better the features discussion board (from my understanding), my thought is: in an ideal world, the default theme shall not have it, because it would be the equivalent of having a file named Settings.php in the home: at the next update (or file overwrite for any reason) it would be wiped out along with all the custom code.
For themes created by the admin panel it would be very nice to have I guess.
Actually, this makes me think the "correct" behaviour of the editing page should be to always work only on copies of the defaul theme, and if none exists, then silently create one. That would make it easier to deal with the customizations I think. It would likely require one more step on saving (i.e. ask the admin if he wants to apply the changes to all the users), but would be cleaner.
Well, you can have as much as 1 custom.css per theme and 1 custom_variant.css per variant, and even if you have more, elk will not care about them unless you change the code to have them use them. ;)
That's what variant is for @derived. If you need more variants, just add new ones where in each of them you can use custom.css. For the rotation, you can do it manually via admin control panel or you can create an addon that have scheduled change of default variant on daily basis. Adding a button to allow visitors / users to change variant may also be useful.
@emanuele, I'd prefer the default theme is hidden from theme edit page by default. Of course, I'd also prefer that there is an option, like by ticking a box, it will shows it back for those who wants to still edit it directly.
As for adding empty custom.css to default and variants' css, my thoughts were to check if they existed and create them only if there is none found. This way no overriding happens accidentally either by default install / update / upgrade or by copying from default / custom theme.
IIRC this was already tried and reverted during the SMF 2.0 development cycle because of popular revolt.
To me, the only option is either "it can be edited" or it cannot. Otherwise it's just another potential source of confusion.
But if you are doing an upgrade or resetting the installation uploading the files via FTP you cannot check if the file is there. The file is overwritten. ;)
1. No comment about confusion as it is always argueable. Removing default from theme edit is your idea anyway
@emanuele. I'd just prefer hiding it by default instead.
2. When I posted the earlier reply, I do mean "create" the custom.css file during installation / upgrade / update in verbatim, instead of having an empty file in default and variant css that can override any existing custom.css file.
By the way, this is just an idea which I didn't request as feature at the first place. Users can always use ftp client to create and edit it as they used to before.
I guess I got confused. lol
It happens when I'm trying to do too many things. :)
Yes, probably I started mixing things in my mind.
To be clear, my proposal (that may be exactly what you said) was something like "give an edit button, but silently hide the copying of the default theme". Instead of "force to create a copy of the default theme before being able to edit".
It's basically the same thing, in fact. Just a little difference in the front-end. :)
Ohh. you mean create it as part of the install script?
hmm... yes, it could be an option.
I'm not sure how server configuration is nowadays, a few years ago I remember a tons of issues in creating files via script due to permission issues, and for that reason the preferred way was to have the files in the repo as empty files.
It may still be a problem or not, TBH I have no idea.
But it makes sense, and I was wondering about it as well.
I don't get this. Are we talking about install theme or edit theme page or both?
I was thinking a simple php fopen script while creating custom.css in default theme and variant css, but to be honest, I didn't take what you said into account as I thought something like that would not usually fail.
The file's creation has its own issue as stated earlier by
@emanuele. Other than that, I think it should not be that difficult to implement in whatever UI design.