Add SCSS compiler to Template #92
Comments
|
@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 |
|
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). |
|
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. |
|
@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 |
|
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 :) |
|
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? |
|
@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 |
|
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 |
Am I right in assuming there could be some potential security issues that needs to be taken into consideration then? |
|
A lot of hosts block |
|
There's not much joomla can do about that |
|
And what is safe mode is enabled? |
|
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 |
|
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. |
|
@mbabker ok we can do it in the client side! AJAX power... |
|
Will code something |
|
based on https://github.com/medialize/sass.js or there is another better script for that? |
|
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. |
ACL what else? |
|
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. |
|
@dgt41 - I really dont like the idea of compiling SCSS on the client side. |
|
@C-Lodder why? there is a benefit here: offloading processor hungry tasks from the server |
|
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. |
|
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. |
|
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. |
|
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 |
|
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 :) |
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: #94 |
|
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 😉 |
|
compiling anything from the web ui is never going to be successful - no one anywhere has got it working yet on budget hosts |
|
@brianteeman we could go client side: #92 (comment) |
|
Not going to look at any software that hasn't had a stable release yet. Been there, done that, never again |
|
BS4....still smashing alphas since 2015 :P |
|
@brianteeman which one are you referring to here? |
|
This one https://github.com/medialize/sass.js |
Are we really going to import a file of this size to start compiling client side? |
Which is almost the same weight as jQuery and Bootstrap not minified/gziped |
|
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 |
|
and you cant compare 2 files that are probably already cached etc etc
…On 29 November 2016 at 16:59, Lodder ***@***.***> 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
<#92 (comment)>,
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/>
|
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...
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 |
|
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. |
|
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. |
@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 |
How much of the user feedback came from template developers?
I have no idea what you mean by
Compiling is compiling. If we do it, we do it properly. We're trying to figure out the best approach. |
|
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. |
|
@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 ***@***.***> 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
<#92 (comment)>,
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/>
|
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... |
|
I'm in favor a front end API and we should be able to override everything. That's kind of the point of MVC and it's big advantage in our architecture that we should do more with. I question the need to recompile all template core files and bootstrap dependencies unless it's an override and people are choosing to do that. Any end user solution should be completely based on overrides, they shouldn't be based around potential changes to the core file implementation. We all know users shouldn't be messing with core files, too many do already and we should discourage it. Core files don't need to be recompiled, only custom changes do and it needs to be implemented in a way that overrides the core files and leaves them untouched. Custom css or scss doesn't necessarily need to be added to template.css.min, it could be complied into custom.css.min or whatever. If users can override the compiling script in through a template override they could do whatever they want. I think just having an option available or some way to hook into the functionality is enough for people who want to do this kind of thing. |
|
We aren't talking about recompiling all of the core files here. Unless I've missed something, this is focused on the template manager integrations, where a user can and will edit anything the UI gives them access to. Yeah, that might mean the files shipped with the core templates because users directly modify those instead of copying the templates or whatnot, but that's beside the point and not something we can prevent; the template is the user's domain. If we try to get fancy by detecting the file changes and compiling those into a custom.css file or something, we're going to make the code a lot more complex than it needs to be. Clicking "Compile |
|
Well that's pretty much another topic. We'll provide a |
|
I agree we shouldn't make this overly complex. There are downsides to this particular idea but the upside is it takes some of the other complications away. We don't necessarily need a detection system, just a way for people to hook into the functionality so they can customize the way they want to. All we need to do is make the functionality more accessible to people who want to use it. It's all in there right now but it's much easier to install a third party solution than it is to take advantage of the core functionality. As I've said all along, it's not a highly requested feature but I don't see any downside to providing an easier way to let people tap into it. We can bring this functionality out in many different ways, either through an override, a more accessible script, or better documentation. It doesn't have to be complicated. |
* com_finder es6 3 * Update index.es6.js * Update index.js * //TODO replace with joomla-alert * //TODO replace with joomla-alert * make simple * make simple * make simple
|
am I wrong or has scss compilation been added to 3.9? |
|
You are wrong :) |
This was going to be re-evaluated for J4.0 and needs to be done:
joomla/joomla-cms#11941
The text was updated successfully, but these errors were encountered: