More issues with nginx about decko

[ethn]

Are you trying to run this with a relative root (gamesdb)?

Because if so you will need to configure that.

Here's the relevant Rails documentation for how to do that: http://guides.rubyonrails.org/configuring.html#deploy-to-a-subdirectory-relative-url-root

Short version, you have some options:
config.relative_url_root = "/gamesdb" (eg in config/application.rb)
RAILS_RELATIVE_URL_ROOT = "/gamesdb" (as an environmental variable)
in your passenger configuration (.htaccess): RackBaseURI = "/gamesdb"

more recent passenger configuration may be using a different option, but it's something like that...

[Nemquae]

Yes, and that fixed it (mostly).

The last part we're stuck on are the icons (and I presume other assets) that are still looking for the root. Everything else about the site seems to be working.

Here are the errors:

MaterialIcons-Regular.woff2 Failed to load resource: the server responded with a status of 404 (Not Found)
ui-bg_flat_75_ffffff_40x100.png Failed to load resource: the server responded with a status of 404 (Not Found)
MaterialIcons-Regular.woff Failed to load resource: the server responded with a status of 404 (Not Found)
MaterialIcons-Regular.ttf Failed to load resource: the server responded with a status of 404 (Not Found)
DevTools failed to parse SourceMap: http://learning.sd.polyu.edu.hk/gamesdb/files/:all_script_machine_output/bootstrap.min.js.map

We tried clearing the cache and restarting nginx/passenger a few times, no luck. Also, after we added memcached it's still not fast enough. I know you mentioned xsendfile and expires, so we're looking into those, but were there any other nginx specific optimizations that you could recommend?

Edit: Just to be clear, for the relative root we modified application.rb, the environment variable, and the .htaccess file.

[ethn]

for the performance problem, are you definitely running in production? It's worth checking in boot.rb to make suer that RAILS_ENV is being set to production. And, although this should be the default, I might add config.view_cache = true to your application.rb.

After that, I'd look to see what is slow: is it the files or the application requests.

Re the icons, I would try going to /:admin and clearing the machine cache. If that works, great. If not, we may need to fix a bug. That could happen very quickly, but if you're willing to confirm first, that would be appreciated!

[Nemquae]

So it turns out that while that line was set to production, in the nginx config file we still had development set, so we were in development. We set config.view_cache = true and deleted the machine cache but that didn't bring back the icons. In production almost nothing loads (just the html), so there very well could be a bug with relative roots.

I should note that we're using Decko 0.3.6 because 0.3.7 seems to depend on the cardname gem 0.3.7 which has been released yet.

[ethn]

Re production - at least that explains the performance.

Re assets, I would try clearing the machine cache again in production (there's a link in /:admin, but you can use /update/:admin?task=clear_machine_cache). Note that even though we call it a "cache" this removes noncanonical copies stored in the database, so, eg, restarting memcache doesn't fix this.

If this is loading bad CSS / JS, could you send me the urls it's trying to load?

Re cardname, thanks for the catch. 0.3.7 is there now. There was a snag in the last deployment. I fixed the underlying issue and thought I pushed the gem by hand, but I forgot the last step.

Re the MaterialIcons issue, I suspect that might persist even after the cache clearing. I'll get a fix into 0.3.8, which we will get out this week.

[Nemquae]

So I started from scratch with the 0.3.8 version, completely deleting the gamesdb folder, dropping all databases, and then creating a new install and seeding it. Before and after, I deleted the machine cache and updated Decko.

The results are the same, so I'm thinking that there must be an issue from our side. It seems like the relative paths for assets aren't being updated correctly between decko/passenger/nginx, but at this point I'm at a loss for how. Below are some examples of the asset URLs that fail to load, as well as our current nginx and decko config files. The logs are also attached. Any help would be greatly appreciated.

http://learning.sd.polyu.edu.hk/assets/fonts/MaterialIcons-Regular.woff2
http://learning.sd.polyu.edu.hk/assets/fonts/MaterialIcons-Regular.woff
http://learning.sd.polyu.edu.hk/assets/fonts/MaterialIcons-Regular.ttf
http://learning.sd.polyu.edu.hk/assets/tinymce/themes/modern/theme.min.js

DevTools failed to parse SourceMap: http://learning.sd.polyu.edu.hk/gamesdb/files/~1834/bootstrap.min.js.map

nginx.conf.txt

application.rb.txt
boot.rb.txt
database.yml.txt

development.log
production.log

[ethn]

We're putting out 0.3.9 (today, I hope), which finally resolves the MaterialIcons issues. You'll have to clear the machine cache, but I've tested it and it appears to work.

The DevTools issue is not really an issue; that's a url that only gets requested when you're using Chrome DevTools and those tools are hunting for a js map. We don't have a js map at that url, but the url passes off as a real one, and Decko returns a standard js file. I'd like to fix it, but it shouldn't even get requested in normal usage, much less cause any problems.

I haven't been able to reproduce the tinymce request yet. Does that load on every page? Did you configure tinymce in anyway? Does anything appear not to be working?

I'm hoping things will be working pretty well for you from 0.3.9. I did just add a story to our tracker in hopes of making this much easier. Remaining work:

1. make it so that any of these configuration options works (right now you need at least the environmental variable and the application config.)
2. fix the hard coded links in *header and *main menu
3. update documentation!!

Anything else you're aware of?

[Nemquae]

Ok, great so that did solve the MaterialIcons issues. I had to delete the entire gamesdb folder again, but after upgrading and deleting the machine cache the icons are there. Thanks for that.

The problem with tinymce is still present, however. I didn't make any change to the configuration for tinymce, so this is straight out of the box. The error happens on any page that tries to load tinymce, such as when trying to create new cards or editing existing cards. When it happens, the editor simply doesn't load, with a blank area under the card content label where it should be.

I did manage to get it to work on one page while I was digging into the error: http://learning.sd.polyu.edu.hk/gamesdb/script_tinymce+*all+*script+*machine_cache

I'm not sure why that card's content can be edited in tinymce while others can't. I found it while searching for references to tinymce's themes. There's a line where it looks like the tinymce script references the document base uri path or constructs the themes from that path. Maybe that's the source of the error?

[ethn]

I think I found and fixed it, and in the process I spotted some other potential relative base issues and have improved our API to prevent further problems. Given my plate, I'm guessing it will take until Monday to get this fully implemented, approved and released, but it's on its way. Thanks for your patience!

[ethn]

v0.3.10 (released yesterday) should resolve the tinyMCE problem!

[Nemquae]

Thanks. I've tested it now and tinyMCE works except for one last issue. When I tried to press submit for a new card, nothing happens (except for a flash for the submit button). Here's the error:

Failed to load resource: the server responded with a status of 404 (Not Found)
1519102853.js:5 POST http://learning.sd.polyu.edu.hk/gamesdb/gamesdb/card/create?main=&is_main=true&slot%5Bview%5D=new&slot%5Bnest_name%5D=_main&slot%5Bnest_syntax%5D=_main%7Copen&slot%5Bmain_view%5D=true&slot%5Bmain%5D=true&slot%5Bhome_view%5D=open 404 (Not Found)

It may be that you were a bit overzealous appending relative paths there, since there's two gamesdb references. I tried disabling a few things in Nginx config, but no luck.

[ethn]

ARG. Thanks for the catch. Ruby was converting the path once, and then javascript was converting it again. I tweaked things so javascript won't add roots to any absolute paths (and then checked to make sure everything we need it to is relative).

In the process I caught a file uploading call that would have broken and patched it. I'm sorry this is taking so long, but I'm happy we're finally getting some systematic root handling in place.

I'll get 0.3.11 out as soon as my collaborator reviews the PR (#168). We always review each others' code, though clearly it's not fully keeping me from sneaking some mistakes through! ;)

Thanks yet again for being so patient.

[ethn]

OK, 0.3.11 is out!

I'm going to go ahead and close this issue, since we're not actually talking about nginx any more, but obviously open another if needed!