Hello,
I've searched the archives, google, and posted on the forums. Trying here as well as none of the apparent solutions suggested elsewhere are working.
on apache server, login screen looks OK: http://i52.tinypic.com/f2t2tc.png
on lighttpd server, it looks broken: http://i52.tinypic.com/wgsqde.jpg
Notice missing box and obvious misalignment on the lighttpd screenshot. Also, upon logging in, the icons and text are misaligned to the point the site cannot be used.
We need to get RC working on lighttpd, but since there are no errors being reported in any logs as far as I can tell, I'm a little perplexed about how to troubleshoot.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Mon, 19 Sep 2011 23:09:37 -0400, Sahil Tandon sahil@tandon.net wrote:
We need to get RC working on lighttpd, but since there are no errors being reported in any logs as far as I can tell, I'm a little perplexed about how to troubleshoot.
I would start by viewing the page source in the browser and checking for differences.
If it looks different, it probably means something different was served.
Hi,
On 20/09/11 05:09, Sahil Tandon wrote:
on apache server, login screen looks OK: http://i52.tinypic.com/f2t2tc.png
on lighttpd server, it looks broken: http://i52.tinypic.com/wgsqde.jpg
Notice missing box and obvious misalignment on the lighttpd screenshot. Also, upon logging in, the icons and text are misaligned to the point the site cannot be used.
Looks like CSS rules are not being applied. As Kaz suggested, view the page source and try to follow CSS links. Perhaps you have something wrong in your lighttpd configuration that doesn't map correctly your static files paths as RC is expecting.
Regards.
On Sep 20, 2011, at 2:05 AM, Jorge López Pérez jorgelp@us.es wrote:
Hi,
On 20/09/11 05:09, Sahil Tandon wrote:
on apache server, login screen looks OK: http://i52.tinypic.com/f2t2tc.png
on lighttpd server, it looks broken: http://i52.tinypic.com/wgsqde.jpg
Notice missing box and obvious misalignment on the lighttpd screenshot. Also, upon logging in, the icons and text are misaligned to the point the site cannot be used.
Looks like CSS rules are not being applied. As Kaz suggested, view the page source and try to follow CSS links. Perhaps you have something wrong in your lighttpd configuration that doesn't map correctly your static files paths as RC [...]
I am able to follow all the css/foo/bar links without incident. Diffing the two sources is complicated by the fact that the apache server is running a much older RC version, so a diff would be tainted with expected differences due to changes from 0.3.x -> 0.5.x.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Tue, 2011-09-20 at 14:31:18 -0400, Sahil Tandon wrote:
On Sep 20, 2011, at 2:05 AM, Jorge López Pérez jorgelp@us.es wrote:
Hi,
On 20/09/11 05:09, Sahil Tandon wrote:
on apache server, login screen looks OK: http://i52.tinypic.com/f2t2tc.png
on lighttpd server, it looks broken: http://i52.tinypic.com/wgsqde.jpg
Notice missing box and obvious misalignment on the lighttpd screenshot. Also, upon logging in, the icons and text are misaligned to the point the site cannot be used.
Looks like CSS rules are not being applied. As Kaz suggested, view the page source and try to follow CSS links. Perhaps you have something wrong in your lighttpd configuration that doesn't map correctly your static files paths as RC [...]
I am able to follow all the css/foo/bar links without incident. Diffing the two sources is complicated by the fact that the apache server is running a much older RC version, so a diff would be tainted with expected differences due to changes from 0.3.x -> 0.5.x.
Would it be helpful if I posted the problematic address here? I'm not sure if that violates some sort of mailing list protocol.
Although the INSTALL document recommends the inclusion of "text/css" in Lighty's compress.filetype array, removing "text/css" (i.e. not compressing css) restores normal UI behavior. I am not entirely satisfied with this, but it is a sufficient workaround for now.
On Tue, 20 Sep 2011 19:09:15 -0400, Sahil Tandon sahil@tandon.net wrote:
Although the INSTALL document recommends the inclusion of "text/css" in Lighty's compress.filetype array, removing "text/css" (i.e. not compressing css) restores normal UI behavior. I am not entirely satisfied with this, but it is a sufficient workaround for now.
Good work. Okay, so the problem would seem to be in the compression or decompression. Might it be a issue in lighthttpd?
You're missing just perhaps one more step in your excellent root-cause analysis.
Namely, google for "lighthttpd broken compression".
First hit:
"Lighthttpd - css files broken if mod_compress enabled on lighttpd 1.4.26"
http://redmine.lighttpd.net/boards/2/topics/4226
:)
On Tue, 2011-09-20 at 16:21:27 -0700, Kaz Kylheku wrote:
On Tue, 20 Sep 2011 19:09:15 -0400, Sahil Tandon sahil@tandon.net wrote:
Although the INSTALL document recommends the inclusion of "text/css" in Lighty's compress.filetype array, removing "text/css" (i.e. not compressing css) restores normal UI behavior. I am not entirely satisfied with this, but it is a sufficient workaround for now.
Good work. Okay, so the problem would seem to be in the compression or decompression. Might it be a issue in lighthttpd?
That would be the obvious conclusion but such diagnosis is too general and, thus, incomplete. For example, other css-employing web sites served by the same lighttpd instance are unaffected by css compression.
You're missing just perhaps one more step in your excellent root-cause analysis.
I think more than one step is missing. Indeed, that is why I am on this seeking help from the experts.
Namely, google for "lighthttpd broken compression".
Been there; done that.
First hit:
Yes, I noticed this when I conducted similar google queries several days ago.
"Lighthttpd - css files broken if mod_compress enabled on lighttpd 1.4.26"
A careful reading of that link will reveal nuanced differences between the issue reported by "telix" and my problem.
The OP in that thread is apparently referring to broken css files even when text/css is not explicitly set in compress.filetype. What I have reported above is that RC behaves as desired when text/css is not set in compress.filetype, but I did not have to disable mod_compress! In my testing, it is *only* when compress.filetype is configured to compress text/css does the problem manifest itself in various browsers. Compressing other mimetypes is just fine, does not cause any problems, and there is no apparent breakage of css or RC.
So, I would appreciate if others who are using lighttpd + roundcube 0.5.4 (or more recent trunk) *and* compressing text/css mimetype would share their lighttpd configurations as they related to RC.
In the meantime, I will continue to investigate for "root causes" and report my findings.
List info: http://lists.roundcube.net/users/ BT/9b404e9e