CSS dissappears randomly in so-theme

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.0b
• Fix Version/s: 1.5RC
• Component/s: Environment > General / Integration
• Labels: None
• Similar Issues: Show 5 results ; ;

  SOS-984	SO Theme: Exceptions when user tries to logout with the SO theme applied
  SOS-102	Theme main search bar to match SO theme
  SOS-116	Theme members portlet to match SO theming
  SOS-332	Migrate so-theme to 6.0 theme engine.
  SOS-1149	Deleting a site causes the Dashboard to lose SO theme

Sometimes so-theme loses is CSS and appears blank. I have seen this happen with 1.5b and it was also reported in the forum: http://www.liferay.com/web/guest/community/forums/-/message_boards/message/3855974#_19_message_3857457

[Jamie Sammons]

Speaking of the problem. Just happened again. Nothing ever appears in the catalina.out

[Jamie Sammons]

One other bit of information. I was unable to recover it this time until I flushed the Tomcat cache and restarted the server.

[Ryan Park]

Hey Jamie,

If it is random would you mind replying to this ticket for different case and just note what you were doing at the time?
Maybe up to 5 times?

Thanks!

[Jamie Sammons]

This particular time I made a Task and reassigned it to a co-worker. I just tried that again but it didn't break it this time. Do you know of any trace settings that may help with this that I can set?

[Ryan Park]

Sorry Jamie I don't know of any setting which would help recover that data.

Just a hunch, I suspect that it is the css and javascript minifier that we use to compact the files together before returning it to save on requests and file size. This is the only delta that I can see between my environment and everyone else's because I turn the minifier off since i'm not concerned with the number of requests.

I will start developing with the minifier off and we'll see if this problem crops up.

Another question:

How frequent does this problem occur?

[Jamie Sammons]

I wasn't trying to recover anything I was just trying to get the system to log more information when the problem occurs. Are there any trace settings that we can enable for minifier to try and get more information at the time that the problem occurs?

I have seen it about 3 times since we rolled 1.5b1.

One other thing of interest is that this never occured in 1.0b1. Is the minifier something new in 1.5b1?

[Ryan Park]

Nope the minifier isn't anything new, though there has been changes made to it but the difficult problem is that it isn't throwing any errors. Which is what I meant by not being able to recover any logs.

This one might take a while because I'll have to wait for it to happen again.

Though if it happens to you again, I'm interested to know if it occurs on more than one computer and if the problem is isolated to a browser. If it crops up can you see if the css is missing for other browsers on the same machine and if it is missing on a different computer with the same browser?

Thanks Jamie

[Jamie Sammons]

Hi Ryan,

I do know that it affects more than one computer. When the problem happens I usually have my co-worker CTRL-F5 her browser and then hers disappears. Right now I'm almost wondering if my Tomcat cache was corrupted. Maybe flushing it was all that I needed. I will keep my fingers crossed.

[Ryan Park]

You're right, it could be corrupted cache.

We were having this problem with Liferay's minifier prior to launch but we've fixed it which is why i thought our fix didn't work but looking back we removed the code that caused it. So it may not be the minifer but a caching problem.

Thanks for the heads up. It still hasn't popped up on my computer. But I'm looking forward to fixing this one.

[Jamie Sammons]

Ryan,

I just had this happen again to me. It was difficult to recover from it this time. I ended up having to delete everything in the tomcat temp directory before it would come back. It looks like people were updating Wiki articles and one person posted to the Forum today.

[Ryan Park]

Hey Jamie,

Thanks for the updates. When this problem occurs can you try to add "?css_fast_load=0" without the quotes to the end of your url and see if the proper CSS comes back?

[Jamie Sammons]

Hi Ryan,

Adding "?css_fast_load=0" without the quotes to the URL doesn't make a difference. I had to flush the Tomcat temp and cache directory and restart again before it would come back.

[Jamie Sammons]

Ryan,

Do you think I should completely disable the Minifier to see if the problem goes away?

[Ryan Park]

Yes you could try, though it could dramatically increase the amount of time a page loads.

[Jonas Yuan]

In IE 6, can reproduce the same as stated in SSO-221.

Most of time, it is working fine for IE6, FF, Chrome when loading the site for the first time. But after caching, the issue always comes out.

[Jonas Yuan]

see screenshot in IE 6

[Jonas Yuan]

It is in SOS-221 - same issue.

[Jamie Sammons]

I was curious if disabling the Minifier would aid us in troubleshooting. I didn't know if the Minifier was obscuring some valuable troubleshooting information from us. I was hoping that Firebug would help us chase this down but it hasn't helped much so far.

[Jamie Sammons]

It happened again. I disabled the Minifier which made it come back on a restart.

I noticed that without the Minifier running the contacts portlet doesn't display right. It has missing icons and issues with the Sites drop down at the top.

So I enabled the Minifier again and restarted which caused it to break again.

I then undeployed the contacts portlet and restarted which made the theme come back. So maybe this issue is related to the contacts portlet?

[Ryan Park]

That is quite interesting, I'm not sure why the contacts portlet would effect this but I guess its a lead.

Thanks Jamie.

[Jamie Sammons]

Ryan,

Undeploying and redeploying the contacts portlet definitely makes the so-theme come back. It does so even without restarting the App Server. I'm wondering if its just that one portlet or if its just the act of undeploying and redeploying a portlet that is fixing it. Next time it happens I will choose another portlet to undeploy and redeploy.

[Jamie Sammons]

Actually it just broke again shortly after deploying the contacts portlet again. I tried undeploying the tms portlet which didn't fix it. I then undeployed the contacts portlet again which does fix it.

Could the things that break in the contacts portlet with the Minifier disabled be a clue?

[Ryan Park]

Hey Jamie,

This is a bit of a stretch but can you give me some info of your setup?

What OS are you running?

What JDK\JRE are you using?
If windows are you using the bundled JRE?

Thanks

[Jamie Sammons]

Hi Ryan,

Here's the info:

Ubuntu Server 8.04 64bit
OpenJDK 6.0
MySQL 5.0.51a
Tomcat 5.5.27

[Jonas Yuan]

Same issue I got in following settings:

URL: http://liferay.cignex.com:9090/
User: jonas/jonas

Server Settings:
CentOS 64bit
JDK 1.6.0_16
MySQL 5.0.45
Tomcat 6.0.18

[Jonas Yuan]

By the way, I can reproduce same issue in IE 6, FF 3.5.3, Chrome 3.0 ...

[Jonas Yuan]

Here are simple steps to reproduce the issue:

1) go to http://liferay.cignex.com:9090/
2) login as jonas/jonas
3) switch to the site "Clients"
4) go to http://liferay.cignex.com:9090/web/clients/calendar
5) update an event and click on Save button
CSS dispeared ...

[Jamie Sammons]

I have recreated this behavior on our site. The stuff with the contacts-portlet must have been a coincidence.

[Ryan Park]

Hey Jamie,

As in undeploying contacts no longer fixes the issue?

I was going to ask that you try other plugins like the so-theme.

But for sure that should fix it because I do firmly believe this is now a cache issue.

[Jamie Sammons]

Ryan,

I do believe undeploying contacts still fixes it. At the moment I am unable to recreate the calender problem so I would totally buy a caching bug.

When the problem occurs again I will see what impact undeploying the various plugins has on it.

[Jamie Sammons]

Jonas,

Please try the following to see if the calendar issue goes away for you:

1.) Stop Tomcat
2.) Delete the tomcat work and temp directories
3.) Restart Tomcat and try to recreate.

I also made sure I had a fresh browser session so that the browser cache wasn't messing with me.

If this works it may help prove the caching theory.

[Jonas Yuan]

Hi Jamie, Thanks. I can reproduce this issue always with following steps.

Clean and restart
1) Stop Tomcat
2) Delete the tomcat work and temp directories
3) Restart Tomcat

Then test (using Chrome)
1) go to http://liferay.cignex.com:9090/
2) login as jonas/jonas
3) switch to the site "Clients"
4) go to http://liferay.cignex.com:9090/web/clients/calendar
5) update an event and click on Save button
CSS disappeared ...

[Jonas Yuan]

Hi Ryan and Jamie, thanks you both.

I could reproduce the same issue in FF. It seems that it is not only caching issue ...

The server (SO) is cleaned and restarted. You may test this server, too, using IE, FF,Chrome from your local machine. The following are main steps:

1) go to http://liferay.cignex.com:9090/
2) login as jonas/jonas
3) switch to the site "Clients"
4) go to http://liferay.cignex.com:9090/web/clients/calendar
5) update / create an event and click on Save button
CSS disappeared ...

[Jamie Sammons]

Hi Jonas,

I could recreate this yesterday in my enviornment but today I can't. How odd.

[Attila Fazekas]

Hi all,
This issue is very similar what we found at Liferay Portal.

On our case if the browser asking for data which is not in the Liferay cache, but tagging it with good ETAG or Not-Modified-Since, the lower filters / servlet serves the content with 304(not modified) status. The gzip filter compress the zero length response to 20 byte (only when other filter closes the stream before gzip comes). The cache will cache it, and on next request serve it.

After tracing the issue I reported several bugs, including: LPS-5244 , LPS-5243 .

We reproduced this issues by telnet to 8080 port like this:
GET /Path-to-my-css/my.css?hfkjhi=45 HTTP/1.1

Host: myserver

Accept-Encoding: gzip

If-Modified-Since: Sat, 29 Aug 2009 09:00:13 GMT

HTTP/1.1 304 Not Modified

Date: Tue, 29 Sep 2009 14:46:08 GMT

ETag: 1

ETag: W/"494-1251520140000"

Expires: Fri, 27 Sep 2019 14:46:10 UTC
(20 byte comressed data)

And et next time:
GET /Path-to-my-css/my.css?hfkjhi=45 HTTP/1.1
Host: myserver
Accept-Encoding: gzip

HTTP/1.1 200 OK

Date: Tue, 29 Sep 2009 14:46:24 GMT

filter-class: com.liferay.portal.servlet.filters.header.HeaderFilter

Expires: Fri, 27 Sep 2019 14:46:26 UTC

ETag: 1

ETag: W/"494-1251520140000"

Content-Encoding: gzip

Content-Length: 20

Content-Type: text/css

The ?hfkjhi=45 can be any other not used random for test, it needed to make sure it is not requested before. The target file can be anyone where you uses the cache, gzip and etag filter.

[Brian Chan]

This issue should be solved now. Thanks Attila.

[Tim Jones]

With the latest version (as of 20100301) I am experiencing exactly the same issue - so it would seem not to be solved after all

[Ryan Park]

Hi Tim,

The version which contains the fix has not yet been released.

If you have built Social Office from the source, can I ask which revision of Portal and Plugins you are using?

Thanks,
Ryan