Something prevents Roundcube CSS from loading only when a domain is part of the webmail URL. Layout displays properly as long as server IP or hostname over port 2443 are used, or when accessed from Siteworx.
The domain glitch occurs in any browser. Firefox console shows errors such as stylesheets fetch failed and Error while parsing stylesheet along with NS_ERROR_NET_PARTIAL_TRANSFER for CSS and font assets.
Where should I be looking to find and fix the problem?
Hello–
This is a known issue. I do not have an ETA as to when the fix will be released. Please use 2443 in the url for the time being. We have to release a new version of httpd-iworx to resolve the issue.
Note, you should be able to use the domain in the url, it just has to be domain.com:2443/roundcube or /webmail. Though that connection will show as insecure since the SSL cert that covers 2443 is for the hostname, not the domain.
Thanks,
-Jenna
We had this and fixed it. Will go back and look for the fix, had to override something to do with the cache within the httpd.conf for iWork back end.
Hello–
Please do not make changes to the internal httpd.conf file. Doing so may cause unexpected issues down the line.
Thanks
-Jenna
Thanks, good to know.
If you mean the iworx instance, in particular proxy stuff, that’s sacred ground I would never mess with.
/home/interworx/etc/httpd/httpd-last.conf
Commented out:
# AddOutputFilterByType DEFLATE text/html
# AddOutputFilterByType DEFLATE text/css
Added after closing for
<LocationMatch “^/roundcube/static.php/”>
RemoveOutputFilter DEFLATE
This isnt a 100% fix but workaround that works that we are using until patched.
Hello–
I mean any file under the /home/interworx/etc/httpd/ directory.
Changes made to those files may cause unforeseen issues down the line. Especially since we do not overwrite those files upon update, if they have been edited.
So if we made an update to httpd-iworx that includes required changes to /home/interworx/etc/httpd/httpd-last.conf, since you edited that file, you will never get that part of the update. It will be added to httpd-last.conf.new, instead. And, since the new version of httpd-iworx can’t see the required changes to the conf file, your GUI may break.
For this reason (on top of others, such as just a typo potentially breaking something), we ask that customers never edit those files, themselves. I’ve seen so many servers where edits made to those files just broke everything in ways that took me hours to fix.
Thanks,
-Jenna
I appreciate the hack and even if I don’t use it I learned something from it. static.php came up a lot during my research, apparently it’s been controversial. Thanks for taking the time.
Hello–
We just released the fix for this issue. It is an update to httpd-iworx. The fixed version is httpd-iworx-2.4.68-15
Your servers should automatically update the next time the daily cron runs. Alternately, you can update manually with
yum clean all
yum update *.iworx.*
Thanks,
-Jenna
That was quick, thanks! Update fixed it.
Seems like i got this problem still active (after all updates).
If client using /webmail and replying email then got red message below: Connection Error (Failed to reach the server)!
If hostname over port 2443 are used everything works.
Hello–
That is a completely different issue. In the issue reported here, the CSS just looked weird–the inbox was just a plaintext list, the Roundcube icon took up the entire page, etc. There were not any errors, connection or otherwise. It was an issue with how the page looked–purely cosmetic. It had nothing to do with sending, replying, or receiving messages.
What you are reporting also has not been reported by anyone else, nor can it be reproduced on a test server.
Please submit a ticket to support.interworx.com. Make sure to provide the IP or hostname of the server, steps to reproduce (credentials to an affected account can be left in a file on disk), and make sure that remote assistance is enabled: How To: Enable Remote Assistance — InterWorx documentation
Thanks,
-Jenna