jsDelivr options broken

I can confirm the same behavior.

Confirmed, same issue here.

This is actually an issue in the current dev branch.

Same problem for me...

The problem is that jsDelivr started calling Bootstrap "twitter-bootstrap" instead of "bootstrap".

Patch attached.

Same problem for me.

Temporary workaround is to use another CDN Provider set under Custom:

//maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css
//maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js
//maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.css
//maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.js

Change 3.3.4 in above to your preferred version.

I can confirm that using this CDN does work for me.

Patch in #6 works for me. No need for the workaround I gave.

FYI - If you've saved your theme settings while it was broken, you may also need to go back and correct the cdn settings after applying the patch.

This happened due to a regression introduced in jsDelivr's API v1 (likely due to work on v2). I have filed an issue with them: https://github.com/jsdelivr/api/issues/94

The real "problem" is that the "bootstrap" alias (provided by BootstrapCDN) is no longer being picked up (by jsDelivr API v1). "twitter-bootstrap" has always existed.

I'm tempted to mark this as "Closed (won't fix)" or "Closed (works as designed)" and just wait for them to fix their mistake (and to wait for v2), but this is a relatively minor change. I will commit shortly.

FWIW, the "bootstrap" alias has been fixed and is back in v1: http://api.jsdelivr.com/v1/bootstrap/libraries?name=bootstrap

@markcarver: Thanks for the quick response!

Unfortunately, the commit you made does not work.

Take a look at line 169:

${$data['name']}[$asset['version']] = $asset['files'];

And here it is in context:

  // Extract the raw asset files from the JSON data for each framework.
  $bootstrap = array();
  $bootswatch = array();
  foreach ($json as $data) {
    if ($data['name'] === 'bootswatch' || $data['name'] === 'twitter-bootstrap') {
      foreach ($data['assets'] as $asset) {
        if (preg_match('/^' . BOOTSTRAP_VERSION_MAJOR . '\.\d\.\d$/', $asset['version'])) {
          ${$data['name']}[$asset['version']] = $asset['files'];
        }
      }
    }
  }

With your change, that line of code will be trying to set a variable named $twitter-bootstrap, but it needs to be setting the $bootstrap variable. I tried your change first, and ran into that issue, which is why I ultimately just added a line to translate "twitter-bootstrap" into "bootstrap" instead (minimally invasive, but sticking with the existing conventions in the code).

Changing this back to Needs Work.

@m.stenta, you are correct. Might have helped if I had actually tested the change before committing, my bad.

dynamic variables--

I've opted for using a $libraries array instead to get rid of the dynamic variable bit (I knew this would come back to bite me in the a$$) and then re-purposed the $bootstrap and $bootswatch variables to be the expected jsDelivr library names.

Also I feel like I should have further explained why I chose to not use the patch in #6.

I tried your change first, and ran into that issue, which is why I ultimately just added a line to translate "twitter-bootstrap" into "bootstrap" instead (minimally invasive, but sticking with the existing conventions in the code)

Arbitrarily changing a raw response value is never really a good idea and is generally considered bad "best practice". It can lead to hours of confusion as to "why" or "where" this change occurred (as it would differ from the original API response). Also, I knew they would likely put it back in (which they did, rather quickly) and thus we would have duplicate libraries on our hands.

@markcarver: You're right. I shouldn't have been changing a raw response value... bad. Oh well, glad you got a new fix worked out!

And yea... dynamic variables are definitely another one of those someday-gotchas. :-)

Thanks again!

No worries. This actually has helped with the "what happens when" scenario.

I've gone ahead and committed more fixes so that it moves the "error" handling up a little when the main twitter-bootstrap library isn't found whether it be from bad HTTP request or something like this (where the request was successful, but the library name didn't exist in the response).

GOSH - they changed it back to bootstrap ...

aka oops they did it again ..

I made this new issue:
#2842944: jsDeliver name change back to bootstrap