Refactor providers to utilize new data.jsdelivr.com API

Having the exact same issue here, using version 8.x-3.0-beta2+19-dev

jsDelivr messed up their v1 API (again)... sigh.

https://github.com/jsdelivr/api/issues/56#issuecomment-175100773

Postponed, awaiting response from @jsdelivr/jimaek.

To (edited) "temporary" solve, use custom CDN and add the correct uri's:

http://www.jsdelivr.com/?query=bootswatch

http://www.jsdelivr.com/?query=bootstrap

Greetings!

This really only affects the UI dropdown. You could, in theory, still set the jsDelivr version and theme via a theme's .info file as well if you don't want to go down the Custom CDN route.

I think the custom CDN way is better, when jsDelivr fix the issue the Bootstrap Drupal theme will need a little modification, its a clean way than edit theme files.

BTW, i tested the two methods and both work fine.

I'm a little confused now. Where exactly do i change the CDN reference? In the theme settings the references point directly to the css and js files of the bootstrap framework. Also tried changing the package name to 'Simplex' in the info.yml file, but that did not seem to work for my setup. Any help would be greatly appreciated.

Frustrating. Flashbacks to #2504343: jsDelivr options broken... :-(

Yes... I'm a little pissed off right now. Apparently their idea of API versions are just that... "ideas".

Jesus, this bug hit me right between the eyes! I will never, never confide in those jsDelivr guys! I tired to set up my subtheme with LESS processor, but did not get it working with the Bootswatch sandstone variables. How ever, thank you for the advice to set up a custom CDN!

Yea, my CDN subtheme broke because my .info file had the following:

settings[bootstrap_cdn] = 3.2.0
settings[bootstrap_bootswatch] = 'yeti'

I changed it to:

settings[bootstrap_cdn_provider] = 'custom'
settings[bootstrap_cdn_custom_css] = '//cdn.jsdelivr.net/bootswatch/3.2.0/yeti/bootstrap.css'
settings[bootstrap_cdn_custom_css_min] = '//cdn.jsdelivr.net/bootswatch/3.2.0/yeti/bootstrap.min.css'
settings[bootstrap_cdn_custom_js] = '//cdn.jsdelivr.net/bootstrap/3.2.0/js/bootstrap.js'
settings[bootstrap_cdn_custom_js_min] = '//cdn.jsdelivr.net/bootstrap/3.2.0/js/bootstrap.min.js'

And now it's working as expected (after deleting the theme settings variable and clearing cache).

I'll just hard-code the URLs from now on...

It is already working again...

Yes, confirmed it's working again.

Thank you @m.stenta for chiming in on that issue and asking to revert (which I didn't think to do) and getting this working again!

Honestly, the one good thing from all this is that it has shown (on both sides) where some problems exist. From @MartinKolarik on https://github.com/jsdelivr/api/issues/56#issuecomment-175757350:

Once the user selects a theme, you can store the needed URLs in some kind of persistent storage. Even if the API went down, it shouldn't affect anyone except people trying to change the theme at that moment.

I definitely agree with this, although I'm not entirely sure how to accomplish this (yet). Originally, I was just thinking of using another variable (similar to the Custom CDN solution), but given the "coded settings are ignored" issue... I don't think that's going to work.

We could create a custom variable, I guess. That will persist through a cache clear.

Thoughts?

@markcarver: Yea, it wouldn't hurt to make the Bootstrap theme a little more robust to prevent that sort of thing - but I agree it's sort of tricky to implement. Especially for existing sites (it would be nice if themes could use hook_update_n() to modify the theme variable).

What if:

* The theme settings ALWAYS stored the URLs of the CDN.
* Instead of toggling the CDN variable between "jsdelivr" / "custom" - you just always use the stored URLs.
* Then the UI that let's you select "JsDelivr" is really just a helper - and the UI itself then shows you some options (for versions, bootswatch, etc) to choose from - but when you actually save the form, it get's saved as URLs.

I admit, though, that I'm not 100% familiar on how it's working now - so maybe some of my assumptions are wrong.

Especially for existing sites (it would be nice if themes could use hook_update_n() to modify the theme variable).

I don't think we need an update hook (which I did implement in 8.x-3.x btw #2628530: Introduce a proper Update API) .

I think we could just get away with retrieving the assets as we do now and then set it if it doesn't exist (at least for 7.x-3.x).

Then anytime it's changed in the UI, we retrieve the assets and then re-save the variable.

Re: "What if" comments:

The problem is that the available themes different between versions (as they're added/removed), see #2357237: Paper Bootwatch Theme breaks css in Bootstrap and it's sub themes. The other problem is that the bootswatch theme does not provide the bootstrap JS in it's assets.

Basically, if we could do a 1:1 map between the project, version and theme then we wouldn't need this API service to extract the assets from it in the first place.

This is really a feature request and something not really "critical" (at the time it felt like it). In reality though, using a CDN for anything will have this potential downside and why using local code is preferred for high profile/important sites.

That being said, I'm not entirely sure what the path forward with this issue is yet. There are a lot of variables at play.

This issue suddenly popped up for me today - my Bootswatch theme disappeared.

Similar to #4 above, I got it back for now by choosing CDN Provider:Custom and pasting in the URL of the Bootswatch theme cdn.jsdelivr.net/bootswatch/3.3.5/united/bootstrap.min.css

But I do keep getting this message on that theme settings page:

"ERROR: Unable to reach or parse the data provided by the jsDelivr API. Ensure the server this website is hosted on is able to initiate HTTP requests via drupal_http_request(). If the request consistently fails, it is likely that there are certain PHP functions that have been disabled by the hosting provider for security reasons. It is possible to manually copy and paste the contents of the following URL into the "Imported jsDelivr data" section below.
api.jsdelivr.com/v1/bootstrap/libraries."

Not sure this is going to happen for 8.x-3.x.

Actually, it's going to have to happen for 8.x-3.x.

The old API has been deprecated: https://github.com/jsdelivr/api/issues/137

The new API (https://github.com/jsdelivr/data.jsdelivr.com) unfortunately has a completely different structure.

WIP

Above patch isn't going to happen.

Instead, this will be relying on the work I've been doing over at https://www.drupal.org/project/cdn_library and https://www.drupal.org/project/jsdelivr.

Given that it will require major refactoring, that will have to happen in 8.4.x after all.

This is going to have to be solved for 8.x-3.x and 7.x-3.x due to #3020589: Default to Bootstrap 3.4.0; if only as a temporary "fix" somehow.

FYI, This patch is depending on the site https://data.jsdelivr.com/v1/package/npm/$package in bootstrap/src/Plugin/Provider/JsDelivr.php on line 108;

$packageJson = $this->requestJson("https://data.jsdelivr.com/v1/package/npm/$package") + ['versions' => []];

Therefore if that URL site is down (or not accessible), the code doesn't work by ending up the following error:

Got error 'PHP message: Error: Unsupported operand types in /var/www/html/data/d8/sites/all/themes/contrib/bootstrap/src/Plugin/Provider/JsDelivr.php on line 108
#0 /var/www/html/data/d8/sites/all/themes/contrib/bootstrap/src/Plugin/ProviderManager.php(38): Drupal\\bootstrap\\Plugin\\Provider\\JsDelivr->processDefinition(Array, 'jsdelivr')
#1 /var/www/html/d8/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(286): Drupal\\bootstrap\\Plugin\\ProviderManager->processDefinition(Array, 'jsdelivr')
#2 /var/www/html/d8/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\\Core\\Plugin\\DefaultPluginManager->findDefinitions()
#3 /var/www/html/data/d8/sites/all/themes/contrib/bootstrap/src/Plugin/PluginManager.php(101): Drupal\\Core\\Plugin\\DefaultPluginManager->getDefinitions()
#4 /var/www/html/d8/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\\bootstrap\\Plugin\\PluginManager->getDefinitions()
#5 /var/www/html/d8/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php(60): Drupal\\Co...

Same thing.

Yup. This is breaking my build at the moment.

Change record done, please review: https://www.drupal.org/node/3032924