Add SCSS compiler to Template

[C-Lodder]

This was going to be re-evaluated for J4.0 and needs to be done:

https://github.com/joomla/joomla-cms/pull/11941

[ghost]

@C-Lodder - Allon has already done a lot of work on this as part of the previous template team efforts we were discussing in the UX room. Adding SCSS support was a big priority for me, we got it working, I did a lot with it and after we added some cool compiling features relating to the front end template.

It might not be perfect but we should take a look before starting from scratch. https://github.com/Digital-Peak-Incubator/tpl_tauristar

[mbabker]

Can we find a way to not do the compiling with PHP? Or find a library that isn't as completely FUBAR as the current lessc compiler is? I had to switch the joomla.org template from that to the recess compiler the Bootstrap team used to use because there were too many issues related to caching in lessc (we're talking the grid system being off by pixels because of it).

[dgrammatiko]

@C-Lodder @cpfeifer the Leafo parser/compiler is a piece of crap, but that is all it;s available in php

I will agree with @mbabker a simple node command will do (of course we need to check that npm and also scss compiler exists

EDIT: I can provide simple code for that

[mbabker]

The node stuff is fine for working from the main repo. We're talking here about compiling from the template manager, unless the node stuff works in that context.

[dgrammatiko]

@mbabker node modules can be local or globally available. WE ASSUME, for this to work universally, that the scss module is globally available, then the directories are irrelevant

[ghost]

I'll leave the implementation up to you guys. I'm simply pointing out there has been some work done already. This is just something to consider, I'm not saying we have to use it.

I want to do this in the best way possible, no question. Maybe we can use some of it to save time, maybe not. Just an FYI :)

[mbabker]

What are you trying to get at here? Can you trigger npm, node, or whatever by clicking a button in the Joomla backend? If the answer's no, that's not an option for the distributable package. If yes, how do you do it without triggering host issues with running commands from PHP scripts or whatnot?

[C-Lodder]

@mbabker - Then we'll have to go with Node. I am of course in favour of this as it's more powerful and maintained, but I'm also thinking about the average end user. Unless we'll simple say "If you want to change the template styling, then use the custom.css".

[C-Lodder]

I don't think npm can be trigged via a button click

[dgrammatiko]

I don't think npm can be trigged via a button click

IT CAN

Or to make it even more flexible: check if module scss is globally available then use it else check if in the root direcory of joomla

[dgrammatiko]

http://php.net/manual/en/function.shell-exec.php

[C-Lodder]

IT CAN

Am I right in assuming there could be some potential security issues that needs to be taken into consideration then?

[mbabker]

A lot of hosts block system(), exec(), and that type of stuff. So it's not a reliable option.

[dgrammatiko]

There's not much joomla can do about that

[C-Lodder]

And what is safe mode is enabled?

[dgrammatiko]

Of course another option is to organise some PBF specifically to fix Leafo's crap and then go the PHP way. There's no easy solution here

[mbabker]

Exactly. That's why whatever option is available in the Template Manager, via the UI, can't be reliant on running a serverside function to work. It has to be possible through PHP or JavaScript available to the end user basically.

If we were only talking about workflow for contributors to core, then what's already been started here is more than enough. But we're talking about the end user now and the distributed production package, so options are more limited.

[dgrammatiko]

@mbabker ok we can do it in the client side! AJAX power...

[dgrammatiko]

Will code something

[dgrammatiko]

based on https://github.com/medialize/sass.js or there is another better script for that?

[ghost]

We were considering an option to let users access the compiler feature from the backend. I don't believe it's hooked up to anything currently in that repo. It's just a button.

My major complaint with the LESS implementation is that I want to access the compiler because I'm a front end developer. It's only part of the build version, not the core release. I'm definitely not the average end user, but I feel the functionality should be more accessible for people who want to use it.

I have a lot of input on how the compiling features should be available to users, but it has to exist before we can get to that conversation. We can tackle that part when we get there.

[dgrammatiko]

I have a lot of input on how the compiling features should be available to users, but it has to exist before we can get to that conversation. We can tackle that part when we get there.

ACL what else?

[mbabker]

The LESS compiler's been shipping as part of the core package for a while now (I think 3.2 added it with the major rewrite of the template manager). Originally it was only in the repo but that was long addressed.

[C-Lodder]

@dgt41 - I really dont like the idea of compiling SCSS on the client side.

[dgrammatiko]

@C-Lodder why? there is a benefit here: offloading processor hungry tasks from the server

[ghost]

I think we should provide the option for client side compiling. Have it be off by default, but let people choose. Some people don't like it, some people want it, I personally find it to be valuable in some cases.

In any case, it's a polarizing topic with no easy answers. Some people just prefer one method over the other so I say let people choose their own path on this one. If they mess up their own sites or don't have the right server requirements, that's on them in my opinion. If they want to use it, they have to turn it on and have the right skills to make it work.

[mbabker]

IMO there isn't an issue having a client side compiler. However, I think we need to retain feature parity with what we have now for LESS. When you open a LESS file you have the option to compile it to CSS in the template manager; that needs to be retained and preferably not with a busted ass compiler that breaks things catastrophically (seriously, you try working with a grid at 724px that expands out to 732px because the compiler caches stuff incorrectly; that's how bad lessc is). So yes, that will mean there are more code paths for compiling, but it's ultimately going to give the most flexibility.

[ghost]

I agree. It's all about providing flexibility so people can work how they want to work. Flexibility is what I've always loved about Joomla. A solid SCSS implementation is obviously valuable to me, but I also think if we can provide this functionality in a useful and accessible way to designers and front-end devs, it will set us apart from other platforms.

It's powerful functionality that appeals to a lot of people, and no one else is really leveraging this functionality. Easy CSS compiler options is honestly the number one reason I use third party frameworks, and I know that's true for a lot of people as well.

That's just my perspective, many end users don't even know what CSS is, but we could appeal to a lot more advanced users by expanding on this functionality in my opinion.

[C-Lodder]

Advanced users should be using node, and should have nothing to do with a built in compiler.

My initial though on this was to provide a basic implentation of scss for use who arent experienced with node

[ghost]

Sure. I guess it depends on what you do exactly, but I couldn't do what I do nearly as fast or effectively without a compiler. I honestly don't know how I did anything before they came out.

From a marketing perspective: "Look at the awesome stuff you can do with SCSS in Joomla" is a marketing goldmine. There is no doubt in my mind of that. Maybe we're targeting more intermediate users and integrators instead of advanced developers, but that middle market is where a lot of Joomla people are.

I was a rookie when I first started and Joomla opened the door for me to get deeper into all of this stuff. If we want to get more front-end and design people involved in the project this is a great way to open a door for people in my opinion.

Like I said, I'll let you guys handle the implementation. I trust your judgement on the technical side, all of this is just my opinion :)

[dgrammatiko]

Maybe we're targeting more intermediate users and integrators instead of advanced developers, but that middle market is where a lot of Joomla people are.

To tackle this audience we need to solve some fundamentally wrong parts of joomla, namely: javascript and layouts are tightly coupled to bootstrap and at this point there is no easy way to override them. For a solution on the first on check and test some of the mentioned PRs here: https://github.com/joomla/40-backend-template/issues/94

[mbabker]

Joomla in general just sucks when you aren't doing straight up HTML. I'd love to fix the hack job known as the install app to better represent Joomla's capabilities to handle mixed HTML/AJAX (JSON).

But don't get me started on Yet Another Babker Rant 😉

[brianteeman]

compiling anything from the web ui is never going to be successful - no one anywhere has got it working yet on budget hosts As stated above we have a huge number of hosts with things like shell_exec disabled but more importantly all the compilers use a lot of memory. Something that the cheaper hosts dont provide and when you run out of memory it kills your entire site not just the compile.

[dgrammatiko]

@brianteeman we could go client side: https://github.com/joomla/40-backend-template/issues/92#issuecomment-256969219

[brianteeman]

Not going to look at any software that hasn't had a stable release yet. Been there, done that, never again

[C-Lodder]

BS4....still smashing alphas since 2015 :P

[dgrammatiko]

@brianteeman which one are you referring to here?

[brianteeman]

This one https://github.com/medialize/sass.js We've been killed in b/c hell before using a script that had not yet reached a stable release. It scares the hell out of me

[C-Lodder]

minified the worker weighs 2.7MB

Are we really going to import a file of this size to start compiling client side?

[dgrammatiko]

gzipped it's still 580KB.

Which is almost the same weight as jQuery and Bootstrap not minified/gziped

[C-Lodder]

You can't compare 2 files that serve a big purpose in Joomla and are served minified by default, to a 2.7mb file that will drastically slow down the page loading speeds in com_templates.

[brianteeman]

and you cant compare 2 files that are probably already cached etc etc

On 29 November 2016 at 16:59, Lodder notifications@github.com wrote:

You can't compare 2 files that serve a big purpose in Joomla and are served minified by default to a 2.7MB file that will drastically slow down the page loading speeds in com_templates.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joomla/40-backend-template/issues/92#issuecomment-263630138, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPH8bbLB51zyDfIgRFnub99jVkWOTMVks5rDFnngaJpZM4KjLeJ .

-- Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. https://brian.teeman.net/ http://brian.teeman.net/

[dgrammatiko]

2 files that serve a big purpose in Joomla

Joomla's UI doesn't need any of those you can achieve the same with a fraction of those two files, but that's another sad story...

a 2.7mb file that will drastically slow down the page loading speeds in com_templates

That's not the way I see it. You can ajax the whole procedure and since we do have promises everything can be as a background task. That script WILL NOT be loaded in any view in the template. Probably you got me wrong here...

[ghost]

After a week of digging through all the user feedback I honestly haven't found many requests for client side compiling features of any kind. I think it would be nice but it's certainly not a priority or a highly requested feature.

Maybe simple solutions such as a static recompile option, or an option to compile custom files or changes, or maybe we just leave it open to 3rd party development. If it's possible to have an option that's great, but if it causes more problems than it solves then it's not worth it in my opinion.

[mbabker]

If the template manager is going to support users editing LESS/SCSS/whatever-gets-compiled-into-CSS-in-2017 then there needs to be a compiler otherwise we have to block the user from being able to edit those files if we can't compile their changes.

And as pointed out, the PHP libraries are out the window. They're more FUBAR than the convenience is worth.

[dgrammatiko]

2 files that are probably already cached

@brianteeman whatever caching mechanism you choose, the first time visitors will always have a VERY BAD response time, because there won't be any cache.

@cpfeifer read again the reasons (previous comments) why a server side compilation is not a safe bet for joomla. Also the technical approach to a solution is NOT what people might think or wish, totally irrelevant

[C-Lodder]

@cpfeifer

After a week of digging through all the user feedback I honestly haven't found many requests for client side compiling features of any kind.

How much of the user feedback came from template developers?

Maybe simple solutions such as a static recompile option

I have no idea what you mean by static recompile option....

or an option to compile custom files or changes

Compiling is compiling. If we do it, we do it properly. We're trying to figure out the best approach.

[ghost]

We have a lot of feedback from template developers, there was a template feature survey conducted around this time last year. There are a few requests for this feature, but not many. I would personally appreciate this feature but it's not highly requested.

By static I mean a recompile button that has to be pressed by the user. It only recompiles when requested, not dynamically.

Compiling is compiling, however it's not necessary to recompile unchanged code. It's not uncommon to check for changes before recompiling and it's completely possible to add individual files into a compiling script.

That's just my take on this. Do what you think is best, don't me slow you down.

[brianteeman]

@dgt41 I am referring to the caching of the core bootstrap/jquery files. As they are being served from the cdn then there is a very high % chance that they are already cached in the users browser even if they have never visited the specific joomla site before. That is what i keep saying. The "cost" of using bootstrap/jquery are minimal if they exist at all because of this

On 29 November 2016 at 18:19, Lodder notifications@github.com wrote:

Maybe simple solutions such as a static recompile option, or an option to compile custom files or changes

@cpfeifer https://github.com/cpfeifer - I have no idea what you mean by static recompile option........As for the user feedback how much of it came from template developers?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joomla/40-backend-template/issues/92#issuecomment-263653027, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPH8Y4bwlFW6i5UQVEGa_LPtDLxofgPks5rDGy2gaJpZM4KjLeJ .

-- Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. https://brian.teeman.net/ http://brian.teeman.net/

[dgrammatiko]

That is what i keep saying. The "cost" of using bootstrap/jquery are minimal if they exist at all because of this

Obviously I disagree here, but let's not start this conversation again. IF the decision is to stick with jQuery and Boosvrap js AND NOT being able those to be overridden, then we are back to Mootools/jQuery days. At least PLT should really consider the introduction of an API so front enders don't have to compromise their work...