This repository has been archived by the owner. It is now read-only.

Font-awesome asset path in compiled application.css #402

Closed
shippy opened this Issue Oct 13, 2014 · 16 comments

Comments

Projects
None yet
3 participants
@shippy
Contributor

shippy commented Oct 13, 2014

development.shifts.yale.edu/stcdev, which is the deployed v3.0.0-beta3 in production environment, has broken images and some tooltips hang indefinitely (notably the ones for timeslot creation). A possible reason suggested by @caseywatts and @orenyk is that there is an asset precompilation (lack thereof) problem, which might be solved by deploying to this particular test instance in a staging environment.

This consists of:

@shippy shippy added the highpriority label Oct 13, 2014

@shippy shippy self-assigned this Oct 13, 2014

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Oct 16, 2014

Contributor

Ran Shifts in production, cannot repro hanging tooltip

Contributor

njlxyaoxinwei commented Oct 16, 2014

Ran Shifts in production, cannot repro hanging tooltip

@shippy

This comment has been minimized.

Show comment
Hide comment
@shippy

shippy Oct 16, 2014

Contributor

IIRC development.shifts.yale.edu/stcdev runs in development, because production would send e-mails. staging is a step in-between.

Contributor

shippy commented Oct 16, 2014

IIRC development.shifts.yale.edu/stcdev runs in development, because production would send e-mails. staging is a step in-between.

@shippy

This comment has been minimized.

Show comment
Hide comment
@shippy

shippy Oct 17, 2014

Contributor

Inserted the file in 402_staging and attempted RAILS_ENV=staging rake assets:precompile; this only works on a dev machine if you uncomment #config.serve_static_assets = true, but I assume our deployment server will not have this problem. Filing a PR.

Contributor

shippy commented Oct 17, 2014

Inserted the file in 402_staging and attempted RAILS_ENV=staging rake assets:precompile; this only works on a dev machine if you uncomment #config.serve_static_assets = true, but I assume our deployment server will not have this problem. Filing a PR.

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Oct 17, 2014

Contributor

the following command precompiles the assets:

rake assets:precompile RAILS_ENV=staging

you will need to uncomment line in staging.rb

config.serve_static_assets = true

and then run

rails s -e staging

to start the application in staging environment. It is just production mode without mailer.

Contributor

njlxyaoxinwei commented Oct 17, 2014

the following command precompiles the assets:

rake assets:precompile RAILS_ENV=staging

you will need to uncomment line in staging.rb

config.serve_static_assets = true

and then run

rails s -e staging

to start the application in staging environment. It is just production mode without mailer.

@shippy

This comment has been minimized.

Show comment
Hide comment
@shippy

shippy Oct 17, 2014

Contributor

There are reasons to believe that our initial diagnosis was wrong: the only thing that doesn't load on the test deployment server is FontAwesome, namely http://development.shifts.yale.edu/assets/fontawesome-webfont.woff?v=4.2.0 and http://development.shifts.yale.edu/assets/fontawesome-webfont.ttf?v=4.2.0. This might be, for some reason, be causing some, though not all, JS to hang? Either way, just sent the request to Michael Dunlap, and will merge relevant PR's + tag a new release to see if this makes the bugs go away.

Contributor

shippy commented Oct 17, 2014

There are reasons to believe that our initial diagnosis was wrong: the only thing that doesn't load on the test deployment server is FontAwesome, namely http://development.shifts.yale.edu/assets/fontawesome-webfont.woff?v=4.2.0 and http://development.shifts.yale.edu/assets/fontawesome-webfont.ttf?v=4.2.0. This might be, for some reason, be causing some, though not all, JS to hang? Either way, just sent the request to Michael Dunlap, and will merge relevant PR's + tag a new release to see if this makes the bugs go away.

@shippy shippy closed this in #405 Oct 17, 2014

@njlxyaoxinwei njlxyaoxinwei reopened this Oct 28, 2014

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Oct 28, 2014

Contributor

Beta4 is rendering tooltips correctly on schedule boxes (just checked this with Casey). However, the font-awesome files are still not found. The correct url should be under development.shifts.yale.edu/stcdev/assets/ instead of development.shifts.yale.edu/assets/.
This can possibly be fixed by the official github page of font-awesome rails gem under Note when deploying to sub-domains. We need the production.rb to have action_controller.relative_url_root = "/stcdev" or the environment variable RAILS_RELATIVE_URL_ROOT to have that value. As Casey explained, Michael Dunlap provides his own production.rb when he deploys the instance.

If we still want to run the live instance as development, I believe we need whichever development.rb that Michael uses to have that line as well.

@shippy Can you specify these requirements to Michael?

Contributor

njlxyaoxinwei commented Oct 28, 2014

Beta4 is rendering tooltips correctly on schedule boxes (just checked this with Casey). However, the font-awesome files are still not found. The correct url should be under development.shifts.yale.edu/stcdev/assets/ instead of development.shifts.yale.edu/assets/.
This can possibly be fixed by the official github page of font-awesome rails gem under Note when deploying to sub-domains. We need the production.rb to have action_controller.relative_url_root = "/stcdev" or the environment variable RAILS_RELATIVE_URL_ROOT to have that value. As Casey explained, Michael Dunlap provides his own production.rb when he deploys the instance.

If we still want to run the live instance as development, I believe we need whichever development.rb that Michael uses to have that line as well.

@shippy Can you specify these requirements to Michael?

@shippy

This comment has been minimized.

Show comment
Hide comment
@shippy

shippy Nov 7, 2014

Contributor

Okay. In local testing, when assets are precompiled and server is run in staging, with relative URL stated as /stcdev (as per #413), the font-awesome resources are still loading without the relative-URL prepend.

I'm coming close to just requesting an after-script that will sed out all instances of the wrong URL.

Contributor

shippy commented Nov 7, 2014

Okay. In local testing, when assets are precompiled and server is run in staging, with relative URL stated as /stcdev (as per #413), the font-awesome resources are still loading without the relative-URL prepend.

I'm coming close to just requesting an after-script that will sed out all instances of the wrong URL.

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Nov 8, 2014

Contributor

I found some more possible solutions, just to throw one in here:
twbs/bootstrap-sass#533
We noticed that the bootstrap glyphicons aren't being referenced in the compiled CSS correctly with the prepend subdirectory either, so this might be a bigger issue with font assets in general. The above url suggest using

@import "bootstrap-sprockets";

before importing bootstrap so that the icons would work, as noted in the github page of bootstrap-sass as well.

In light of the above, I suggest we next try switching to font-awesome-sass gem and do

@import "font-awesome-sprockets";

and see if that fixes the issue.

Contributor

njlxyaoxinwei commented Nov 8, 2014

I found some more possible solutions, just to throw one in here:
twbs/bootstrap-sass#533
We noticed that the bootstrap glyphicons aren't being referenced in the compiled CSS correctly with the prepend subdirectory either, so this might be a bigger issue with font assets in general. The above url suggest using

@import "bootstrap-sprockets";

before importing bootstrap so that the icons would work, as noted in the github page of bootstrap-sass as well.

In light of the above, I suggest we next try switching to font-awesome-sass gem and do

@import "font-awesome-sprockets";

and see if that fixes the issue.

@thomasweng15

This comment has been minimized.

Show comment
Hide comment
@thomasweng15

thomasweng15 Nov 9, 2014

Contributor

It looks like the issue is not fixed in the font-awesome repo, but the issue poster is not even sure if it is a font-awesome issue or not: FortAwesome/font-awesome-sass#40

Contributor

thomasweng15 commented Nov 9, 2014

It looks like the issue is not fixed in the font-awesome repo, but the issue poster is not even sure if it is a font-awesome issue or not: FortAwesome/font-awesome-sass#40

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment

@njlxyaoxinwei njlxyaoxinwei changed the title from Create a `staging` environment to Font-awesome asset path in compiled application.css Nov 12, 2014

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Nov 12, 2014

Contributor

The shift instance running is from FApath branch.
The workaround is overriding the font import in application.css.scss L30

This is very bad code. But Rails v3.2 won't work with this otherwise. When we get to Rails 4 or higher, we need to investigate changing this using one of the methods listed in the previous comments, for example:

Contributor

njlxyaoxinwei commented Nov 12, 2014

The shift instance running is from FApath branch.
The workaround is overriding the font import in application.css.scss L30

This is very bad code. But Rails v3.2 won't work with this otherwise. When we get to Rails 4 or higher, we need to investigate changing this using one of the methods listed in the previous comments, for example:

@njlxyaoxinwei njlxyaoxinwei referenced this issue Nov 12, 2014

Merged

F apath #417

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Nov 12, 2014

Contributor

If hacking the source of Rails or sass-rails is preferable, here are some ways of how people are doing it:

Contributor

njlxyaoxinwei commented Nov 12, 2014

If hacking the source of Rails or sass-rails is preferable, here are some ways of how people are doing it:

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Nov 13, 2014

Contributor

As @orenyk pointed out today, the issue might be with the backported sprockets gem. Apparently we can just use the latest version with bootstrap-sass 3.1.1

In other words, do not use backports of sass-rails, sprockets and sprockets-rails.

It seems to work!!!

Contributor

njlxyaoxinwei commented Nov 13, 2014

As @orenyk pointed out today, the issue might be with the backported sprockets gem. Apparently we can just use the latest version with bootstrap-sass 3.1.1

In other words, do not use backports of sass-rails, sprockets and sprockets-rails.

It seems to work!!!

@njlxyaoxinwei

This comment has been minimized.

Show comment
Hide comment
@njlxyaoxinwei

njlxyaoxinwei Nov 13, 2014

Contributor

Deployed to http://development.shifts.yale.edu/stcdev and it works. This issue can finally be closed.

Contributor

njlxyaoxinwei commented Nov 13, 2014

Deployed to http://development.shifts.yale.edu/stcdev and it works. This issue can finally be closed.

@thoughtafter thoughtafter referenced this issue in jquery-ui-rails/jquery-ui-rails Jun 19, 2015

Closed

images in production subdirectory problem #54

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.