Error: Unsupported operand types during providers JSON discovery

Actually, I think ProviderBase::requestJson should just be made to always return an array. There's no need to actually do anything special on an error.

Sure

I want to go ahead and release this, but I'd appreciate if someone can verify these are actually working for you (for both versions). I just simply did code editing in my IDE.

I got this error when rebuilding cache on a site with internet access, so not necessarily limited to that scenario.
Confirming latest dev fixes it.

After make the function return [] instead of nothing

I still encounter this error.
https://stackoverflow.com/questions/31107851/how-to-fix-curl-35-cannot-c...

It doesn't crash Drupal, but made the rebuilding cache process so slow.......

For those experience the very cache rebuilding after solving this issue.
According to the stackoverflow link above, I have managed to solve the problem by adding this to settings.php

$settings['http_client_config']['curl'][CURLOPT_SSL_CIPHER_LIST] = 'ecdhe_rsa_aes_128_gcm_sha_256';

It should be noted that the new jsdelivr API now requires the code here to do multiple requests (one for each version); whereas the previous API could be done in as little as two. This is not something we have control over and they do not plan on adding this convenience back to their API.

Also, for the record, the act of simply rebuilding the cache does not trigger this code. This only gets built when you actually visit the page. Thus, if you rebuild the caches (while on this page) you may experience a longer "cache rebuild time" as it first has to rebuild the caches and then do the multiple requests and process each received JSON data.

markcarver

FYI, I noticed the very slow cache rebuilding time after recent upgrade to the latest version of Drupal 3.6.7, the PHP Debugger found the bottle neck in this requestJson thing.

When I say 'slow'..it is longer than 10 secs (it was used to be under 2-3 secs)

FYI, Putting this inside settings.php causes problem to other request (where ecdhe_rsa_aes_128_gcm_sha_256 is not needed ).
This is needed to be put in requestJson function only.

@markcarver for drupal 7.63 after applying the patch I now get this error:
Parse error: syntax error, unexpected ':' in .../sites/all/themes/bootstrap/includes/cdn.inc on line 35
php 5.2.17

#2265819: [bootstrap][policy][7.x-3.x] PHP 5.2 no longer supported

Thanks @markcarver I also pointed this out to the client. I really appreciate all your hard work in the Drupal community and your work on the bootstrap theme.

#10 tested and and just follow #15. its work for me

For me just this fixed the issue.

The reason was that the $this->requestJson("https://data.jsdelivr.com/v1/package/npm/$package") returned NULL, hence the error. I think we should never rely that return will be an array.

This has already been fixed...

I can confirm this patch does fix the JSDelivr error.

I can also confirm that this patch does make the first visit after a cache rebuild take a dramatically longer time to render. (from ~10 seconds to 1:25)

Is there any way to reduce that? Possibly rely on the "CDN Provider" setting in the theme so when it's set to "none" it will skip the JSDelivr checks?

For me it was I had a slow internet connection and after each attempt to flush caches on the site where I develop a Bootstrap based theme there was a crash. Debugging the issue I've discovered that $this->requestJson("https://data.jsdelivr.com/v1/package/npm/$package") returns NULL instead of the array, so NULL + ['versions' => []] will result in the same error again and again.

I think it does not break anything in the code if we ensure that return type is always an array.

I was mistaken in #16, this code does get hit after a cache rebuild. I forgot that it does trigger the CDN assets when altering the library info:

https://drupal-bootstrap.org/api/bootstrap/src%21Plugin%21Alter%21Librar...
https://drupal-bootstrap.org/api/bootstrap/src%21Plugin%21Provider%21JsD...

And because of the cache clear, the JsDelivr provider plugin definition has to be rebuilt, which is where the API request code resides:
https://drupal-bootstrap.org/api/bootstrap/src%21Plugin%21Provider%21JsD...

I've created the above related issue to try and tackle restructuring some of this code so it doesn't take unnecessary hits to the API.

---

I think it does not break anything in the code if we ensure that return type is always an array.

@drugan, yes, that is what the commits #9 and #11 did: alway return an array (see the corresponding patches above those commits). This specific issue has already been fixed. There is no need to continue repeating something that has already been taken care of.

Also, re: #14 and #15, if you're having issues with cURL/SSL resolving, that is an issue specific to your server. I recommend attempting to upgrade some of your server components (e.g. cURL and OpenSSL) which would likely resolve your issues. If you cannot, I'd recommend getting a different host.

Drugan's patch (#23) was the solution that worked for me, using Bootstrap 8.x-3.17.

Thank you~

The #23 works!

Patch from #8 fixed the issue for us.

Patch #10 works for me.Thanks

Can confirm this occurred on a machine that did have internet. Applied patch #10, seems to be working. Page loading time does seem to be impacted but have not implemented any settings.php changes yet. Thanks for the patch, cashiers would not have been happy this morning.

Patch #8 worked for me as well - thanks!

Patch #8 worked great! Thank you.

Quick question, would this error cause the entire site to go down?

Without the patch in #8, my entire site was unavailable, yes.

Thank for the response @esteinborn, did your site go down after 22 Jan 2019? or did stayed up for a while before it went down?

It went down as soon as I pushed the latest version.

Just a reminder: please test code updates on development sites prior to deploying them to production servers.

That being said, #3031415: Overhaul CDN Providers API just landed in 8.x-3.x-dev and I'm working on the 7.x-3.x backport now. Please help test this code now before a release is made. I always test locally on a real site, but it doesn't mean I can't miss something (as is apparent with this issue).

It should help (a lot) with some of the fundamental flaws that became apparent in the CDN Provider API after the jsDelivr API switch happened in #2657138: Refactor providers to utilize new data.jsdelivr.com API.

I know that people are anxious to get this specific issue out the door, but there are a few things I want to get done prior to another release (especially with the security release that was made today).

Does it matter whether I had CDN Provider set to `none`? Would it still break the site? Thanks

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

I apologize that I write after closing, because I have the same problem with Drupal 7 in the offline intranet network, updated Bootstrap to dev version of February 14 - the problem disappeared. I understand correctly that these fixes will appear in the near future in Bootstrap version 7.24?

(p.s. only noticed that after upgrading to the dev version when logging in the settings of my subtheme reports the following error:

Warning: preg_match() expects parameter 2 to be string, array given in Drupal\bootstrap\Backport\Plugin\Provider\JsDelivr->parseThemes() (line 204 of C:\OSPanel\domains\mysite\sites\all\themes\bootstrap\includes\cdn\JsDelivr.php).
Warning: preg_match() expects parameter 2 to be string, array given in Drupal\bootstrap\Backport\Plugin\Provider\JsDelivr->parseThemes() (line 204 of C:\OSPanel\domains\mysite\sites\all\themes\bootstrap\includes\cdn\JsDelivr.php).
Warning: preg_match() expects parameter 2 to be string, array given in Drupal\bootstrap\Backport\Plugin\Provider\JsDelivr->parseThemes() (line 204 of C:\OSPanel\domains\mysite\sites\all\themes\bootstrap\includes\cdn\JsDelivr.php).

after I change CDN Provider to Custom-stops writing about the error, I change back to jsDelivr-also does not write. It turns out that he writes about the error before the first CDN provider configuration)

Can confirm that patch #3 from issue: https://www.drupal.org/project/bootstrap/issues/3031415 fixes the long cache rebuilding times after applying patch #8 from this issue.

Reduced cache rebuild time from 1:25 to :05 in my local development environment.

Thanks @markcarver

@markcarver if I'm reading this correctly:

If your sub-theme does not implement its own custom CDN providers via the base-theme's APIs, you may safely ignore this change record.

I shouldn't have been affected since I don't use a custom CDN. Is this correct?

In my case I had no cdn at al in my sub-theme settings but anyway got a a crash every time trying to flush the caches:

I shouldn't have been affected since I don't use a custom CDN. Is this correct?

No, that is not correct.

Change records are not an indication of whether someone has been affected by recent changes.

In fact, everyone was affected by recent commits/releases, regardless if they used a CDN or not.

This was primarily due to the way the code was structured.

---

Change records are intended for individuals who use public APIs that have changed.

The sentence you're referring to in the change record is for users who don't implement their own CDN provider (using APIs).

I was simply acknowledging that not everyone will really care about this change and was giving them an easy out.

If you don't use the CDN (set to "None"), then you don't have to worry about the change record.

I have updated the change record verbiage to be a little more explicit about that.

The errors in #46 were also fixed in the latest patch/commit of #3031415: Overhaul CDN Providers API.

Great! Thanks Mark! Waiting for patch for D7 =)

More work done: https://www.drupal.org/project/bootstrap/issues/3031415#comment-12975388

Working on backporting that work to 7.x-3.x, but please go ahead and test 8.x-3.x-dev as well.

Thanks for the clarification @markcarver

Is there a plan for a new release with this fix and #3031415 in please ?

@dudleyc, see https://www.drupal.org/project/bootstrap/issues/3031415#comment-12978631

I can confirm that the patch at #8 worked for me.

In my case, I didn't need this patch for DEV or STAGING servers. These servers all had correct ssl set up and access to the Internet.

However, in my local, composer would never run properly due to it being in an internal network problem hence preventing composer from using ssl correctly so I have to get outside of my local network to run composer correctly everytime. (This problem was specific to my local environment), however, my local composer problem was similar to "using bootstrap on a Drupal 8 website without Internet access" as in the body of this original issue.

So essentially, after I upgraded to Bootstrap 3.17, my local install of Drupal 8 would always get WSOD when viewing as anonymous user only.

However on DEV/STAGING, the exact same site would work as anonymous users.

In both my local and DEV/STAGING, only logged in users can access the site after upgrading to Bootstrap 3.17. Although in both cases, when logged in as admin, the Bootstrap theme was never listed at admin/reports/updates until I applied the patch.

After installing the patch at #8, everything now works and I have included this patch in my composer.json file until the developer of this module cuts a new stable release including this patch.

Took me days to figure out this btw.

Patch #8 worked well for me! Thank you.

When trying to apply the patch in #8 for Drupal 8.6.12 and bootstrap 3.17, I get the following:

error: src/Plugin/Provider/ProviderBase.php: No such file or directory

The WSOD issue I am trying to fix is the following in watchdog:

Error: Unsupported operand types in Drupal\bootstrap\Plugin\Provider\JsDelivr->processDefinition() (line 108 of themes/bootstrap/src/

I had to downgrade to 8.x-3.16.

Patch #8 worked for me as well. thank you!

@just_like_good_vibes #2 Worked for me..thanks

For Drupal 7, this Patch https://www.drupal.org/files/issues/2019-01-24/3027569-7.x-3.x-10.patch partially worked for me, but it seems like, some of my JS libraries are not working properly.

#10 worked for me on my D7 install

I could be mistaken but it looks like there isn't a new release with this commit in it. All of our D8 sites go down on cache clear now without this patch, since it appears jsdelivr is broken/gone/something else. I imagine everyone else running a stable version of bootstrap will be going down as well.

Could be time for a new release.

There is a patch in #3048414: Bootstrap jsDeliver CDN endpoint broken for 8.x-3.17.

Also saw the jsdelivr issue - it's resolved now. Reported to them via Twitter.

https://twitter.com/jsDelivr/status/1118055257542729728?s=19

Could be time for a new release.

@DanielVeza, see #2852156: Move "overrides" source files and generated CSS to separate project

I realise this patch in #8 has already been merged and Mark has asked in #12 above to confirm the fix so he has confidence in a new release.

Tested this to confirm it resolves situations like yesterday's JsDelivr outage:

1. Pointed data.jsdelivr.com to 127.0.0.1 in /etc/hosts to fake an outage
2. With Bootstrap 8.x-3.17 installed, cleared caches
3. Error 500 results: The website encountered an unexpected error. Please try again later.

Applied patch from #8 https://www.drupal.org/files/issues/2019-01-24/3027569-8.x-3.x-8.patch

1. Site is now capable of rebuilding its cached data, pages load once more

Relating in several other issues that might help to lead people here - I believe these all trace back to the same thing fixed here, which is

$this->requestJson($url, $params) + ['versions' => []];

throwing "unsupported operand types" when the result of requestJson is not the expected array.

Thanks Mark!

#2 worked for me. Thanks

#10 solved problem for my D7.66.
Thanks!

#10 saved my life ! Many thanks...

I can't patch the latest version 7.x-3.25 with the #10
What should I do?

Sites are down.

That's because it was already committed (see the next comment #11) and included with 7.x-3.25.

Popped up for me today when a user cleared cache on a site. #10 fixed it and now it's all up to date.

After clearing the caches, a couple of minutes ago, everything went down.

I confirm #10 fixed the issue for me.

after update the module to 3.19 I can't apply #8

While doing (NULL+ Array), PHP will throw Operand type fatal error. This patch will fix operand type issue

Please just update to the latest version. This has long since been fixed.