Answers.Body: <p>OK. So I've found what I think is a pretty serious problem with the current Civi CRM setup and multisites...</p>
  
  <p>There's an entire section up the top of civicrm.settings.php that has these lines:</p>
  
  <pre><code>$civicrm_paths['wp.frontend.base']['url'] = (URL path)
  $civicrm_paths['wp.backend.base']['url'] = (URL path to admin)
  $civicrm_setting['URL Preferences']['userFrameworkResourceURL'] =(URL path) to civicrm
  </code></pre>
  
  <p>The paths are hardcoded to the main site URL.</p>
  
  <p>This seems to be what's causing these problems I'm having. Because if I change it using the code below, then it appears to work again.</p>
  
  <p>=======================</p>
  
  <pre><code>if(function_exists('is_multisite') &amp;&amp; function_exists('home_url')) {
    $url = home_url();
  }
  else {
    $protocol = strstr('HTTPS', $_SERVER['SERVER_PROTOCOL']) ? 'https://' : 'http://';
    $url = $protocol . $_SERVER['SERVER_NAME'];
  }
  
  
  // Additional settings generated by installer:
  $civicrm_paths['wp.frontend.base']['url'] = $url.'/';
  $civicrm_paths['wp.backend.base']['url'] = $url.'/wp-admin/';
  $civicrm_setting['URL Preferences']['userFrameworkResourceURL'] = $url.'/wp-content/plugins/civicrm/civicrm';
  </code></pre>
  
  <p>===================</p>
  
  <p>But is this a good idea? I don't know...</p>
  
  <p>Norm</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-07-13T23:56:13.973Z
Answers.Text: Yes, this strikes me as the right approach.  The issue isn't actually CORS, but that the subdomain is generating the wrong URLs.
  
  Multi-site is a little-used and very advanced feature, and most folks who use it expect to do this kind of tweaking.  I'm sorry to see you struggling here and in chat, but it's good to have a fresh set of eyes to push the documentation etc. forward. More experienced folks fix the quirks for their site and move on.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-07-13T09:43:20.750Z
Answers.LastActivityDate: 2018-07-13T09:43:20.750Z
Answers.UserDisplayName: Norman Cates
Body: <p>I've been having problems with a new install of CiviCRM 5.3 in Multisite on Wordpress.</p>
  
  <p>It seems to be working properly in the main site. </p>
  
  <p>My intent is to have one CiviCRM database that works across all the subsites, sharing the contact data.</p>
  
  <p>On the subsites, when I go to the CiviCRM dashboard, I get the dreaded Network Error pop up. IN the Web Developer console it shows this error:</p>
  
  <p>Access to Font at '<a href="https://dev.domain.nz/wp-content/plugins/civicrm/civicrm/bower_components/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0" rel="nofollow noreferrer">https://dev.domain.nz/wp-content/plugins/civicrm/civicrm/bower_components/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0</a>' from origin '<a href="https://crew.dev.domain.nz" rel="nofollow noreferrer">https://crew.dev.domain.nz</a>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '<a href="https://crew.dev.domain.nz" rel="nofollow noreferrer">https://crew.dev.domain.nz</a>' is therefore not allowed access.</p>
  
  <hr>
  
  <p>And the default and the Activities dashlets just spin with the CiviCRM logos.</p>
  
  <p>If I remove those dashlets from the dashboard, then the problem goes away.</p>
  
  <p>I would of course like to keep them.</p>
  
  <p>I have added </p>
  
  <p>Header set Access-Control-Allow-Origin "*"</p>
  
  <p>to my .htaccess file for Wordpress. This did not help.</p>
  
  <p>I'm sure that this isn't 100% a CiviCRM problem, but I'm not sure where else to ask...</p>
  
  <p>Thanks,
  Norm</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-07-13T09:33:33.123Z
Comments.Text: So to test, I installed a fresh Wordpress and CIVCRM with the absolute minimum changes from the default. I enabled Multisite, and two subsites based on sub-domains. And I got the exact same behavior.
Comments.UserDisplayName: Norman Cates
Tags: <wordpress><multisite>
Title: Getting CORS error from CiviCRM dashboard dashlets
ThreadText: # Getting CORS error from CiviCRM dashboard dashlets
  
  (Asked by: username_0 on 2018-07-13)
  
  I've been having problems with a new install of CiviCRM 5.3 in Multisite on Wordpress.
  
  It seems to be working properly in the main site.
  
  My intent is to have one CiviCRM database that works across all the subsites, sharing the contact data.
  
  On the subsites, when I go to the CiviCRM dashboard, I get the dreaded Network Error pop up. IN the Web Developer console it shows this error:
  
  Access to Font at '<https://dev.domain.nz/wp-content/plugins/civicrm/civicrm/bower_components/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0>' from origin '<https://crew.dev.domain.nz>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '<https://crew.dev.domain.nz>' is therefore not allowed access.
  
  ---
  
  And the default and the Activities dashlets just spin with the CiviCRM logos.
  
  If I remove those dashlets from the dashboard, then the problem goes away.
  
  I would of course like to keep them.
  
  I have added
  
  Header set Access-Control-Allow-Origin "\*"
  
  to my .htaccess file for Wordpress. This did not help.
  
  I'm sure that this isn't 100% a CiviCRM problem, but I'm not sure where else to ask...
  
  Thanks,
  Norm
  
  **Tags:** wordpress, multisite
  
  > **Comments:**
  > **username_0**: So to test, I installed a fresh Wordpress and CIVCRM with the absolute minimum changes from the default. I enabled Multisite, and two subsites based on sub-domains. And I got the exact same behavior.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-07-13. Score: 2
  
  OK. So I've found what I think is a pretty serious problem with the current Civi CRM setup and multisites...
  
  There's an entire section up the top of civicrm.settings.php that has these lines:
  
  ```
  $civicrm_paths['wp.frontend.base']['url'] = (URL path)
  $civicrm_paths['wp.backend.base']['url'] = (URL path to admin)
  $civicrm_setting['URL Preferences']['userFrameworkResourceURL'] =(URL path) to civicrm
  
  ```
  
  The paths are hardcoded to the main site URL.
  
  This seems to be what's causing these problems I'm having. Because if I change it using the code below, then it appears to work again.
  
  =======================
  
  ```
  if(function_exists('is_multisite') && function_exists('home_url')) {
    $url = home_url();
  }
  else {
    $protocol = strstr('HTTPS', $_SERVER['SERVER_PROTOCOL']) ? 'https://' : 'http://';
    $url = $protocol . $_SERVER['SERVER_NAME'];
  }
  
  // Additional settings generated by installer:
  $civicrm_paths['wp.frontend.base']['url'] = $url.'/';
  $civicrm_paths['wp.backend.base']['url'] = $url.'/wp-admin/';
  $civicrm_setting['URL Preferences']['userFrameworkResourceURL'] = $url.'/wp-content/plugins/civicrm/civicrm';
  
  ```
  
  ===================
  
  But is this a good idea? I don't know...
  
  Norm
  
  > **Comments:**
  > **username_1**: Yes, this strikes me as the right approach.  The issue isn't actually CORS, but that the subdomain is generating the wrong URLs.  Multi-site is a little-used and very advanced feature, and most folks who use it expect to do this kind of tweaking.  I'm sorry to see you struggling here and in chat, but it's good to have a fresh set of eyes to push the documentation etc. forward. More experienced folks fix the quirks for their site and move on.  
  
  ---
  
  