@Kyber

Kyber → created an issue.

🐛 | OpenID Connect / OAuth client | Cannot disconnect users

Comment 8 months ago →

Oh, and I do hope the fact this bug was filed against 2.x is not resulting in it getting ignored, it spans versions.
Maybe a new one should be filed for 3.x

🐛 | OpenID Connect / OAuth client | Cannot disconnect users

Comment 8 months ago →

Ran into same issue. The 2.x patch does not apply cleanly, but did fix 3.x when adapted.

Results of testing over here with a bootstrap subtheme and aggregated CSS/JS, clearing cache each time.

require_once('src/Bootstrap.php') WORKS
require_once('vendor/autoload.php') FAILS
require_once('/var/www/html/sitename/themes/contrib/Bootstrap/vendor/autoload.php') WORKS

Thanks for your suggestion! I'll try that instead of my current hardcoded absolute path hack. I think I'll retest require_once('vendor/autoload.php'); too... that's more likely to pull in other things that could be needed.

And, yeah, I don't see why installing all of drupal with composer should be necessary. Bootstrap theme does some weird stuff other themes don't do, and maybe generating that just pulls more things into global autoload. Still kinda ew, esp depending on how bootstrap is removed.

IMO this is not indicative of "use moar composer" but rather of a design issue in drupal or bootstrap theme with subthemes, but have other priorities besides this, so I'll just use your hack.

🐛 | Webform | Libraries.yml looks in wrong folder for Tippy.js

Note, this site was not using composer, but I see you do your own JS fetches anyway so I don't see why it should matter.
I'll doublecheck what's going on with tippy and popper.
Worst case, I just specify the correct paths, manually fetch, or add a ludwig config.

🐛 | OpenID Connect / OAuth client | Connecting MFA account redirects to invalid URL

🐛 | OpenID Connect / OAuth client | Connecting MFA account redirects to invalid URL

Kyber → created an issue.

🐛 | Webform | Libraries.yml looks in wrong folder for Tippy.js

Hello. We just encountered this issue in beta6. In grepping for use of tippy in webforms I noticed some inconsistent versioning.

composer.libraries.json: "url": "https://registry.npmjs.org/tippy.js/-/tippy.js-6.3.7.tgz",
src/WebformLibrariesManager.php: 'download_url' => Url::fromUri('https://registry.npmjs.org/tippy.js/-/tippy.js-6.3.7.tgz'),
webform.libraries.yml: /libraries/tippyjs/dist/: https://unpkg.com/tippy.js@6.2.6/dist/

(also, popper.js seems to not have been downloaded and is being fetched remotely from unpkg directly in the browser, causing occasional browser blocks - not sure if that is related. investigating both.)

Oh! Running composer is NOT necessary.
The vendor autoload is indeed included in the release tarball!

So the ONLY change necessary to fix the issue with subthemes + CSS aggregation is:
require_once('/var/www/html/sitename/themes/contrib/bootstrap/vendor/autoload.php');
in the bootstrap.theme
Which is a silly hack but whatever.

Just recording this for anyone else in same situation.

I'm maintaining a theme created sometime prior as part of a larger site. The creator chose to extend bootstrap for the theme. None of the other modules nor the theme are being maintained by composer, and the theme did not have any composer additions. Everything is being deployed using the module release tarballs.

The fix in this bug, which was not bundled into the bootstrap release tarball as a vendor/autoload.php for some reason (IMO it should be just like those pieces are bundled as part of the drupal release tarballs) I had to generate myself, and did not fix the theme, nor did a few other things I tried with it.

So, I put in the hack above to get things working. Really bootstrap is rather unusual compared to other drupal themes in what it seems to be trying to do load-wise, and the "autoload-fix.php" is rather worrying, but, yeah, not something I created, just trying to keep it chugging along with minimal impact.

Trying not to get too much in the weeds on composer, this was going to prod as .tar.gz snapshot.
So far that is still something that works pretty consistently everywhere except with bootstrap theme.

But I'll give that a try in dev, just to see what it does.

Ok... it turns out my composer attempts had all in fact failed, I was just thrown off by cache clear sequences when switching between aggregated and not.

I did find a horrendous hack that works "reliably" with our subtheme.
1) run composer dump-autoload in the bootstrap theme - this includes the vendor/autoload.php which IMO this theme should be in the tar.gz already (zipped up it's 5K, but I can't attach that to a comment).
2) edit bootstrap.theme and add:
require_once('/var/www/html/sitename/themes/contrib/bootstrap/vendor/autoload.php');
at the top

I'm sure there must be a better method than a hardcoded pathname, but relative path did not work with however drupal was calling it.

I'm open to more ideas, but for now I'll just document this for our stuff.

Ok... what does make this work with subthemes is running the composer update against all of the drupal instance... which pulls the bootstrap into the global autoload.

Only... we were trying to keep bootstrap inside its own folder and not taint things outside it, so need to find another way to do this.

But that could explain why comments above said that composer dump-autoload was not working with subthemes. Perhaps the bootstrap vendor/autoload.php isn't even being called in that case, and the only way to get our theme to call it is to have those includes in the main drupal autoload?