Re: Request to add a custom.css feature in the Joomla Core

[Amy Stephen]

Very clever, Tobias. This is smart. The frontend devs will like this.

On Sunday, June 9, 2013 6:53:21 AM UTC-5, Tobias Zulauf wrote:

hello,

I think it would be a nice feature to overwrite all template.css files with an custom.css. So I have written a small plugin for the Joomla Core to do this.

So you can, with this file (custom.css), overwrite all template css files (e.g. the template.css) and this file will not be touched by an eventual update.

This feature works for all templates e.g. beez3/protostar/isis/hathor if the custom.css exists at /templates/"templatename"/css

The Plugins loads the file (custom.css) if it the file exists with the plugin event "OnBeforeCompileHead()"

If you want to test this feature I have add an zip file at the JoomlaCode Tracker.

I hope you can test and comment my first Joomla! feature.

JoomlaCode Tracker:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31135
Github PR:
https://github.com/joomla/joomla-cms/pull/1259
Github diff:
https://github.com/joomla/joomla-cms/pull/1259.diff

Regards,
Tobias

[Noppadon Tasananutriyakul]

Hi,

Thank you for solve many problem by a simple solution.

Regards,
Noppadon T.

2013/6/10 Amy Stephen <amyst...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Noppadon Tassananutriyakul
new media marketing manager.
digiHUB Co.,Ltd. http://www.digiHUB.co.th

-----------------------------------------------------------------------------------------------------------------

FREE hosting  Cheap hosting  Premium Hosting
All apartment and daily rental  Utimate Online Marketing Tools
If you cannot read the message.Please change encoding to Unicode(UTF-8)

[Fotis Evangelou]

We launched our new template club nuevvo.com on June 7 and the use of a custom.css file is one of the features of our templates - so we can make updating easier. It doesn't even require a Joomla! core change, just make template designers adopt this as a simple pattern.

[Matt Thomas]

Agreed. This is the approach that I've used with Construct for years now and it's simple, easy to use and understand. Best of all, it survives upgrades.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Mon, Jun 10, 2013 at 8:51 AM, Fotis Evangelou <fevan...@gmail.com> wrote:

We launched our new template club nuevvo.com on June 7 and the use of a custom.css file is one of the features of our templates - so we can make updating easier. It doesn't even require a Joomla! core change, just make template designers adopt this as a simple pattern.

[Chad Windnagle]

I believe the thought behind this is by adding it to core the custom.css overrides not only survive template upgrades by also survive switching templates altogether, right? 

--
Regards,
Chad Windnagle
Fight SOPA

[Hannes Papenberg]

Hi folks,
I'd like to put another question here: Should the css (and js and
images) be in the /templates folder at all? We have the media folder,
which actually is meant to hold all non-content media files, but so far
no template that I came across is using that folder. Instead everyone is
putting their stuff in the templates folder, which requires that folder
to be web-accessible. At one point in time, Joomla strived to make it
possible to move all PHP files outside of the webroot. If template
developers would use the media folder, that would actually be possible.
It would also allow to use JHtml::_('stylesheet') in the templates
instead of hardcoding the stuff into the index.php somewhere.

Hannes

Am 10.06.2013 14:57, schrieb Matt Thomas:
> Agreed. This is the approach that I've used with Construct for years
> now and it's simple, easy to use and understand. Best of all, it
> survives upgrades.
>
> Best,
>
> Matt Thomas

> Founder betweenbrain <http://betweenbrain.com/>�

> Lead Developer Construct Template Development Framework

> <http://construct-framework.com/>

> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>
>
> On Mon, Jun 10, 2013 at 8:51 AM, Fotis Evangelou <fevan...@gmail.com

> <mailto:fevan...@gmail.com>> wrote:
>
> We launched our new template club nuevvo.com <http://nuevvo.com>

> on June 7 and the use of a custom.css file is one of the features
> of our templates - so we can make updating easier. It doesn't even
> require a Joomla! core change, just make template designers adopt
> this as a simple pattern.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Matt Thomas]

@Chad, looking at the code, yes it should survive switching templates altogether.

@Hannes, +1 :D

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Michael Babker]

There's other reasons to use the media folder too, a bit of which Hannes eluded too.  After discovering this madness and not realizing Hannes implemented it into JHtml back at 1.6, I wrote about it: http://www.babdev.com/blog/139-use-the-media-folder-allow-overridable-media

If everyone (template and component devs) used the media folder, all media would be overridable (dangerous thought I know) and proposals like the one for this thread would be an afterthought.

[Ove]

Yes,
I'm pretty sure I got the code I'm using from Construct

Thanks Matt

.

[Tobias Zulauf]

@all: Thank You very much for your comments!

@Chad Windnagle

> I believe the thought behind this is by adding it to core the custom.css overrides not only survive template upgrades by also survive switching templates altogether, right?

Yes. At the template.css e.g. from the core templates the JBS work often i think and with this feature the user can overwrite this file (and other css files) so you can make changes without worry about Joomla Updates.

I heared from a lot of users that don't update there Joomla, because of some updates for the used core template (css) files.

@Fotis Evangelou

> and the use of a custom.css file is one of the features of our templates

I can limited the plugin for the core templates but I think if we add this feature to the Joomla core all templates have this feature and this is better than limited this for the core templates.

Regards,
Tobias

[Bakual]

I don't know if this has to be in the core. If you have a working plugin, it can be put on JED and those who need it can simply install and use it like with any other extension.

 

There are various solutions how this particular problem can be solved. Your plugin is a nice one, but only one of them. Some template developers decide to include a template parameter which allows to specify some custom CSS rules. Some decide they check for a custom.css file themself.

[Bakual]

Actually it doesn't survive template upgrades in any case. If the templates uses <file> tags and not <folder>, then the custom.css file will be deleted on an update.

Am Montag, 10. Juni 2013 15:00:18 UTC+2 schrieb Chad Windnagle:

I believe the thought behind this is by adding it to core the custom.css overrides not only survive template upgrades by also survive switching templates altogether, right? 

On Monday, June 10, 2013, Matt Thomas wrote:

Agreed. This is the approach that I've used with Construct for years now and it's simple, easy to use and understand. Best of all, it survives upgrades.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Mon, Jun 10, 2013 at 8:51 AM, Fotis Evangelou <fevan...@gmail.com> wrote:

We launched our new template club nuevvo.com on June 7 and the use of a custom.css file is one of the features of our templates - so we can make updating easier. It doesn't even require a Joomla! core change, just make template designers adopt this as a simple pattern.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bakual]

Currently, com_templates checks the templates CSS folder for CSS files and offers links to edit them in the backend. If you moved the CSS files to the media folder, then this feature would no longer work.

I think that is an important reason why the files are still in the template folder :-)

[JM Simonet]

For those interested, I indeed made a specific plugin which is RTL and LTR aware, specially to get in TinyMCE a custom.css depending on direction.
It needs an url though, therefore the css files can be anywhere.

See:
http://extensions.joomla.org/extensions/style-a-design/templating/20389

JM

-- 

Merci de ne pas renvoyer de pièces attachées automatiquement.

------------------

Jean-Marie Simonet/infograf

info...@orange.fr

http://www.info-graf.fr

[Troy]

as JM mentioned he made a nice plugin, I took his and explanded upon it as shown here http://extensions.joomla.org/extensions/style-a-design/templating/21408

Bear

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6401 - Release Date: 06/11/13

[Lintzy]

If it is wanted to get a custom.css to core templates, why don't integrate it into core templates directly?

Something like this:

$doc->addStyleSheet(JURI::base() . 'templates/' . $this->template . '/css/custom.css', $type = 'text/css', $media = 'screen,projection');

and add an empty custom.css into the css folder.

To avoid an override of this custom.css if the core template becomes updated, there should be also a small php if query (if exists, do nothing, if not, add custom.css)

[Bakual]

You can also just do the if in the template and check if file exist and only load custom.css if it exists. Otherwise you load an empty file by default which is bad.

[Lintzy]

Yes, Bakual- something like that. And in addition a parameter, that asks the user, if he wants a custom.css. If he does not want so, this way it avoids an useless http request.

[Troy]

Thats almost exactly what I did on the template I'm currently designing.
// Load optional custom CSS
if($this->params->get('customcss') ) $doc->addStyleSheet('templates/' . $this->template . '/css/custom.css');
and then I added
                <field name="customcss"
                    type="radio"
                    class="btn-group"
                    default="1"
                    filter="integer"
                    label="TPL_JOWGRADIENT_CUSTOMCSS_LABEL"
                    description="TPL_JOWGRADIENT_CUSTOMCSS_DESC">
                   
                    <option value="0">JNO</option>
                    <option value="1">JYES</option>
                </field>
to the templateDetails.xml

Bear

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.3345 / Virus Database: 3199/6413 - Release Date: 06/15/13

[Bakual]

Either do it with a parameter like Bear described, then you check against the parameter and not against the file existance. Or you do it without parameter and just check if the file exists, if it exists it's loaded.

Both ways will work and don't generate any problems with updating.

 

You can also have a parameter which directly stores custom CSS rules in a textfield and then just include this parameter directly.

 

 <?php if ($params->get('customCssCode')) : ?>
  <style type="text/css"><?php echo htmlspecialchars($params->get('customCssCode')); ?></style>
 <?php endif;

Personally I prefer this approach as the users don't have to fiddle with files on the server. Just fill the custom rules into the template parameters and it will work.

[Lintzy]

Hello Bear,
thanks for sharing. That is exactly, what I conceived. Suppose that would be integrated into index.php and templateDetails.xml of the core templates, the custom.css would not be overwritten by a (template)update?

[Rouven Weßling]

First props for including the necessary call to htmlspecialchars to not create an XSS vector - too many don't do that.

However it should be mentioned that the downside of this approach - if we talk about bigger modifications - is that it's not great for performance. Not only increases it the transfer to between the database and the PHP installation it also increases the size of ever single HTML document served. 

For smaller modifications that doesn't matter but it's something to keep in mind.

Best regards

Rouven

--

[Troy]

RIGHT, because #1 there is no "custom.css" in the template by default.... infact, we could add a "touch" function so that if its selected and it don't exist its created.... good idea...

Bear

[Troy]

Rouven should it be included in this case?

Bear

No virus found in this message.

Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6413 - Release Date: 06/15/13

--

[Troy]

2 other thoughts,,
#1 its important that this file be called last else other will override ( like bootstrap )
#2 the check for custom.css should be done @ template install/update so that we're not performing countless checks with each page load.
on save it can do a check against if param and if !exist.
I hope this makes sense.

Bear

No virus found in this message.

Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6413 - Release Date: 06/15/13

--

[Bakual]

I'm not sure the file_exists check is such a problem. Joomla does countless such checks during each pageload to check for overrides, one more will probably not slow down the page. :-)

[Hannes Papenberg]

The question is, if we REALLY need this as a core feature. Right now I
fear we are going more and more towards being the emacs of web CMS. Yes,
we can do everything with it and you don't even really need to code
anything because everything is an option. But it is still an absolute
overkill.
I would vote for making this an extension, so that people can install it
when necessary. In my case for example, I'm working almost exclusively
with self-written templates. I don't need this feature at all. And even
if we include this, I already know that there will be a template
framework that goes around this feature since it's "not flexible enough".

Hannes

Am 16.06.2013 10:39, schrieb Bakual:
> I'm not sure the file_exists check is such a problem. Joomla does
> countless such checks during each pageload to check for overrides, one
> more will probably not slow down the page. :-)
>
> Am Sonntag, 16. Juni 2013 02:09:36 UTC+2 schrieb Bear:
>
> 2 other thoughts,,
> #1 its important that this file be called last else other will
> override ( like bootstrap )
> #2 the check for custom.css should be done @ template
> install/update so that we're not performing countless checks with
> each page load.
> on save it can do a check against if param and if !exist.
> I hope this makes sense.
> Bear

> On 6/15/2013 5:46 PM, Rouven We�ling wrote:
>> First props for including the necessary call to htmlspecialchars
>> to not create an XSS vector - too many don't do that.
>>
>> However it should be mentioned that the downside of this approach
>> - if we talk about bigger modifications - is that it's not great
>> for performance. Not only increases it the transfer to between
>> the database and the PHP installation it also increases the size
>> of ever single HTML document served.
>>
>> For smaller modifications that doesn't matter but it's something
>> to keep in mind.
>>
>> Best regards
>> Rouven
>>
>> On 15.06.2013, at 21:36, Bakual <werbe...@bakual.ch

>> <javascript:>> wrote:
>>
>>> Either do it with a parameter like Bear described, then you
>>> check against the parameter and not against the file existance.
>>> Or you do it without parameter and just check if the file
>>> exists, if it exists it's loaded.
>>> Both ways will work and don't generate any problems with updating.
>>>
>>> You can also have a parameter which directly stores custom CSS
>>> rules in a textfield and then just include this parameter directly.
>>>
>>> <?php if ($params->get('customCssCode')) : ?>
>>> <style type="text/css"><?php echo
>>> htmlspecialchars($params->get('customCssCode')); ?></style>
>>> <?php endif;
>>> Personally I prefer this approach as the users don't have to
>>> fiddle with files on the server. Just fill the custom rules into
>>> the template parameters and it will work.
>>>
>>> Am Samstag, 15. Juni 2013 20:45:52 UTC+2 schrieb Lintzy:
>>>
>>> Yes, Bakual- something like that. And in addition a
>>> parameter, that asks the user, if he wants a custom.css. If
>>> he does not want so, this way it avoids an useless http request.
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "Joomla! CMS Development" group.
>>> To unsubscribe from this group and stop receiving emails from
>>> it, send an email to joomla-dev-cm...@googlegroups.com

>>> <javascript:>.

>>> To post to this group, send an email to

>>> joomla-...@googlegroups.com <javascript:>.

>>> Visit this group at
>>> http://groups.google.com/group/joomla-dev-cms

>>> <http://groups.google.com/group/joomla-dev-cms>.

>>> For more options, visit https://groups.google.com/groups/opt_out

>>> <https://groups.google.com/groups/opt_out>.

>>>
>>>
>>
>> No virus found in this message.

>> Checked by AVG - www.avg.com <http://www.avg.com>

>> Version: 2013.0.3345 / Virus Database: 3199/6413 - Release Date:
>> 06/15/13
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "Joomla! CMS Development" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to joomla-dev-cm...@googlegroups.com <javascript:>.

>> To post to this group, send an email to

>> joomla-...@googlegroups.com <javascript:>.

>> Visit this group at http://groups.google.com/group/joomla-dev-cms

>> <http://groups.google.com/group/joomla-dev-cms>.

>> For more options, visit https://groups.google.com/groups/opt_out

>> <https://groups.google.com/groups/opt_out>.

[Matt Thomas]

I tend to agree with Hannes. We need to ask ourselves if we need yet another features in core. It's nothing against this feature, but the #1 complaint I hear from clients is that the sheer number of configuration options in core is overwhelming.

In my opinion, we need to gather accurate data on what is being used, and if it doesn't meet the 80% rule, we need to get it out of core. Of course, that's just my opinion.

If it does get included, it should be implemented as a plugin, disabled by default.

Best,

Matt Thomas
Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

[Bakual]

It's already poosible to solve it using a plugin or by using various approachs in the template. I sure think it doesn't need a solution in the core.

[Micheas Herman]

One thing not mentioned is that a lot of people lose their customizations when they get a security upgrade.

The edit your template css from within the browser should probably be replaced with this feature.

Although this feature needs extended to do that much.

There are a lot of vulnerable joomla sites out there that cannot easily be upgraded because there has been lots of time spent customizing the site from within the admin section of the site.

personally I would favor /media/templates/[template_name]/custom.css as the location for the file. 

An alternative could be for Joomla to aggregate all the css files into one file and load the overrides instead of the core template css if it finds an override file of the same name.

This would require a small change to the way <head></head> is generated by designers, unless the <head> tag is parsed for local css files.

Just a couple of thoughts.

[Hannes Papenberg]

I would rather prefer if we were to invest into an SCSS compiler and encourage template devs to use that instead of introducing yet another css file... correctly used, that would solve the issue that you are describing.

I'm sorry, but I doubt that people will use this feature properly. Either they are experienced enough and add their custom.css file anyway by hand, or (the vast majority) they don't have a real clue about the cascading part of css and are only able to see the property in firebug, read the line number and edit it in that file then and there.

Hannes

--

[Bakual]

I wrote a plugin for a template project which creates a single CSS file from LESS files after the template parameters are saved, using those parameters to fill LESS variables. It's quite nice already and since it does the job after parameter saving ("onExtensionAfterSave" event in context "com_templates.style"), it has no impact on a pageload. This could probably improved even further to also include a custom.css file or so. At the moment it's more a proof of concept.

Code would be here: https://github.com/Bakual/Allrounder/tree/master/plg_lessallrounder

[Michael Babker]

We have a GSoC project for this summer to improve the template manager.  IIRC, one of the topics in the proposal was to be able to compile LESS files via the admin UI.  The official start of code work for GSoC is this week, so I'd expect to see that come together over the next few weeks.

As with last year, the code will be on GitHub.  Look for it to start showing up at https://github.com/joomla-projects/joomla-cms/tree/gsoc-template-manager as Ram works on it, and feel free to provide feedback as well.

[Bakual]

This sounds interesting :)

[Micheas Herman]

On Sunday, June 16, 2013 9:50:29 AM UTC-7, Hannes Papenberg wrote:

I would rather prefer if we were to invest into an SCSS compiler and encourage template devs to use that instead of introducing yet another css file... correctly used, that would solve the issue that you are describing.

Especially if the precompiler was extended to do smart selection of .less files. http://leafo.net/lessphp/ seems to be close to supporting bootstrap, so It might not be that big of a coding challenge. (architecturally and politically this looks like it could be the subject of vigorous debate.)

 

I'm sorry, but I doubt that people will use this feature properly. Either they are experienced enough and add their custom.css file anyway by hand, or (the vast majority) they don't have a real clue about the cascading part of css and are only able to see the property in firebug, read the line number and edit it in that file then and there.

Lately my experience has been slightly different form of not getting css. What I have noticed mostly is that people create a super specific override like: body.js div.content div.main .class1.class2.class3 ul.class4 li.class5 a.class6:active { color:red} 

To support what you are saying I have spent a fair amount of time renaming the beez template so I can upgrade a hacked site. So, there is a group of people that do exactly what you are describing.

Personally, I think an aggregation of "things that people try doing to customize a joomla website" would be a good list to have someplace while figuring out how to encourage people to do the right thing when customizing a template.
 

[Bakual]

Just a note: lessphp is the compiler we already use to generate the CSS file for the core templates.

[tr...@hallhome.us]

isn't SCSS the same basic function as LESS?
if so then why embrace yet another compiler especially considering we're
using bootstrap heavily.

[tr...@hallhome.us]

if you could update that to process the "custom.css' last that would be
fantastic.
I'd be very interested in seeing that.

[tr...@hallhome.us]

@Hannes The extension I wrote
http://extensions.joomla.org/extensions/style-a-design/templating/21408
does that and MUCH more, and is very very flexible, so there are plenty of
"extensions" that do this. The point of this topic is that it would be
nice to have a BASIC core feature that does this... embracing the LESS
recompile is even better IMO, though it should be able to be disabled. I
could provide a template I'm working on that does most of this.
Bear

[Hannes Papenberg]

I prefer SCSS over Less, since SCSS has Compass sitting on top of it and
that REALLY helps in developing cool CSS. I dislike LESS especially,
since its roots are in parsing via JS, which makes the whole user
experience unpleasant and generates more load for both my server and my
client than outputting CSS directly like SCSS does. Yes, I know that
LESS also allows to pre-compile the stuff, but people are stupid and
most of the time aren't even aware that there is a problem with sending
uncompiled LESS + the JS compiler over the line. Last but not least, the
minified CSS most of the time is not really (that much) bigger than the
uncompiled LESS and most of the time, the overhead of loading two files
results in more delay than the direct loading of the compiled CSS.

<Begin rant>
That last part from my POV is the biggest issue in webdesign lately.
People tend to include a file here, a file there and without really
noticing it, you got a (few) hundred dependencies that are all loaded
individually. Each file is really small and every single one of those
projects that maintain these dependencies are proud that their code fits
in less than 3 kb. However, the request takes at least one IP packet to
the server and if you have maybe 50 dependencies (10 css files, 5 JS
shims for IE, 5 effect JS files, Mootools, JQuery, 20 images, some ajax
content, fonts) you have 50 IP packets that could have been largely
reduced by combining the CSS and JS into one file each. And no, its not
a good solution to do this on the fly by Joomla. :P
<End of rant>
Sorry, count that as a little blackout. ;-)

There is a SCSS version of Bootstrap available.

Hannes

[Bear]

Someone informed me the link wasn't working but it is now.

[Matt Thomas]

+1 for SCSS

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Bakual]

The joy of Joomla - always changing the proposed standards to follow :-D

[Troy Hall]

hehehe which is why I said if we're going to do LESS then LESS if SCSS then SCSS but not topsy-turvy

Bear

[piotr_cz]

I think you are a little bit wrong here.

Client-side LESS is great for development (FireLESS browser add-on),

for production you just compile all files into template.css (great tool is Less Compiler Plugin).

I haven't seen the LESS client-side compilation on any live site, it's an absurd idea.

I've read that SCSS/ Sass is much more powerful, but there are some downsides in using it Joomla:

• PHP version of the compiler is quite behind native Ruby version.
  
• Bootstrap is using LESS. Sass versions are unofficial ports

[Andreas Tasch]

Hi,

thanks piotr_cz for pointing to the plugin and your client-side debugging feature.

@hackwar

As piotr_cz already said there is no need to compile the .css on the client side as lessphp precompiles it (with caching, so only when .less files change). This plugin can be used during development and I recommend disabling it on production site until you change your .less files again (no need to waste ressources).

@all

I already started a thread on platform list last year regarding a LESS compiler library for Joomla! - but unfortunately got no response. My main question is where to put the external lessphp library - I would assume that we can use the JMail package as boilerplate but I'm not sure if this is the correct way.

Why a library for J!?

As J! sticks with bootstrap and LESS files it would be great to let Joomla! compile .less files on demand. So e.g. we have an sitewide option on templates to 

a) automatically compile templates .less files (works similar as the plugin)

b) a api where template devs can embed a "compile LESS files now" button

During development this is really helpful to have the .less files compiled. What do you guys think - can we get it started?

Regarding custom.css:

I think if we really use the power of LESS there is maybe no need for a custom.css. IMHO a custom.css is against the idea of the whole CSS evolution LESS introduced. A little bit more sense makes maybe a custom.less which is included in the main template.less -> so that it gets parsed by the less compiler and optimized and minified.

[Andreas Tasch]

An addition to "Why J! library":

Almost all template clubs have now their own implementation of the lessphp class to compile their less files. This already resulted in an class error between the plugin and t3v3 framework. So obviously many template clubs use the lessphp compiler - why not integrate it into joomla to make it less painful for all template developers - and let all enjoy the new possibilities offered by LESS 

[elin]

Exactly, some things are needed for interoperability not to mention that people should be empowered to control their own websites, currently quite difficult since you have to go to the file system even to add a precompiled package you download from the bootstrap site or bootswatch.

One thing I'd point out is that we have for quite some time had an  actual copy function for templates which means that never should you modify a core template, you should only modify a copy. Then you don't have to worry about having your work ruined by an update That means you do have to watch for security issues in the core templates that you've copied but those are few and far between. 

Elin

[Troy Hall]

Bear

On Jun 21, 2013, at 4:01 AM, Andreas Tasch wrote:

Hi,

thanks piotr_cz for pointing to the plugin and your client-side debugging feature.

@hackwar

As piotr_cz already said there is no need to compile the .css on the client side as lessphp precompiles it (with caching, so only when .less files change). This plugin can be used during development and I recommend disabling it on production site until you change your .less files again (no need to waste ressources).

because of the caching ( i assume ) I noticed it doesn't work for dev if you've got custom.css as it doesn't pull that data in. ( try it on the default protostar template with something in the .css, Also because its cached no future changes to .css will show up *facepalm*

I can't help but wonder why not use the cli compiler but from within the template?

@all

I already started a thread on platform list last year regarding a LESS compiler library for Joomla! - but unfortunately got no response. My main question is where to put the external lessphp library - I would assume that we can use the JMail package as boilerplate but I'm not sure if this is the correct way.

Why a library for J!?

As J! sticks with bootstrap and LESS files it would be great to let Joomla! compile .less files on demand. So e.g. we have an sitewide option on templates to 

a) automatically compile templates .less files (works similar as the plugin)

b) a api where template devs can embed a "compile LESS files now" button

During development this is really helpful to have the .less files compiled. What do you guys think - can we get it started?

+1

Regarding custom.css:

I think if we really use the power of LESS there is maybe no need for a custom.css. IMHO a custom.css is against the idea of the whole CSS evolution LESS introduced. A little bit more sense makes maybe a custom.less which is included in the main template.less -> so that it gets parsed by the less compiler and optimized and minified.

I have to disagree here.  What if I have modules that I need to "tweak"  custom.css is perfect for that. and IMO is where it should be.  Anything else would possibly cause conflicts/failure on updates.

Bear

[Troy Hall]

+1

Bear

[Troy Hall]

On Jun 21, 2013, at 6:02 PM, elin wrote:

Exactly, some things are needed for interoperability not to mention that people should be empowered to control their own websites, currently quite difficult since you have to go to the file system even to add a precompiled package you download from the bootstrap site or bootswatch.

One thing I'd point out is that we have for quite some time had an  actual copy function for templates which means that never should you modify a core template, you should only modify a copy. Then you don't have to worry about having your work ruined by an update That means you do have to watch for security issues in the core templates that you've copied but those are few and far between. 

Elin

I've been working on this very thing for quite some time now, yes I'm horrendously slow,   and its allowing me to create quite a unique piece rather simply.  As Elin encouraged me to do, I'm going to try to rework my .css into LESS but while I'm developing I'm not smart enough to do so on the fly and the plugin doesn't allow me to continue using the custom.css while I do so.  I'm not very bright so I probably won't succeed in COMPLETELY putting everything into LESS so i'll definitely need my custom.css to make everything function.  infact, for me peronsally I due things probably dumb as the first few lines in my custom.css are

@import "modules.css";

@import "components.css";

@import "articles.css";

/*

  * ITS IMPORTANT THE ABOVE 3 IMPORTS BE FIRST IN ORDER

  * FOR THEM TO PROPERLY LOAD THE STYLES

  *

  * I recommend you put your individual overrides in those files

  * and leave this for global overrides

  * optionally you may remove them and only this sheet will be used.

  *

This allows me to keep my overrides organized and easy to find/remove as time goes by.  One key feature I noticed in doing those, is all the .css files are individually editable in the template admin.  The ability to hit "recompile" there would just be icing on the cake.

afaik J! is about simplistic individualism and the code we're talking about adding is extremely miniscule so I'm really kind surprised @ the resistance.

I know my voice ain't worth much but since I've been involved since Mambo days I feel I've earned the right to jump on my soap box now and then...

Bear

 /me steps off soap box.

[Bakual]

It doesn't make a difference if you put your custom rules into a custom.css or into a custom.less. Only that with the latter you only get one file and can use mixings, guards and whatever LESS offers. Custom.less would be superiour to custom.css

[Andreas Tasch]

Hi Bear,

sorry if I did not understand your concerns correctly - as I'm no native English speaker. If your issue is how to include your custom .css files into .less it is quite easy.

The main .less file and starting point in protostar is in /templates/protostar/less/template.less. If you open that file you will find many @imports in this file - imports from many different places. And they do exactly what you do with your .css files. 

Option 1: import your .css as .less files (a little bit work but worth it, imho)

Now lets assume you want to include your custom files and get them parsed by LESS compiler - you do NOT need to rewrite your .css to LESS because plain .css works as well. The only thing you have to do is to rename your .css files to .less and add an @import statement into above mentioned main /templates/protostar/less/template.less

I assume you put your custom .css files renamed to .less into the /templates/protostar/less folder. Now you open /templates/protostar/less/template.less and at the bottom of the file you import your custom .less files so that they override existing declarations:

@import "modules.less";

@import "components.less";

@import "articles.less";

If you now compile your main template.less file you end up with one main template.css optimized and minified (if you wish). You also reduced your http requests and the site should load faster. Now you can start step by step in your custom.less files to use less variables and other cool stuff http://lesscss.org has to offer. 

Option 2: just import your .css / does not work for overriding

In /templates/protostar/less/template.less just import your .css files and they will be included as imports into main template.css:

@import "../css/modules.css";

@import "../css/components.css";

@import "../css/articles.css";

But this way you do not get any optimization. And a big issue is that this import is always on top before other declarations - so you can't override an existing declaration.

More information: http://lesscss.org/#usage (Section Importing)

[brian teeman]

Thanks for that Andreas its all beginning to make sense now.

[elin]

Andreas,

It would be great if you (or someone) would put that explanation in the wiki, it is really clear.

Elin

[tr...@hallhome.us]

Andreas TYVM!!! you saved me countless hours of research and work!!
of course my ultimate goal would be to use the vars like you said for main
template stuff.
one question I have and I'm fairly sure I know the answer to, is when I do
the less compile , if in the template.less it has
.site {
color : red;
}

near the top
and then in my custom.css i have
.site {
color: blue;
}
when it "compiles" does it replace red with blue? Or does it simply
create another entry further down.
I'm ASSUMING it behaves like the computed styles function in element
inspector.
Bear

[piotr_cz]

+1 on LESS as a Joomla library.

I think you should prepare pull request, Andreas.

There is an article on magzine.joomla.org: Tools To Do LESS but IMO manual compiling on local machine/ trough CLI is more work and LESS fun.

Having a library will make Joomla closer to automated compilers, like your plugin.

As for custom.css, this might be really helpful for club template users that don't want to change it's index.php because of updates or don't know how to.

I think we are not getting too much response from such users here, as we are more or less advanced on this group.

[Bakual]

My plugin now takes care of /less/custom.less and /css/custom.css files if present. :-)

 

If you want to test this, be aware that it's meant to be part of a template. It will not work as a standalone plugin as it is.

The main reason is that the generated CSS file includes the style id (eg template9.css). Since you can use template parameters in your LESS files, the generated CSS file is different depending on the template style. The template will then need to load the correct file depending on active style.

Also the template needs a parameter named "useLESS" which has to be other than zero, otherwise the plugin will just skip to avoid issues with templates that don't need it :-)

The template may also have a parameter named "cssCompress" which will generate a minimised output if enabled.

 

https://github.com/Bakual/Allrounder has also a template in it which shows what you could do with the "lessphp" compiler and Joomla. It's a fork from the "Allrounder" template from lernvid.com which I took because it has so many template parameters :-)

[George Wilson]

Just remember that FOF has it's own LESS compiler - so there may be one coming in anyhow with that.

Kind Regards,

George

[Bakual]

I don't know which one FoF uses. Andreas and I use the one which is also used by Joomla to build the Protostar and Isis template.css. So I'd think the RAD layer should use this one as well, if there is one to be included.

[Michael Babker]

The one in core is just lessphp with a wrapper to define a consistent style rule for the CSS files so that each person wasn't potentially running a different compiler with different code style.  See https://github.com/joomla/joomla-cms/blob/master/build/libraries/less/less.php and https://github.com/joomla/joomla-cms/blob/master/build/libraries/less/formatter/joomla.php.

There was a thought of one day building out that JLess class properly (what else it would need, I don't know) and distributing the CMS with it and lessphp included, I just have no idea what happened to that thought.

On Sun, Jun 23, 2013 at 1:21 AM, Bakual <werbe...@bakual.ch> wrote:

I don't know which one FoF uses. Andreas and I use the one which is also used by Joomla to build the Protostar and Isis template.css. So I'd think the RAD layer should use this one as well, if there is one to be included.

[Bakual]

It would probably be a good step to include this files into the shipped core. Currently they are only used to build the package but not part of it.

[George Wilson]

On Sunday, June 23, 2013 7:21:11 AM UTC+1, Michael Babker wrote: 

I don't know which one FoF uses.

https://github.com/akeeba/fof/blob/development/fof/less/less.php

The source for the FOF one is listed in this file here as part of the FOF Less class. Perhaps rather than putting that LESS class into the RAD Layer it could become the basis for a JLess class (I guess the RAD group would also need to be consulted on this???) 

On Sunday, June 23, 2013 8:09:11 AM UTC+1, Michael Babker wrote:

There was a thought of one day building out that JLess class properly (what else it would need, I don't know) and distributing the CMS with it and lessphp included, I just have no idea what happened to that thought.

I think that there was going to be a LESS compiler in the GSOC Template Manager project. Not sure if someone could confirm that? But as to whether it was going to be a generic JLess class or if it was just going to in the Template Manager I don't know.

[Bakual]

As far as it looks, FoF has the same less compiler (lessphp from http://leafo.net/lessphp) included. Only that it's an outdated version (0.3.8 instead of 0.3.9) and that Nic changed the name of the class to FOFLess and did some code styling. Maybe he did change something else, but it's not marked with **FOF** like the header would say.

 

So I would vote to just include the compiler as it is. Changing class names only to change classnames doesn't make much sense to me. I guess it was needed for the FoF Autoloader or something like that.

 

At the end it hasn't much to do with RAD itself. It's a (very small) library we already use to build the core and which could easily just included into the core so other extensions could use it. On the other hand it doesn't matter much if every extensions ships their own version since it's so small (~85KB) :-)

[George Wilson]

Yup know its out of date: https://github.com/akeeba/fof/issues/71 already working on it :) The other thing he's changed is that in places it uses JFile and JLoader (see an example here: https://github.com/akeeba/fof/issues/71).

Perhaps we should talk with Nick about whether (once the 0.39 update has been done) we can change FOFLess to JLess and use this as a new class? Means the majority of work is already done. Also chat with the template manager GSOC project as well - as I said - not sure what their doing

Kind Regards,

George

[Michael Babker]

The difference between Nicholas' approach in FOF and the CMS approach is that FOF took the lessc class and renamed it and made his changes directly to it while the CMS added a wrapper.  Might have to do with their uses too (one's used in production, the other only in development).

--

[Andreas Tasch]

Hi Elin, 

I added it - slightly rewritten - to the existing LESS entry in the wiki http://docs.joomla.org/Joomla_LESS

[brian teeman]

Thank you evry much Andreas

[Andreas Tasch]

Hi Bear, 

both .site {} definitions get added and the last one overwrites the ones before. Therefore I suggested to add your custom.less import on the bottom of the template.less. But you could make use of LESS variables to define a color, e.g. @myColor: #CC0000; then you can use it everywhere in your template e.g. .site { color: @myColor } 

[Andreas Tasch]

Regarding which less compiler implementation to use: 

All of them I know are based on lessphp (template clubs, FOF, build-script, less compiler plugin,..). For me this is really a strong sign that such a compiler is missing in the core. We should wrap lessphp into our own JLess (as with phpmailer and JMail) so that we can easily update lessphp if a new version arrives. (imho rewriting lessphp to Joomla or other class names as FOF does is not that practical as you have to rework it each time a new version of lessphp is out instead of just replacing the file - but I'm not striktly against the idea to put it into FoF - the core or the framework just feels like a better place for it). This way FOF, template clubs plugin, build script and my plugin can all use the JLess class to do the work. Thinking further template clubs and default templates can have a button to compile .less files on demand or automatically on page reload. 

Regarding lessphp:

Out of the tags on github new releases take usually 5 to 9 month. On the github repo there are already fixes for some nasty bugs (e.g. mixins classname crash) and some useful pull requests  and a lot of open issues - but the maintainer does not want or has no time to tag releases more frequently. So we may want to backport some of these. See https://github.com/leafo/lessphp

But I think we agree that we do not want to make our own less compiler library from scratch :D

[tr...@hallhome.us]

ah, thats simple enough.. course the best thing would be to make sure I
put it in the template.less itself and use custom only for custom stuff
I'm fairly sure.
Bear

>> > email to joomla-dev-cm...@googlegroups.com <javascript:>.

>> > To post to this group, send an email to

>> joomla-...@googlegroups.com<javascript:>.

[Seth Warburton]

Personally, I'm against a LESS compiler in core. Any dev capable of working with LESS is also quite capable of choosing a compiler that fits their needs, and then configuring it to their own preferences. 

I've spent a good bit of time today disabling the compiler built into a popular framework, as it was killing my MAMP server. Worse, it was compiling even though the source files contained errors, and with no warnings.

Pre-processors are great, provided you know how to use them correctly (like nail guns). Like nail guns, putting them in the hands of the inexperienced just delivers disaster faster. I can't help but think that an automatic compiler would be like putting a nail gun into the hands of someone wearing a blindfold. It'll be carnage.

[Andreas Tasch]

Hi Seth,

I agree that the CMS/Framework should never compile automatically less files. The compiler should only do this after enabled by the developer during development or on occasional updates on the site or by clicking a button in the backend template view. I'm no hardcore template developer but I found it too work intensive to copy & paste the less output all the time between the desktop LESS compiler (simpless) and the resulting .css What is more, on a remote webserver you have to copy files around for each small update. By default the compiler should be disabled. I doubt many devs have a deployment process in place which compiles and moves the files on production machines.

On the other hand many template clubs or their underlying frameworks ship their own compilers based on lessphp with their bootstrap templates (t3-framework, gantry, soon yootheme?). They use twitter bootstrap with all features, including benefits of LESS. But each of them installs their own plugin with lessphp included. I wonder why all template clubs do the same thing for theirself instead of putting heads together and contribute a unified solution to Joomla! ;-)

I have no proof but it feels like most people today, even on bootstrap templates, just edit the template.css. If we say twitter bootstrap is the default Joomla! template way to go we should also offer the evolution LESS (or likewise SASS) introduced for CSS. Having bootstrap in place and editing the resulting template.css is imho the wrong way. Eg. the template.css in protostar could be minified and compressed out of the box to speed up load times but it sits there fully commented and with no optimization. I agree that it may take some time and education until we can deliver a optimized template.css with default templates (maybe 4.0? :) )

As mentioned for me LESS/SASS is the evolution of CSS
+ use of variables, mixins, operations and functions to write less CSS

additional benefits:

+ you can structure your template into multiple .less files (as jui/bootstrap does) but get 1 file out of that, results in

    + fewer http requests

    + faster load time

+ you can comment .less files but strip it out on the resulting .css 

+ out of the box compression+minification (if you want)

I have not completely thought through it but if there is a JLess class, extension developers may also benefit from it

But I agree with your concerns that people with little knowledge even to CSS who know only how to change colors, font-families and dimensions will may have troubles with .less. On the other hand, change is the only constant and we all have to learn new things all the time :) So, we should have really guides and documentation and also the option to not use it - so that they always can edit their template.css.

[piotr_cz]

I understand your concerns, but I think you are wrong here.

Adding LESS compiler as Joomla library will minimally affect Joomla users, but may help extension developers (we are not talking here about the autocompile option/ feature)

Remember the hassle of adding jQuery to Joomla before 3.0? Everybody was adding different version and doing it different way.

I'd rather compare it to giving ammo to users, but without a gun.

I'm kinda surprised that popular framework doesn't have an option to turn precompiling off.

[Bakual]

Maybe Joomla needs a way for the templates to process parameters after they are saved. Currently we are quite limited here for what we can do with com_templates. If com_templates would call a class/method within the template (if present) after the style parameters are saved, then that would probably help as well. Or if we could add additional functions to the com_template manage view, like a button to compile the LESS files or create/edit a custom.css file. Currently we are just stuck with what com_templates offers and if you want to do more, you need a template framework.

[Hannes Papenberg]

If you start down that lane, you wanna have a generalized event
onBeforeParameterSave and onAfterParameterSave and we got that already
in most extensions with the onBeforeContentSave stuff. Granted, it would
require that a template always be shipped with a plugin to attach itself
to this, but WHEN we introduce something like this, please don't invent
yet something new for something that we already have in the core. It's
bad enough that we had 20 solutions for 1 problem in Joomla in the past
(and we still have some instances of those) please don't make it worse
by introducing some magic classes for templates.

Hannes

Am 26.06.2013 15:08, schrieb Bakual:
> Maybe Joomla needs a way for the templates to process parameters

> *after* they are saved. Currently we are quite limited here for what

[Bakual]

We already have this events for template parameters. But it sounds a bit wrong to me to ship a template together with a system plugin only so it can do some postsave processing like compiling LESS files or parameters.

[Seth Warburton]

I'm not against LESS (though I much prefer Sass), I'm against adding a compiler to Joomla's core. I don't think it should be possible to edit LESS files within Joomla, so I don't think we should include any compiler. 

I don't think anyone would consider implementing a basic IDE *within joomla* to allow people to edit .php files from within the CMS (for the same reason I don't want to see a LESS compiler), so why do that for LESS? We're not recommending people edit files via FTP on a live server now are we?

When you want to work on a live site you should have to copy your local changes there, this is a good thing. There is no ctrl+z on a live server. When working locally you can simply have your compiler watch the LESS folder in your localhost environment and output the .css to the templates css folder, no copy/paste required. Crucially though, the compiler isn't using the resources of the local server and there's an undo option available.

Put simply, I can't see any good reason to include a compiler in Joomla, but I can see plenty of reasons why we shouldn't.

[Bakual]

Just saying: We already have a built-in editor for CSS files and for the index.php. Why not for LESS files? :)

[George Wilson]

I believe (but not 100% about this) that the GSOC template manager project will be adding in a LESS editor/compiler http://docs.joomla.org/GSOC_2013_Project_Ideas#Project:_Improvements_to_Template_Manager_for_CMS_3 we should be checking what's going on there I guess as well!

Kind Regards,

George

On 27 June 2013 12:46, Bakual <werbe...@bakual.ch> wrote:

Just saying: We already have a built-in editor for CSS files and for the index.php. Why not for LESS files? :)

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/jo5pFTx4gpE/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Andreas Tasch]

@George

thanks for the hint, I searched a bit around and found the corresponding thread on joomla gsoc 2013 group:

https://groups.google.com/forum/#!topic/joomla-gsoc-2013/pVRSzaUBpyI

There you find the proposal/timeline of Aleks:

https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/aleks_linya/1

Seems that editing less files and therefore a less compiler is part of the project.

In his github repo he uses lessphp from build/, so he did not implement the library yet 

https://github.com/aleks-linya/joomla-cms/commit/fb5f8fcd4790645f93b2f9e0d0be749f428230d2

[Andreas Tasch]

@Seth

I see but have another point of view on the matter.

Am Donnerstag, 27. Juni 2013 12:32:11 UTC+2 schrieb Seth Warburton:

I'm not against LESS (though I much prefer Sass), I'm against adding a compiler to Joomla's core. I don't think it should be possible to edit LESS files within Joomla, so I don't think we should include any compiler. 

It has been possible to edit CSS file since J! 1.5? If LESS is the evolotion of CSS (I think it is) we have two options, remove the ability to edit any template file from the template manager or make it possible to edit even .less files.

I don't think anyone would consider implementing a basic IDE *within joomla* to allow people to edit .php files from within the CMS (for the same reason I don't want to see a LESS compiler), so why do that for LESS? We're not recommending people edit files via FTP on a live server now are we? 

When you want to work on a live site you should have to copy your local changes there, this is a good thing. There is no ctrl+z on a live server. When working locally you can simply have your compiler watch the LESS folder in your localhost environment and output the .css to the templates css folder, no copy/paste required. Crucially though, the compiler isn't using the resources of the local server and there's an undo option available.

This is ok for me if I have to build the site from scratch or do some major changes. This is also ok if I do my development mostly on localhost. On my daily business I have to make small changes (just a few lines) for my customers from time to time - < 10 mins work. Making a backup of a live site and setting it up locally would take much longer. So I often end up grabbing their template.css or template.less doing the change and move it back on the server. Done.

Afaik t3-framework has a neat theme editor  - so customers do not need to bother me to make color changes, which is a good thing imho. But I don't expect everybody to agree :)   

Another common use case for me is the development of the site on a testserver. The site sits there on happycustomer.in-development.tld. I do the coding and if I have a good loking version and copy the template from localhost to the testserver. My buddy edits the content, moves modules around BUT also sometimes edits the colors of headings and links or changes font-sizes. During development we often end up in a Skype talk and do some minor changes here and there to get the perfect result. Copying the files all the time for each change is really frustrating so I end up editing the files directly on the server with a shell editor while we are talking. After we are finished we show the site the customer and may tweak again some minor styles until I deploy it on the live server.

Therefore a less compiler and maybe also an inline .less editor makes sense for my point of view. This is why I developed the less compiler plugin - in my workflow I often edit files on the command line editor and just refresh the page to see the results immediately.

[Andreas Tasch]

I just found out that Aleks gsoc proposal was not selected but instead the one from Ram, see

http://googlesummerofcode3.cloudaccess.net/9-front-end-categories/project-description/6-implementation-details.html

and github 

https://github.com/joomla-projects/joomla-cms/tree/gsoc-template-manager

[Ram Tripathi]

Hi Guys,

I'm a GSoC 2013 student with Joomla and my project is "Improvements to the Template Manager for CMS 3".

To begin with I'd like highlight what are the things that I plan to do.

So looking at my whiteboard I'm listing the features I'll be adding to Joomla.

Ability to:

• Edit and browse all the template files with ease
• Create new files
  
• Compile LESS
  
• Upload new files to the Template Folder (for e.g fonts, images or any other file)
  
• Template Preview
  
• Create new overrides
  
• Support for CDN
  
• And an ambitious feature of Generating a custom CSS file based on the JUI (Similar to the feature on bootstrap website).

All this will fit into one Editor which will be like a lightweight browser based IDE.
I've implemented some part of the project which can be seen here. The code is available on my personal repo.

You can find all the details about my project on my project website. The plan was changed about 3 times during the project planning phase to chose the right implementation for the project. After discussing it with my mentors I finally came up with what I think would be the best implementation (check the link above).

Since the basic editor is ready and compatible with all the types of template files, I'd love to get it tested and have your valuable feedback.
I've created a Tracker Item for the editor. Right now I'm working on the next feature i.e. ability to create new overrides and will also be modifying the editor further. Tell me what you think of it.

Looking forward to hearing from you guys :)

Thanks
Ram Tripathi

[Paul Orwig]

Hi Ram,

Thank you for checking in on this email list and sharing this information about your GSoC project!

I read the blog on your project website. It sounds to me like you have a good plan. Thank you for asking here for more feedback.

I am looking forward to reading more about your progress this summer. I hope you will learn a lot from your project, that your work will make Joomla better, and that you will remain a member of our community for a long time!

Best regards,

paul

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[George Wilson]

So if we are having a LESS Compiler as part of the template manager - to me it would make more sense to make this a more generic JLess Class with the Less PHP library that can be used outside of the the template manager. For example perhaps an JDocuments->addLess() which can be used similarly to JDocument::addScript() etc. 

Kind Regards,

George

[Bakual]

Such an APi would only make sense if LESS files are compiled during runtime, which I don't think is a good thing for a productive site. It takes to much time.
The files have to be compiled from the template manager, either manually or after saving parameters or after editing a file.