Question: What could be causing the ext_repo_url setting value to be empty when running in the browser, though it appears to be correct when running in cv?

Under civicrm 5.35.2, if I visit the Extensions page, I see this message:

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.

Notice that it says "extensions directory at could not", implying an empty value for the repo URL.

Things seem to work normally using cv:

  • At the command line I run cv api Extension.getremote, I get a full json array of remote extensions.
  • From the command line, the setting has what appears to be a correct value.
cv api setting.get | grep -i ext_repo_url  
"ext_repo_url": "https://civicrm.org/extdir/ver={ver}|cms={uf}",
  • I also tried a script with cv scr, and get what looks like correct output, like so:
$ cat /tmp/a.php
$a = CRM_Extension_System::singleton()->getBrowser()->getRepositoryUrl();
$ cv scr /tmp/a.php
string(51) "https://civicrm.org/extdir/ver=5.35.2|cms=WordPress"

But for content called from the browser, the repo setting appears to be empty. To test, I added this code to an existing extension:

function activityical_civicrm_pageRun(&$page) {
  $page_name = $page->getVar('_name');
$repo = CRM_Extension_System::singleton()->getBrowser()->getRepositoryUrl();
echo "<!-- page_name: $page_name -->\n";
echo "<!-- repo_url: $repo  -->\n";

And then I view the page source at https://REDACTED.example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fextensions&reset=1 , which says:

<!-- page_name: CRM_Admin_Page_Extensions -->
<!-- repo_url:  -->
<!DOCTYPE html>

Also tried:

  • cv flush and wp cache flush do not make any change in the above findings.
  • Is this a multidomain setup?
    – Demerit
    Apr 30, 2021 at 19:09
  • Nope, just one domain on this server.
    – TwoMice
    May 2, 2021 at 20:46
  • Is memcache active?
    – Aidan
    May 4, 2021 at 9:12
  • Aidan: nope, no memcache.
    – TwoMice
    May 4, 2021 at 20:53

1 Answer 1


Turns out this site was long ago upgraded from an older version that lacked global $civicrm_settings variable definition as called for in this (5-year-old) commit in civicrm.settings.php.tpl.

Simply adding that variable definition cleared up the problem immediately. (Naturally there were other important things to change in civicrm.settings.php, so of course if you have this problem, you've probably got others.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.