Patch #1186

JS should be cached in production mode to save bandwith and cpu

Added by Philippe Lafoucrière over 6 years ago. Updated almost 6 years ago.

Status:ClosedStart date:2008-05-06
Priority:LowDue date:
Assignee:-% Done:

100%

Category:-
Target version:-

Description

Attached in very small patch to allow caching the JS files in production mode.

add_cache_for_js_in_layout_base.diff Magnifier - Patch file to add cache for JS (580 Bytes) Philippe Lafoucrière, 2008-05-06 15:56


Related issues

Related to Defect #1821: failed to set repository Closed 2008-08-27

Associated revisions

Revision 1748
Added by Eric Davis about 6 years ago

Javascripts are now cached into a single file for downloads in production mode.

Thanks to Philippe Lafoucrière for the patch. (#1186)

Revision 1771
Added by Eric Davis about 6 years ago

Reverting commit r1748. Some environments are not allowing the cached file to
write to public, causing all JavaScript to fail.

Javascripts are now cached into a single file for downloads in production mode.

#1186

History

#1 Updated by Eric Davis about 6 years ago

  • Status changed from New to Resolved
  • Assignee set to Eric Davis
  • % Done changed from 0 to 100

Applied patch in r1748. Javascript files will now be cached as a single file.

#2 Updated by Philippe Lafoucrière about 6 years ago

Be careful if later you want to use other javascript lib than the ones packaged with rails. I had surprises where some libs are requesting prototype, and they were not able to detect it any more with the cache mode.
To explain the cache mode in one line, all js files are concatened in one single file, easily compressable and cacheable.

Thanks

#3 Updated by Jan Losinski about 6 years ago

For me this Patch wont work.
If I've applied it there are no actions on the comment buttons of the issues, also the context menu at the issue list will not be available.
If I've removed it all the things works fine.

#4 Updated by Eric Davis about 6 years ago

Philippe Lafoucrière wrote:

Be careful if later you want to use other javascript lib than the ones packaged with rails. I had surprises where some libs are requesting prototype, and they were not able to detect it any more with the cache mode.

Can you provide an example? I still see the Prototype object:

>>> Prototype.Version
"1.6.0.1" 

Jan Losinski wrote:

For me this Patch wont work.
If I've applied it there are no actions on the comment buttons of the issues, also the context menu at the issue list will not be available.
If I've removed it all the things works fine.

Can you provide me your browser version and Operating system version? The context menu and issue links are working fine for me in Firefox. Also make sure you've cleared the browser cache.

#5 Updated by Philippe Lafoucrière about 6 years ago

I know starbox (http://www.nickstakenburg.com/projects/starbox/) at least won't work in this case (all js compacted in one all.js file).

Thx
Philippe

#6 Updated by Jan Losinski about 6 years ago

Eric Davis wrote:

Can you provide me your browser version and Operating system version? The context menu and issue links are working fine for me in Firefox. Also make sure you've cleared the browser cache.

The cache was cleared, the Problem exist until I remove :cache => true
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071618 Iceweasel/3.0.1 (Debian-3.0.1-1)
Rails: 2.1.0
Ruby: 1.8.2
libjs-prototype: 1.6.0.2

Rails runs in a apache-fcgid environment.

#7 Updated by Eric Davis about 6 years ago

Jan Losinski wrote:

The cache was cleared, the Problem exist until I remove :cache => true
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071618 Iceweasel/3.0.1 (Debian-3.0.1-1)
Rails: 2.1.0
Ruby: 1.8.2
libjs-prototype: 1.6.0.2

Rails runs in a apache-fcgid environment.

I tested with the exact same browser and the context menu is working for me. In fact the context menu isn't included in the cached JavaScript so it shouldn't be affected at all.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071618 Iceweasel/3.0.1 (Debian-3.0.1-1)

#8 Updated by Ralph Lange about 6 years ago

I'm having the same problem: upgrading from r1747 to r1748 breaks a bunch of things in my installation:
  • Wiki formatting buttons disappear (for project descriptions, issues, comments...)
  • The preview link does not work (when creating or commenting an issue)
  • Issue filtering does no work: parts of filter expressions are missing, adding filters does not work, listing all issues (including closed) does not work, ...

I tried migrating the db, clearing the redmine cache and clearing the browser cache with no result.

Removing ":cache => true" puts everything back to normal.

Rails 2.1.0, ruby 1.8.5
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

#9 Updated by Jean-Philippe Lang about 6 years ago

I think the problem is due to the fact that your application can't write all.js in /public/javascripts folder because the app doesn't have write access on this repository. And thus, all javascripts are unavailable.

I personnally use this cache technique for a while here on redmine.org but everyone may not want to give write access to the app on the /public folder. So IMHO, this patch should be reverted.

#10 Updated by Jan Losinski about 6 years ago

Jean-Philippe Lang wrote:

I think the problem is due to the fact that your application can't write all.js in /public folder because the app doesn't have write access on this repository.

On my Box, all.js exist in /public/javascripts and RoR can write to it, but it's an empty file.

#11 Updated by Philippe Lafoucrière about 6 years ago

Ok, seeing all the problems this patch is raising, and the very little improvement, we can clearly reject the patch. Sorry for that guys.

#12 Updated by Eric Davis about 6 years ago

  • Target version deleted (0.8)

Jean-Philippe Lang wrote:

I think the problem is due to the fact that your application can't write all.js in /public/javascripts folder because the app doesn't have write access on this repository. And thus, all javascripts are unavailable.

Ah, didn't even think about that since my Redmine runs as the user who owns the files. So it was able to write to public.

Philippe Lafoucrière wrote:

Ok, seeing all the problems this patch is raising, and the very little improvement, we can clearly reject the patch. Sorry for that guys.

Don't worry about it, that's what trunk is for, trying out new features. I tested it myself and it worked great in my environment so I committing the patch.

I've reverted the commit. Can everyone who had an issue please update to r1771 and see if the problem is reverted. Sorry for the hassle.

#13 Updated by Paul Rivier about 6 years ago

Eric Davis wrote:

I've reverted the commit. Can everyone who had an issue please update to r1771 and see if the problem is reverted. Sorry for the hassle.

If the problem may occur on some installations, and is server side configuration issue, it does not make the feature proposed unusable for everybody. Can't it just be let as an option for site administrator ?

#14 Updated by Richard Hurt about 6 years ago

It looks like r1786 turned this back on somehow and my installation is broken. Can we get this turned back off please or is there some other fix in place that allows it to be toggled on/off?

#15 Updated by Norbert Wenzel about 6 years ago

Has this been turned on again in rev1794? I was just wondering what those bugs were, which occured every now and then, and disappeared after reloading. I had to change the folder permissions for "javascripts" and now Redmine is working with JS support again.

#16 Updated by Eric Davis about 6 years ago

Richard Hurt wrote:

It looks like r1786 turned this back on somehow and my installation is broken. Can we get this turned back off please or is there some other fix in place that allows it to be toggled on/off?

The merge from the hooks branch in r1786 pulled in the bug. If you update to r1795, I've backed it out.

#17 Updated by Richard Hurt about 6 years ago

Eric Davis wrote:

Richard Hurt wrote:

It looks like r1786 turned this back on somehow and my installation is broken. Can we get this turned back off please or is there some other fix in place that allows it to be toggled on/off?

The merge from the hooks branch in r1786 pulled in the bug. If you update to r1795, I've backed it out.

Thanks, that did the trick.

Later...
Richard

#18 Updated by Eric Davis almost 6 years ago

  • Status changed from Resolved to Closed
  • Assignee deleted (Eric Davis)

Closing, we can revisit caching later as part of a more comprehensive optimization strategy.

Also available in: Atom PDF