User tests: Successful: Unsuccessful:
The idea here is to give the ADMINISTRATOR all the tools to fully customize the admin template!
What is in it?
A way to override the color values from the fields in the back end
A way to create a fully customized color theme using an override of the variables.less
A way to compile the new css (also the rtl)
A way to recompile the css in every joomla update if variables-user.less is not empty
Only drawback is that for every update the adminstrator needs to recompile the css! (maybe we can do it through the update script?)
None really
The usual way with custom color fields (the way it was)
Apply this patch
paste @bodyBackground: light blue;
into isis/less/variables-user.less
select Use inline styles No
and hit the compile button
hit save on the toolbar and you should get a light blue background! congrats!
One consideration for PLT: The file isis/less/variables-user.less needs to be excluded from the update files that joomla provides in each update package!
Labels |
Added:
?
?
|
Labels |
Added:
?
?
|
@brianteeman we can add a warning label, for those chaps but I guess with great power comes great responsibility
One consideration for PLT: The file isis/less/variables-user.less needs to be excluded from the update files that joomla provides in each update package!
Actually, then the template CSS files could not be provided in an update package either. So now there'd be a requirement to run the LESS compiler on each site on each update.
@mbabker not really, joomla will continue to provide the standard template.css but admins need to take one more step to recompile the css so that the site will not change styling after the the update. If generatecss.php was shipping with the joomla installation a simple call to the script at the end of the update process could solve this extremely easily.
See that's exactly the point. If you recompile the CSS with anything in your user variables file, you're changing the template.css file. So immediately after an update is finished, without adding the LESS compiler to the update process, the site is back at the default Isis styling until the admin recompiles.
The generatecss.php file is just a shortcut for us to update all the template CSS files. The JLess API ships as part of core and is used in the template manager.
@mbabker what do you think about dgt41@95455e6
It would need to be heavily tested on hosting environments to see how it would affect the update time. It's a solution I suppose, but honestly I think our entire update system isn't as stable as we need it to be and adding more features or steps to it isn't something I personally want to see happening until we can get it at an appropriate (granted it would be really subjective) level.
@mbabker I take your word for the update system (I haven’t really check the code).
But this is one more step on postInstall (I think so, right?) so provided that all cases are covered (file doesn’t exist, variables are wrong and file cannot be compiled) and that this code fires at the end I don’t see how things can go bad…
Of course heavy testing in this case in mandatory especially for the update procedure
Never the less, this is a different point of view for the customization of the templates and even if it’s not accepted (as is, or at the current codebase) is a good example of how to utilize bootstrap framework in a more appropriate way than what we do right now with the inline overrides
Compiling LESS online is always wrong. If you know what are you doing you should use something like Grunt / Gulp for that or anything that does it locally for you. If you don't know what are you doing you won't be able to fix/understand issues caused by this.
It transmits the wrong message to joomla users and will make things harder to manage for us. People may think that they can add/edit all the LESS files and argue for lost changes.
So here
I agree with Roberto, nothing I would like to see in Joomla. Too many problems around the corner.
I'm not against the idea of enabling the templates to be customized necessarily. But, bigger picture, I see a lot of quirks with the overall proposal.
The custom.css file gives you the maximum control over customizing things without hooking into other structures like overwriting LESS. The user variables file really only works for changing colors, paddings, and other details that are repeated. To really get the most out of customizing the template, you're really looking at a scenario where you're better off with layout overrides (which shouldn't be deleted at update except for ones that exist in the template) or copying the template outright as a new template (a feature in the template manager).
Like I mentioned before, at what point do we draw the line on customizing templates in the UI? We aren't a template framework and frankly I think they're crap and bloated anyway with how many options they shove in. Let's keep it simple for the simple folks, the advanced folks would be able to manage copying the template and syncing it at releases as needed I'd hope.
Setting this to needs Review so the CMS maintainers can decide if it is worth pursuing
Status | Pending | ⇒ | Needs Review |
I agree with Brian, Roberto, Michael and Robert.
I wrote an own template as a proof of concept to see if it's possible to compile the template params directly into the final template.css file. It's actually possible using our JLess class to inject an array which is then used as LESS variables. That's actually quite powerful.
However compiling it (with all Bootstrap files and stuff) takes several seconds and is memory intensive and thus is bound to fail on shared hosts. You can't do that on an update.
I also don't see the reason to add more parameters to our template. Our job is to provide a robust template. Customisation is already possible easily for those who want.
Closing as I don't see us implementing this. To much risk and almost no gain.
Status | Needs Review | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-04-16 10:14:11 |
I also don't see the reason to add more parameters to our template.
Actually this PR was all about totally removing all the color inputs from isis
But I respect the fact that online LESS compiling is kinda wrong (actually if you know what are you doing and have enough resources, I think is not).
Thanks for all the input
the less compiler can be very memory intensive and has the potential to
kill a site on poor shared hosting
On 15 April 2015 at 15:26, Dimitris Grammatiko notifications@github.com
wrote:
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/