无法通过本地生产 Rails 3.1.3 服务器上的管道配置资产

发布于 12-27 17:09 字数 2020 浏览 6 评论 0原文

这个月,我从 Rails 3.0 升级到 Rails 3.1 - 这周我尝试以生产模式启动服务器 - 今天我遇到了困难!

我无法让我的生产环境服务器通过资产管道提供我的公共资产(JavaScript 和 CSS),除非我设置了 config.assets.compile = true我的environment.rb 文件,出于速度原因我显然不想这样做。

我有大量的 JS 和 CSS 文件,每个文件往往会在一两个不同的页面上使用。这意味着创建单个“清单”文件不适合我的使用,因为每个页面都需要稍微不同的东西。我还预计某些 CSS 不会很好地组合在一起。因此,我采取了“让它工作起来”的方法,希望稍后清理大量的 CSS / JS。

这是 Production.rb 文件:

Implicit::Application.configure do
  ...

  config.consider_all_requests_local       = false
  config.action_controller.perform_caching = true

  # I set this to true, as I am testing this locally, just running a local Thin server
  config.serve_static_assets = true

  config.assets.compress = true

  # Setting this to false removes the issue - but is SLOW
  config.assets.compile = true

  config.assets.digest = true

  # This is overkill - but does get EVERYTHING precompiled for now
  config.assets.precompile += %w( *.css *.js )

  config.action_dispatch.x_sendfile_header = nil
  ...
end

这对我来说是一个相当新的领域,所以我今天花了很多时间切换这些布尔值并停止/启动本地 Thin / Rails 服务器来尝试它们。但唯一能产生显着差异的值是编译标志。

我的 application.rb 文件几乎是标准的,其中有 config.assets.enabled = true 和 config.assets.initialize_on_precompile = false ,后者来自 Heroku 帖子(再次猜测)。

我有一个完全填充的 public/assets 目录,是使用 bundle exec rake assets:precompile 命令创建的,在我的旧笔记本电脑上运行大约需要 20 分钟(5 年) ,可能与“catch all”预编译正则表达式有关,尽管注释了该行,它仍然需要 10 分钟以上(!)

将编译标志设置为 true,我可以看到这些的副本在我的 /tmp/cache 目录中创建资产 - 这显然是应用程序创建自己的资产“编译副本”。

将编译标志设置为 false 时,我遇到了 jquery 的错误消息(在日志中,除非我将请求设置为本地,否则我会在渲染的错误页面上看到它)。 Reveal 未预编译。但是,当我访问 http://localhost:3000/assets/jquery.reveal.js 时,就会提供 javascript 文件。

导致此问题的应用程序布局行是:

<%= javascript_include_tag "application", "jquery.reveal" %>

我尝试将 jquery.reveal 更改为 jquery.reveal.js ,没有任何更改。删除它可以修复索引页,但 jquery.reveal 功能当然消失了!很明显,application.js 正在正确提供。我只是不明白为什么 jquery.reveal 不是,因为我可以在 public/assets 目录中看到预编译文件。

This month, I upgraded from Rails 3.0 to Rails 3.1 - this week I tried to launch the server in production mode - today I have hit a wall !

I am unable to get my production environment server to serve up my public assets (JavaScript and CSS) via the asset pipeline, unless I set config.assets.compile = truein my environment.rb file, which for speed reasons I obviously don't want to do.

I have a large number of JS and CSS files, each of which tends to get used on one or two different pages. This means creating a single "manifest" file doesn't fit my usage, as each page wants something slightly different. I also expect some of the CSS won't sit together nicely. Therefore I have gone down the approach of "just get it working", looking to tidy up the large quantity of CSS / JS later.

Here is the production.rb file:

Implicit::Application.configure do
  ...

  config.consider_all_requests_local       = false
  config.action_controller.perform_caching = true

  # I set this to true, as I am testing this locally, just running a local Thin server
  config.serve_static_assets = true

  config.assets.compress = true

  # Setting this to false removes the issue - but is SLOW
  config.assets.compile = true

  config.assets.digest = true

  # This is overkill - but does get EVERYTHING precompiled for now
  config.assets.precompile += %w( *.css *.js )

  config.action_dispatch.x_sendfile_header = nil
  ...
end

This is quite a new area for me, and so I've spent much of today toggling these booleans and stop/starting the local Thin / Rails server to try them out. But the only value that's made a solid difference is the compile flag.

My application.rb file is pretty much standard, and has config.assets.enabled = true and config.assets.initialize_on_precompile = false in it, the latter from a heroku post (and a guess, again).

I have a fully populated public/assets directory, created with the bundle exec rake assets:precompile command, that takes about 20 mins to run on my oldish laptop (5 years), probably something to do with that "catch all" precompile regex, although with that line commented it still takes over 10 mins (!)

With the compile flag set to true, I can see copies of these assets getting created in my /tmp/cache directory - this is clearly the application creating it's own "compiled copy" of the assets.

With the compile flag set to false, I am confronted with the error message (in the logs, unless I set requests to local, then I see it on the rendered error page) of jquery.reveal isn't precompiled. However, when I go to http://localhost:3000/assets/jquery.reveal.js the javascript file is served up.

The line of my application layout causing this is:

<%= javascript_include_tag "application", "jquery.reveal" %>

I have tried changing that jquery.reveal to jquery.reveal.js with no change. Removing it fixes the index page, except that the jquery.reveal functionality is gone of course ! So clearly the application.js is being served up correctly. I just can't figure out why jquery.reveal isn't, as I can see the precompiled files in the public/assets directory.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

深爱成瘾2025-01-03 17:09:35

这是一个有趣的问题,我认为可能存在两个错误 - 您链接的一个错误和另一个错误:文件被编译为错误的名称。可能值得尝试生成一个最小的测试用例,您可以将其与错误报告一起提交。

解决这个问题的方法 - 我怀疑这就是为什么很少有人遇到这个问题 - 是使用辅助清单(仅通过清单链接库似乎是一种不断发展的最佳实践)。

创建一个名为 home.js 的文件,并只需要该文件即可。

总的来说,这不是一个坏方法。这些额外的清单必须添加到预编译数组中(请参阅指南),并允许在多个页面或部分共享多个库,而不必每次都链接它们。

This is an interesting issue, and I think there may be two bugs - the one you've linked and another: the file is being being compiled to the wrong name. It might be worth trying to generate a minimal test case that you can submit with a bug report.

The workaround for this - and I suspect that this is why few people seem to have the problem - is to use a secondary manifest (linking libraries only via a manifest seems to be an evolving best-practice).

Create one called home.js and require just that one file to it.

This isn't a bad approach overall. These extra manifests have to be added to the precompile array (see the guide), and allow multiple libraries to be shared over several pages or sections without having to link them each time.

感情旳空白2025-01-03 17:09:35

在这里回答我自己的问题,但看起来可能是解析带有“句点”的资产(例如 jquery.reveal)时出现的错误

问题报告(https://github.com/rails/rails/issues/3398)报告了这一点并突出显示一次提交(https://github.com/sstephenson/sprockets/commit/4ba5b32764a9073671df5e77355df6ed2bb3d3c9)发生在Sprockets 2.0.3之后——rails 3.1.3依赖的默认版本。因此,升级 Sprocket 需要移至 3.2 稳定轨道 - 对于这个新手来说有点前沿!

但错误报告确实说这只发生在 config.assets.compile = true 时 - 而且我确实看到在我的代码中 jquery.reveal 被动态编译为 jquery-8fu。 ..8g.reveal.js(而不是 jquery.reveal-8fu...8g.js)。

所以也许这不是答案。至少我希望不是。但肯定会继续关注这个时期问题,因为据我所知,包含 CSS / JS 文件的“非时期”文件正在提供得很好。

Answering my own question here, but looks like it might be a bug in parsing assets with "periods" such as jquery.reveal

An issue report (https://github.com/rails/rails/issues/3398) reports this and highlights a commit (https://github.com/sstephenson/sprockets/commit/4ba5b32764a9073671df5e77355df6ed2bb3d3c9) which occurs just after Sprockets 2.0.3 - the default version that rails 3.1.3 relies upon. Upgrading Sprocket would therefore involve moving onto 3.2-stable rails - a bit bleeding edge for this newbie !

But the bug report does say this only occurs when config.assets.compile = true - and I did see whilst that was the case in my code that jquery.reveal was being dynamically compiled to jquery-8fu...8g.reveal.js (instead of jquery.reveal-8fu...8g.js).

So perhaps this ISN'T the answer. At least I hope it isn't. But will certainly continue to look at this period issue, as the "non-period" containing CSS / JS files are being served up just fine, as far as I can tell.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文