Upgrade to Bootstrap 3

[jricher]

Bootstrap 2 has reached EOL, we should try to upgrade and track with the newer version at some point. Probably post 1.1-branch though.

[jricher]

Icons don't seem to translate well when locally served, this might keep us off Bootstrap3 and FontAwesome.

[hansgru]

Icons don't seem to translate well when locally served, this might keep us off Bootstrap3 and FontAwesome.

I don't understand what you mean here. We are using Boostrap3 and FontAwesome on in many projects (and upgraded them from 2 to 3 for Bootstrap and 3 to 4 for FontAwesome without problems)

[jricher]

When I've tested this under Firefox on several platforms, I was not able to get the web font to load from the server's local domain. Everything runs fine when running from a CDN, but many of our deployments are on closed or restricted networks, so we need to pack in everything. We already have CORS headers set and the paths seem fine, so at the time I couldn't figure out what was causing the hiccup. Any advice would be appreciated!

[hansgru]

FontAwesome is using special font files for those icons (not images).

The difference can be in the encoding and mime types of the resources that come from CDN vs those who come from the local server.

E.g. apps made with Spring (e.g. Grails) won't handle font files correctly out of the box so extra configuration is required for fonts files to be served correctly by a local server too (not just images and css as they usually do)

FireBug can help to pinpoint this by having the 2 versions of a page and see if the local vs CDN headers are similar regarding encoding, mime type but also the content (e.g. in case Spring Security is not letting the font files tru).

(we also enforce all our Tomcats to have in catalina.bat/sh JAVA_OPTS=-Dfile.encoding=UTF8 to avoid further encoding mess)

[jricher]

I've just checked the headers for the local and CDN versions of the .eot file, and they aren't identical but are fairly close and I can't see what's causing the issue.

Local:

    Status Code: 200 OK
    Access-Control-Allow-Origin: *
    Content-Length: 67119
    Content-Type: application/vnd.ms-fontobject
    Date: Thu, 12 Mar 2015 15:38:57 GMT
    Last-Modified: Thu, 12 Mar 2015 15:36:26 GMT
    Server: Apache-Coyote/1.1

CDN:

    Status Code: 200 OK
    Access-Control-Allow-Origin: *
    Cache-Control: max-age=31104000
    Content-Encoding: gzip
    Content-Type: application/vnd.ms-fontobject
    Date: Thu, 12 Mar 2015 15:40:07 GMT
    Etag: W/"8b27bc96115c2d24350f0d09e6a9433f"
    Expires: Sun, 06 Mar 2016 15:40:07 GMT
    Last-Modified: Tue, 05 Nov 2013 13:56:32 GMT
    Server: NetDNA-cache/2.2
    Vary: Accept-Encoding
    X-Cache: HIT
    X-Hello-Human: You should work for us! 

It's GZIP encoded from the CDN, but I don't see how that's any different in this case. Any advice in helping make this work would be appreciated, but if the webfonts won't load then we just can't use it.

[jricher]

After some more investigation, I found the answer! It turns out that Maven was corrupting the font files while packaging the .war file through the resource filtering mechanism. I told it to leave the .woff, .eot, and .ttf files alone and things seem to be fine now. This is great and it paves the way for Bootstrap 3 and FontAwesome (#243). Both of those are still lower priority tasks right now, but at least it looks like it's possible.

[jricher]

Font loading should be enabled by ed88878

[praseodym]

Aside from doing what is mentioned in the Bootstrap 3.x migration guide, is there any upgrade trouble expected?

We've got an issue where the /manage/user/profile view misaligns due to empty claims, this is fixed in Bootstrap 3.

[jricher]

Now that font loading is fixed, that's probably it, but it's a big enough undertaking that I'm not sure it's going to make it for 1.2 just due to priorities.