Even MORE Performance fixes

It's hard to contain my excitement about what I am going to share.

Brian Chan (along with Eduardo Lundgren) have just recently committed a change that I (along with any other person who has to deal with themes) have been pestering him for quite some time, and it is my great pleasure to finally be able to tell you guys he has implemented it.

What is it, and why should you care?

One of the less friendly aspects of how themes and plugins work in Liferay is the packing of CSS and Javascript. From 4.3.x and later, there has been some files that have caused an unending amount of confusion and extra work for people.
I'm talking specifically about *_unpacked.* and *_packed.*

Perhaps you've looked at your deployed theme and seen a everything_packed.css and everything_unpacked.css as well as seeing around files like packed.js, unpacked.js, everything_packed.js, etc.

These files have been created at build time and they are the optimized versions of those files so that you don't make as many http requests and don't download unnecessary whitespace and characters.

Well, the change that Brian committed now completely removes those files and they are handled for you automatically.

Think about something that happened to my good friend Ray Auge not too long ago while we were doing some work for one of our critically acclaimed clients. I can't say who, but practically everyone has heard of them. Anyways, they have a theme hot-deployed and Ray made some changes to the theme and IMed me one weekend wondering why the changes weren't being picked up. He kept changing the CSS in custom.css and nothing happening.
Only because I had been touched by this little bug had I known what was causing it.
But anyone that knows Ray knows that he's one of the smartest guys in Liferay. There's no reason in the world why he should have been banging his head against this, and I wish I could say it was a lone incident.

The reason he wasn't seeing his change is because the client was in production mode, with and set to true (which is what it should be for a production environment, and I have to applaud everyone that uses these properties in production).

But what that meant was that since the packed css files were only being created when the theme was built, the changes were never actually being copied into everything_packed.css. So not only would he have to rebuild the theme from the plugins SDK, he would also have to redeploy the theme. And as we all know, sometimes we don't have the plugins theme available.
Sometimes we have to do maintenance on a theme or plugin someone else has developed.

So how is this fixed now?

Brian Chan has made it so now those files are automatically created when the server starts up. How would Ray resolve this if he were to do this now?
All Ray would have to do is restart the server or if that was too much, and he had the original theme WAR file, he could just redeploy the theme.

Either of those is far preferable to having to rebuild the theme from the source, and far less confusing.

Brian and Eduardo have been really hard at work doing this and even more performance fixes over the past couple of weeks and I've been amazed at how snappy our website has become.

So what's the information on getting these fixes? These changes will be available in 5.2 which is coming soon (really :), or, if you need an enterprise-level and robust way to get these fixes for your deployment of 5.1.x version of Liferay, then now is a great time to get Liferay Enterprise Edition. You can get long term bug fixes, security patches, and performance improvements like this in a safe, reliable manner with our Enterprise Edition, so I would highly recommend it.

And when you get a chance, shoot by Brian and Eduardo's pages and thank them for getting this in.

Hi Nate!

Thanks for post about this and for the references you've made emoticon

I'm really excited with these improvements we've been working on Liferay.
Hello Nate,

Thank you for this post, I have been laughing inside, because the case of Ray and you, is the same case I had with Miguel Angel Pau, a few weeks ago.
You can imagine I am also very happy with the improvment.
From here also thanks to Brian and Eduardo.

Saludos, Jack.
Thank heavens! When I started working on a custom theme for work I just hacked up the jedi theme and this totally threw me for a loop. I was never on board with the idea of "building" a theme when all I had was velocity templates, css, and images, but no java code.

Too bad we're locked into 5.1.2 for a few months . . .
The shared case is a common problem faced, especially when :

- You are working (hacking, hacking) directly at the production portal
- You don't have the luxury of "re-building" the theme using plugins SDK
- You need to get it done fast

The new enhancement is surely a great improvement that we all need, but it is only available in the coming releases.

Knowing for the fact that I'll always face the abovementioned scenario, just to share with you what I have done :

- create a "lib" folder in the production <theme> folder
- place jargs.jar, rhino.jar and yuicompressor.jar files into the "lib" folder
- create a .bat file (in my case windows env) in the production <theme> folder with the following commands :

java -classpath ..\..\..\WEB-INF\lib\portal-impl.jar;..\..\..\WEB-INF\lib\util-java.jar;..\..\..\WEB-INF\lib\commons-logging.jar;..\..\..\..\..\common\lib\ext\portal-kernel.jar css css\everything_unpacked.css

java -classpath ..\..\..\WEB-INF\lib\yuicompressor.jar;..\..\..\WEB-INF\lib\rhino.jar;..\..\..\WEB-INF\lib\jargs.jar --type css -o css\everything_packed.css css\everything_unpacked.css

Whenever I've made any change to the CSS files, I will then run the .bat file to have all the changes compiled into the _packed.css file, usable in a production env with enabled.
I'm going to publish a tutorial on my own web site on how to "tune" liferay and its underlying apps tomcat and mysql. When it's ready to go public - it will be on - my site that's devoted to those of us that have curly hair emoticon