Body: <p>If I enable asset caching in CiviCRM everything works fine. If I disable it, the administration menu is gone from the top to a list that's beneath the page content and a lot of JS is broken too.</p>
  
  <p>The reason for the broken JS (and maybe the broken CSS too), is (at least for some scripts) that in the files that are on my installation in /sites/default/files/css/ and /sites/default/files/js/ is somewhere in the middle of the JS code (and the css code) some PHP code, namely:</p>
  
  <pre><code>&lt;?php
  
  /**
   * @file
   * The PHP page that serves all page requests on a Drupal installation.
   *
   * The routines here dispatch control to the appropriate handler, which then
   * prints the appropriate page.
   *
   * All Drupal code is released under the GNU General Public License.
   * See COPYRIGHT.txt and LICENSE.txt.
   */
  
  /**
   * Root directory of Drupal installation.
   */
  define('DRUPAL_ROOT', getcwd());
  
  require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  menu_execute_active_handler();
  ;
  </code></pre>
  
  <p>When asset caching is enabled, there are different css and js files used, that are beneath the "image uplod url". And they seem to work properly.</p>
  
  <p>I would like to disable asset caching, because I want to provide the images from a different server, so that they are loaded faster, to save bandwidth to our CiviCRM server and to have not so much load on the server, which has a lot of work, when sending mailings with images, tracking links and providing petitions by CiviCRM.</p>
  
  <p>That asset caching is making use of the image uploud url, is imho not really intuitive, but thats a different story.</p>
  
  <p>Does anybody have an idea what the reason is and how to solve this?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:12:16.067Z
Comments.Text: Maybe I should add, that this seems to be connected to the upgrade of Drupal core from 7.63 to 7.67 or views from 7.x-3.20 to 7.x-3.23.
Comments.UserDisplayName: Harald Balluch
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:29:56.450Z
Comments.Text: Does it look like this? https://civicrm.stackexchange.com/questions/30547/menu-problem-with-civicrm-5-13-2
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:34:58.740Z
Comments.Text: Well, yes it does in principle.
Comments.UserDisplayName: Harald Balluch
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:40:28.257Z
Comments.Text: Their solution sounds reasonable to me, if they use asset caching and if there was something wrong with the image upload url, because as I said, asset caching seems to use the image upload url to store css and js files.
  In my case everything works fine as long as asset caching is enabled and there is no difference, if I use absolute or relative image upload urls.
Comments.UserDisplayName: Harald Balluch
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:46:54.707Z
Comments.Text: Sorry I don't have an answer - it sounds like at some point in the chain the contents of index.php is being sucked into the output instead of executed, so instead of js/css output you get that.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T20:58:39.113Z
Comments.Text: Do you know, which routine updates the css and js files, if asset caching is disabled. Emptying caches doesn't trigger new css and js files. The files have different time stamps so they don't seem to be created and updated together at once.
Comments.UserDisplayName: Harald Balluch
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-26T21:46:01.097Z
Comments.Text: Regarding the problem with the menu that is simply on the bottom of the page instead of being styled as a menu bar on top, I found out, that I get "@import url("https://my.domain.com/index.php?pv9pug");" instead the proper path to the css file with the styling information of the admin menu bar. So the css isn't broken because of this strange php code inside, but because it is not linked properly.
  The JS for example of the system status page brakes because of the php part.
Comments.UserDisplayName: Harald Balluch
Tags: <javascript><css><cache>
Title: Civicrm on Drupal: broken JS and CSS or Asset Caching enabled
ThreadText: # Civicrm on Drupal: broken JS and CSS or Asset Caching enabled
  
  (Asked by: username_0 on 2019-07-26)
  
  If I enable asset caching in CiviCRM everything works fine. If I disable it, the administration menu is gone from the top to a list that's beneath the page content and a lot of JS is broken too.
  The reason for the broken JS (and maybe the broken CSS too), is (at least for some scripts) that in the files that are on my installation in /sites/default/files/css/ and /sites/default/files/js/ is somewhere in the middle of the JS code (and the css code) some PHP code, namely:
  
  When asset caching is enabled, there are different css and js files used, that are beneath the "image uplod url". And they seem to work properly.
  I would like to disable asset caching, because I want to provide the images from a different server, so that they are loaded faster, to save bandwidth to our CiviCRM server and to have not so much load on the server, which has a lot of work, when sending mailings with images, tracking links and providing petitions by CiviCRM.
  That asset caching is making use of the image uploud url, is imho not really intuitive, but thats a different story.
  Does anybody have an idea what the reason is and how to solve this?
  
  **Tags:** javascript, css, cache
  
  > **Comments:**
  > **username_0**: Maybe I should add, that this seems to be connected to the upgrade of Drupal core from 7.63 to 7.67 or views from 7.x-3.20 to 7.x-3.23.  
  > **username_1**: Does it look like this? https://civicrm.stackexchange.com/questions/30547/menu-problem-with-civicrm-5-13-2  
  > **username_0**: Well, yes it does in principle.  
  > **username_0**: Their solution sounds reasonable to me, if they use asset caching and if there was something wrong with the image upload url, because as I said, asset caching seems to use the image upload url to store css and js files. In my case everything works fine as long as asset caching is enabled and there is no difference, if I use absolute or relative image upload urls.  
  > **username_1**: Sorry I don't have an answer - it sounds like at some point in the chain the contents of index.php is being sucked into the output instead of executed, so instead of js/css output you get that.  
  > **username_0**: Do you know, which routine updates the css and js files, if asset caching is disabled. Emptying caches doesn't trigger new css and js files. The files have different time stamps so they don't seem to be created and updated together at once.  
  > **username_0**: Regarding the problem with the menu that is simply on the bottom of the page instead of being styled as a menu bar on top, I found out, that I get "@import url("https://my.domain.com/index.php?pv9pug");" instead the proper path to the css file with the styling information of the admin menu bar. So the css isn't broken because of this strange php code inside, but because it is not linked properly. The JS for example of the system status page brakes because of the php part.  
  
  ---
  
  ## 0 answers
  
  