Well, if people are creating spam accounts and trying to crack passwords that can totally be handled by selectively protecting resources related to account creation and login.
Static content on your website should probably not have this "protection" unless you are experiencing flooding (something I understand is more and more of a problem nowdays as everyone and their mother is scraping the web for AI - personally I found ByteDance's to be the most annoying since it ignores rate limiting and robots.txt rules).
But, static content can also be put on CDNs, or reasonable requests per minute per IP put in. The advantage of more nuanced thingies like that is that the website is also still usable in other things people-still-use, like w3m (although, amusingly, and props to them on this at least, the website works just fine in w3m for me — Which is also funny 'cause w3m would look a lot like a bot too (no JS, HTML only fetches) - so honestly, how is putting this in front of static pages helping anything at all).
But sure, I get it. Y'all are no doubt extremely busy, and tossing the problem over to a company like theirs to handle every resource on the domain instead of on specific resources is easier, so long as they do things in a sensible fashion. ☺
Well, if it's any comfort to you, they break plenty of other websites for me too, I've come to recognise the combo. Zillow.com - same issue, breakage started at same time as drupal.org - only workaround being, again, to use Firefox without resist fingerprinting enabled.
I do this sort of thing selectively and only if I really need it since the whole "uniquely identify all users" thing online these days really annoys me even if I'm not trying *that* hard to be unidentifiable.
I normally just take my business elsewhere if a website does this (like zillow), but, I do care quite a lot about drupal since I've been working with it and pushing it as a solution for a couple of decades, and given the website *is* the place to go if there are any security issues I just feel y'all should at least not block access to key pages like your sales and patch pages.
Anyway, good luck to you, and who knows, maybe this will lead to them not breaking other sites too :)
While I appreciate the issue being acknowledged, I feel it's worth mentioning to anyone who might drop by here that there has been absolutely no change in the situation.
The only solution if you need some information on drupal.org these days is to setup a profile with user fingerprinting enabled. There are no other workarounds.
Kyber → created an issue.
Kyber → created an issue.
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
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.
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.
Kyber → created an issue.
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?
So. What's the verdict on this one? Is bootstrap now only installable using composer?
After reading through it fairly carefully, it *seemed* that generating the vendor/autoload.php using composer dump-autoload should be sufficient, and the result could then be packaged up.
However, we are still encountering this issue in the latest release, but only with a subtheme.
Specifically that:
sites/default/files/css/css_XXXXX.css?theme=bootstrap
loads the aggregated CSS, but
sites/default/files/css/css_XXXXX.css?theme=custom_subtheme
fails, with aggregation enabled, with the 'Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of themes/contrib/bootstrap/bootstrap.theme)'
Now, we don't particularly need aggregation, it just complicates debugging and editing, is a bit user unfriendly, and in this age of HTTP2 and compression, doesn't really offer any significant benefits.
But, I'm a bit concerned this might be revealing other problems with bootstrap in general compared to other themes.
It could be an issue with the subtheme itself and needed D10 changes though?