Recent Bloggers Recent Bloggers
Ronald Sarayudej Posts: 19
Stars: 39
Date: 7/2/09
Jonas Yuan Posts: 6
Stars: 17
Date: 6/29/09
Cecilia Lam Posts: 1
Stars: 0
Date: 6/25/09
Alice Cheng Posts: 131
Stars: 0
Date: 6/17/09
Deepak Gothe Posts: 2
Stars: 3
Date: 6/16/09
Bryan Cheung Posts: 12
Stars: 56
Date: 6/12/09
Richard Sezov Posts: 27
Stars: 83
Date: 6/10/09
Jonathan Neal Posts: 10
Stars: 58
Date: 6/8/09
Caris Chan Posts: 2
Stars: 6
Date: 6/5/09
Blogs Blogs
IE8 is out. What does it mean for your theme?
By Nate Cavanaugh, On 3/19/09 10:19 AM

If you're as cutting edge as our own Jonathan Neal, you might have downloaded the IE8 final that was released this morning at 9am PST.

IE8 is a HUGE improvement towards standards, and while it still has not caught up with Firefox, Safari, Chrome or Opera, when it comes to IE, we will take what we can get :)

However, since it's more accurate with the standards, you may have noticed that your theme could be off in IE8 compared to IE7.
If this is the case, there's a good chance that any IE hacks that existed in your theme to fix problems that were in IE7 and below. A good example of this would be using the .ie selector in your CSS.

The problem with applying a hack to ALL IE's via .ie means that when future versions, such as IE8 fix the problems you were hacking, these will break your theme for the new IE.

So what's the fix? It turns out there are 2 good fixes, one for the short term and one for the long term.

The long term fix is to of course change your selectors from being broad to being specific.
For instance, if you are using a selector like this:
.ie #wrapper {
}

And that selector is causing issues, you should change it to be:

.ie7 #wrapper, .ie6 #wrapper {
}

This will make sure that the selector only applies to specific versions of IE that have the broken functionality you're addressing.

But this might take some time to get around to, and we all are a bit busy, so there is a quick short term fix that will solve the issues.

In the <head> of your theme, you can add this:
<meta http-equiv="X-UA-Compatible" content="IE=7" />

That is a new tag Microsoft has added to IE8 so that you can tell IE8 what rendering engine to use. In this case we're telling it to use the IE7 rendering engine instead of the more standards compliant IE8 engine.

Average (2 Votes)
1146 Views, 2 Comments
Changes in Liferay's front end
By Nate Cavanaugh, On 2/18/09 5:53 PM

If you follow our trunk as ardently as I do (and really, who doesn't) you might have seen some front end changes, and there might have been some theme changes that are a little different from what you were expecting.

There are some big happenings going on in the front end of Liferay, and I'll have some more details for you shortly, but I just made a commit that I wanted to talk about that I think will make developers quite happy.

I added a file called deprecated.js to portal.properties. This file is a place where we will deprecate our changing Javascript so that that the upgrade path between major versions is a lot smoother.
This file will be updated any time something from the Javascript API has been changed from the previous version.

Here's how it will work:

As soon as a piece of script is changed from a previous version, such as a variable being removed, certain options changing, etc, we will place code inside of deprecated.js that will make the Javascript work for the next version.

So let's go through an example. One thing we've been wanting to do is clean up the amount of room we take in the global namespace. We have a few outstanding global variables, such as LayoutConfiguration, or themeDisplay and we want to clean those up to protect from future namespace collisions.

So assuming we move LayoutConfiguration to be accessed from Liferay.LayoutConfiguration, we would add code inside of deprecated.js that will keep the backwards compatibility for 1 major version.

So in 5.3, the deprecated.js might look like this:

//To be removed in 5.4

// LPS-1234
LayoutConfiguration = Liferay.LayoutConfiguration;

// LPS-4567
themeDisplay = Liferay.ThemeDisplay;

 

However, in Liferay 5.4, this entire block would be commented out.
It will still be in the file, but it will be commented out. The reason behind this is so that developers who are running behind in upgrading between versions can still uncomment their code and have things work for the most part. It's kind of our way of letting you know what we recently removed.

In Liferay 5.5, this block would be removed completely.

So in any version from 5.3 on, you would be able to see what is scheduled to be removed and what, if anything, was removed in the previous version.

There are a couple of reasons for this change, and I wanted to talk about them.

One of the areas where I believe Liferay shines is in innovation. We are able to rapidly change faster than any organization I've worked for. However, whenever things change rapidly, not everyone is able to keep up. It's very easy as a developer to forget this, unless you're the developer who is trying to keep up :)

One of the reasons we introduced Liferay Enterprise Edition was because people, especially enterprises, need a stable and robust way to get bug fixes, security patches and performance enhancements, without having to upgrade an entire revision number.

In that same vein, we're adding the deprecated.js, not just as a service to EE customers, but as part of the general process.
So we have spent some time now trying to come up with creative ways to allow innovation, while making sure that we make upgrades a lot smoother.
I'm not trying to portray this as the end goal in and of itself, but more or less a piece of the process and a goal we're striving for.

We still have a lot of areas where we can improve, but this is more or less to let you know we are, and the steps we're taking in getting there.

What are some other ideas? Bryan Cheung and I were talking earlier today about communicating to folks that don't have the time or mental bandwidth to scour through commit logs and LPS tickets. What we were wondering is, similar to Liferay's twitter feed what if we had a Liferay Developer twitter account? Is that something anyone would be interested in?
Basically, it would contain short snippets and bursts on stuff we're working so you can keep a loose idea of the happenings going on with the development team.

For instance, if I add some awesome functionality to the JS, but it doesn't warrant an entire blog post, I could tweet something like "Added the ability to create ajaxable panels: LPS-12345" which would have a link to the ticket where I discuss what was added.

Would this be helpful to anyone?

Also, in the lead up to Liferay 5.3, there will be some very big UI changes coming, and I will blog in more detail about that, but the other plan is that as everything progresses, I will be blogging about the individual changes and milestones.

Another option that has completely changed my life and sanity is that Mike Young recently installed Fisheye to watch our commits. I think the feature I have most used is the RSS functionality. I subscribe to commits by directory and also by committer. For instance, I am usually interested in a couple of commits. Anything committed by my friends Eduardo Lundgren or Peter Shin, anything committed to the portal-web directory and anything committed to the themes or to the js directories (I know there is some duplication there, but I'd rather have a bit more info).

If you want to stay on top of what people are doing, it's an awesome way to keep your ear to the ground.

So there are some ideas. I would love to have feedback, especially on ways to better communicate with you guys that extends beyond our normal routes.

Average (2 Votes)
1073 Views, 3 Comments
Even MORE Performance fixes
By Nate Cavanaugh, On 1/12/09 8:16 PM

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 theme.css.fast.load and javascript.fast.load 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.

Average (3 Votes)
6154 Views, 4 Comments
Liferay wallpaper
By Nate Cavanaugh, On 12/28/08 6:33 PM

There are a ton of amazingly creative people here at Liferay, and I'm always stunned with the stuff that people create.

Last night I was doing a ton of coding and some inspiration struck to make some Liferay "fan art". I don't get the time to do as much artwork as I used to, so it was a nice treat for me.

So, it totally is not "corporate" and doesn't really follow the Liferay branding guidelines, but like I said, it's "fan art" and normal rules don't apply. I wanted to make something a bit edgier than we're used to having.

I've created a package with common wallpaper sizes that you can download here.

Here is a brief preview:

Average (1 Vote)
1460 Views, 7 Comments
Is this site running Liferay?
By Nate Cavanaugh, On 11/20/08 6:41 PM

It's been a while, but trust me, we've been working like crazy to get 5.2 out for your using pleasure.

But, I arrive with a bit of a gift, especially for the marketing folks (or anyone curious). Have you ever wondered if a website was running Liferay?

Well guess no more. I've written a Greasemonkey script that will tell you if a website is running Liferay or not. What's Greasemonkey you ask?
Only about the absolute coolest extension for Firefox known to man (yes it requires Firefox).

So what do you do?

If you have Greasemonkey installed, you should just skip to Step 3.

Step 1: Go to https://addons.mozilla.org/en-US/firefox/addon/748

Step 2: Click the Add to Firefox button, and install the plugin. It will notify you to restart firefox.

Step 3: Once you've restarted, go here: http://userscripts.org/scripts/show/37259

Step 4: Press the Install button at the upper right

Step 5: Agree to the install

 

Step 6: Visit a website (like http://liferay.com)

 

Step 7: Enjoy the info:


And that's it. You can hide the display (and it will popup on every page load, or you can hide it for the domain, which will hide it for 1 year. If you want it to show up again, just clear your cookies, and it will popup again for any domain you have hidden it for.

 

Enjoi!

Average (3 Votes)
2613 Views, 5 Comments
Showing 1 - 5 of 26 results.
Items per Page
Page of 6
First Previous Last