Answers.Body: <p>Looking at <code>CRM/Extension/Browser.php</code> where that error is generated, I would expect it to show a URL between the <code>at</code> and <code>could</code> in your message.  So Civi isn't calculating the repository URL.</p>
  <p>Tracing the code a bit, it seems that the URL should be calculated in <code>CRM_Extension_System::getRepositoryUrl()</code>, which pulls it from the <code>ext_repo_url</code> setting.</p>
  <p>Here's what I would try, in order:</p>
  <ul>
  <li>Clear the CiviCRM cache, that's probably the issue anyway.</li>
  <li>Confirm that <code>&lt;civiroot&gt;/settings/Extension.setting.php</code> defines <code>ext_repo_url</code> with the default value of <code>https://civicrm.org/extdir/ver={ver}|cms={uf}</code>.</li>
  <li>Check the <code>civicrm_setting</code> table for a record with a <code>name</code> of <code>ext_repo_url</code>.  If one exists, this is overriding the default; remove it.</li>
  <li>Alternatively, add a setting (via API Explorer, or in civicrm.settings.php - see <a href="https://docs.civicrm.org/sysadmin/en/latest/customize/settings/" rel="nofollow noreferrer">Override settings in the docs</a>) to set <code>ext_repo_url</code> to
  <code>https://civicrm.org/extdir/ver={ver}|cms={uf}</code>.  This should force the correct URL to be generated.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-17T01:03:13.117Z
Answers.Text: Thank you so much. You're a life saver.
Answers.UserDisplayName: Andrew
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-17T01:04:25.797Z
Answers.Text: I ended up updating the setting file, which fixed the issue for now. There is clearly something else going on, so more investigation is required on my part. Will report back if I find anything.
Answers.UserDisplayName: Andrew
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-18T03:19:27.460Z
Answers.Text: Update: Turns out most of my weirdness was coming from strange CIVICRM_TEMPLATE_COMPILEDIR behaviour. I did not have a specific directory specified in the setting file, so a replica civicrm directory structure was being created with ONLY the templates_c directory being filled with files (the remainder of the files including extensions were located in another directory). I manually specified a location in the setting file and all the weird messages and unstable behaviour disappeared. Hope this helps someone.
Answers.UserDisplayName: Andrew
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-17T00:31:00.473Z
Answers.LastActivityDate: 2021-02-17T15:20:10.413Z
Answers.LastEditDate: 2021-02-17T15:20:10.413Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I have upgraded to CiviCRM 5.34 and things seem to have gone astray. When loading the extensions page (Administer -&gt; Systems Settings -&gt; Extensions) the following error message is displayed:</p>
  <blockquote>
  <p>Extension download error The CiviCRM public extensions directory at
  could not be contacted - please check your webserver can make external
  HTTP requests or contact CiviCRM team on CiviCRM forum.</p>
  </blockquote>
  <p>I cannot refresh the extensions list, not install any new extensions (I guess since the catalogue cannot be reached). I fired up a terminal into the server and Curl seems to work, and I cannot see any PHP options which may prevent connections.</p>
  <p>Any help here?</p>
  
Tags: <extension>
Title: Upgraded to CiviCRM 5.34.0 and extensions broke
ThreadText: # Upgraded to CiviCRM 5.34.0 and extensions broke
  
  (Asked by: username_0 on 2021-02-17)
  
  I have upgraded to CiviCRM 5.34 and things seem to have gone astray. When loading the extensions page (Administer -> Systems Settings -> Extensions) the following error message is displayed:
  
  > Extension download error The CiviCRM public extensions directory at
  > could not be contacted - please check your webserver can make external
  > HTTP requests or contact CiviCRM team on CiviCRM forum.
  
  I cannot refresh the extensions list, not install any new extensions (I guess since the catalogue cannot be reached). I fired up a terminal into the server and Curl seems to work, and I cannot see any PHP options which may prevent connections.
  
  Any help here?
  
  **Tags:** extension
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-02-17. Score: 2 | Accepted answer
  
  Looking at `CRM/Extension/Browser.php` where that error is generated, I would expect it to show a URL between the `at` and `could` in your message. So Civi isn't calculating the repository URL.
  
  Tracing the code a bit, it seems that the URL should be calculated in `CRM_Extension_System::getRepositoryUrl()`, which pulls it from the `ext_repo_url` setting.
  
  Here's what I would try, in order:
  
  * Clear the CiviCRM cache, that's probably the issue anyway.
  * Confirm that `<civiroot>/settings/Extension.setting.php` defines `ext_repo_url` with the default value of `https://civicrm.org/extdir/ver={ver}|cms={uf}`.
  * Check the `civicrm_setting` table for a record with a `name` of `ext_repo_url`. If one exists, this is overriding the default; remove it.
  * Alternatively, add a setting (via API Explorer, or in civicrm.settings.php - see [Override settings in the docs](https://docs.civicrm.org/sysadmin/en/latest/customize/settings/)) to set `ext_repo_url` to
    `https://civicrm.org/extdir/ver={ver}|cms={uf}`. This should force the correct URL to be generated.
  
  > **Comments:**
  > **username_0**: Thank you so much. You're a life saver.  
  > **username_0**: I ended up updating the setting file, which fixed the issue for now. There is clearly something else going on, so more investigation is required on my part. Will report back if I find anything.  
  > **username_0**: Update: Turns out most of my weirdness was coming from strange CIVICRM_TEMPLATE_COMPILEDIR behaviour. I did not have a specific directory specified in the setting file, so a replica civicrm directory structure was being created with ONLY the templates_c directory being filled with files (the remainder of the files including extensions were located in another directory). I manually specified a location in the setting file and all the weird messages and unstable behaviour disappeared. Hope this helps someone.  
  
  ---
  
  