Drupal 10.1 breaks Bootstrap

I have the same issue with Drupal 10.1 and this theme.

However, in my case disabling advagg and built-in aggregation doesn't really solve the issue completely for some reason.
Theme still won't work properly, but it is "way less broken". Maybe I messed up somewhere else. With D9.5 everything works just fine.

SITE/sites/default/files/js/js_sMSIP1zYFriunMpQD3CnuzLA2MwAy8fDHkEZOuIC4TU.js?delta=0&include=eJx9UQtuwyAMvRANZ9hJIkOshBZiZpuq2ekHy2dNp1WKYvOe7eePJ0Z7_SzIi3Hgb71S_bJ98vur_EspPtT4VmPgkiF2mWlkFKng3MgCcad-kUsM801MhK_Ftp-RRRRTrSxo0uLUjpFcjRPPIaucMV1q-nhSBa_hjj9lTZVodqe2p3FEKsqQbaZMd-QnRImihmymIEq8WMjh8BPw7QJyYYThpDkEyRE8rqCCc-AidusuO5lCOoVveCYJGmh-KQWRxg6u8DCtFwdsN9slnMsreJ69KHlKOaKigSGFud_CekFgP9nVmCLIe1Lzu1AvImutUE_DcyVkwjwhD1WyNL3Cx8IP5CTfBq9sghlG5Pdn39s_d9msHPO2poxMxOqL7jX29znzyFFGfEN1U7t3G3HWP_tF8ZDxoyUbF8Y-h4x2d74BGUk3oQ&language=ru&scope=footer&theme=mybt

Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of SITEDIR/web/themes/contrib/bootstrap/bootstrap.theme).

Thanks, will try that with 10.0.9.

I'm experiencing the same problem.
After upgrading to Drupal 10.1.0, Bootstrap theme breaks when 'Bandwidth optimization' for 'CSS' and 'JS' files are checked to 'aggregate'
When aggregation is not selected, the theme loads just fine.
If switching to another theme, such as 'Claro' the interface displays without any issue.

Also seeing this on multiple sites. Have tried changing the nginx config as suggested https://www.drupal.org/node/2888767#nginx-php-fpm
But even then bootstrap css js agg fails to create any files.
This is becoming a big issue for us (100+ sites).

Could also be this: https://www.drupal.org/project/drupal/issues/3368769 (not directly related to original issue, but for the ones having problems only when aggregation is enabled this may also be the culprit).

However if class loading errors are logged, the link above will not help.

However if class loading errors are logged, the link above will not help.

My comment was more as some may land here but in fact have the other problem (or both problems combined).

My workaround for this is to add the autoload lines to my project's composer.json
The path should point to the proper place of bootstrap/src

  "autoload": {
    "psr-4": {
      "Drupal\\bootstrap\\": "www/themes/bootstrap/src"
    }
  },

As mentioned by @TrevorBradley on #3, locking Drupal to composer require drupal/core-recommended:10.0.9 works without any issues.

@tikaszvince, I'll try your solution soon.

I had the same problem this morning deploying to Acquia PROD. No issues on DEV or STG but after deployment to PROD I began to get 503s and this log: Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of .../themes/contrib/bootstrap/bootstrap.theme)

@tikaszvince, your workaround fixed the issue in my case as well, thanks.

It seems like a race condition to me. When I was testing, I was visiting /user and /user/register and sometimes they'd work and other times were a 503.

I just used the upgrade status module to scan the Bootstrap theme and I get these errors for D10 readiness and I'm not sure if any of them would be related to this issue.

Tested MR !29. Works.

@shelane, your scanning tool appears to be looking at custom code. Someone on your team probably included a very old copy of bootstrap as custom code in your build.

You should grab the latest version of bootstrap, it is already functional for Drupal 10.0.9

This issue currently is looking at Drupal 10.1.0 compatibility.

Howdy,

I tried the workaround noted in #12, but it did not work. I still get the following error when CSS/JS aggregation is enabled:

Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of /var/www/html/web/themes/contrib/bootstrap/bootstrap.theme).

The theme does work fine when CSS/JS aggregation is disabled. FWIW, my running environment is as follows:

- Drupal 10.1.0
- Ubuntu 22.04 server
- Apache/2.4.52
- PHP version 8.1.20
- Bootstrap 3 theme + sub-theme

I have the same or similar issue when updating to 10.1 (and 10.1.1) when using nginx as a reverse proxy in front of an apache web server when enabling css and js aggregation. Switching theme to Oliveiro and the issue goes away.

e.g.

Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of /var/www/vhosts/mydomain.com/httpdocs/web/themes/contrib/bootstrap/bootstrap.theme).

But other themes like claro don't even have a composer.json file.

They don't have a composer.json file and they don't ship any OOP code. I'm not aware of any themes other than bootstrap that do, which might be why it's hitting this problem.

Uploading patch here as I can't see it already

Tried patch but does not seem to help in my scenario i.e. running apache with nginx working as reverse proxy

https://www.drupal.org/project/bootstrap_barrio also has composer.json file

Seems to behave in a similar way

In fact every theme I have seen installed via composer seems to have composer.json?

This also looks similar to a couple of closed issues e.g devel module https://www.drupal.org/project/devel/issues/2853398 and webform_bootstrap https://www.drupal.org/project/webform/issues/2893225

With regards to:

Why does bootstrap need an "autoload-fix.php" in the first place?

Looking at the autoloadFixInclude method it states:

 /**
   * Returns the autoload fix include path.
   *
   * This method assists class based callbacks that normally do not work.
   *
   * If you notice that your class based callback is never invoked, you may try
   * using this helper method as an "include" or "file" for your callback, if
   * the callback metadata supports such an option.
   *
   * Depending on when or where a callback is invoked during a request, such as
   * an ajax or batch request, the theme handler may not yet be fully
   * initialized.
   *
   * Typically there is little that can be done about this "issue" from core.
   * It must balance the appropriate level that should be bootstrapped along
   * with common functionality. Cross-request class based callbacks are not
   * common in themes.
   *
   * When this file is included, it will attempt to jump start this process.
   *
   * Please keep in mind, that it is merely an attempt and does not guarantee
   * that it will actually work. If it does not appear to work, do not use it.
   *
   * @see \Drupal\Core\Extension\ThemeHandler::listInfo
   * @see \Drupal\Core\Extension\ThemeHandler::systemThemeList
   * @see system_list
   * @see system_register()
   * @see drupal_classloader_register()
   *
   * @return string
   *   The autoload fix include path, relative to Drupal root.
   */

See also Document differences between themes and modules and their limitations https://www.drupal.org/project/bootstrap/issues/2770001

Namespacing/Autoloading - Generally this works just fine for themes since anything in {system} will automatically add the namespaces to the autoloader. That being said there is a small caveat, generally when dealing with cross-request/ajax theme class based callbacks, that prevent the namespaces from being registered in themes when logic is being processed too early in a low level bootstrapped request. This is why I added the Bootstrap::autoloadFixInclude helper method so autoload-fix.php can be included as a "file" for certain callbacks where it's necessary.

The patch didn't resolve the issue.

Given reports that the patch is not working, I'm setting back to "Needs work."

****EDIT****
Hmm, looks like a variety of possible solutions available here, not sure which is best.

@shelane, patch 26 looks like a likely candidate to go in, it's a chicken and egg thing with composer.

Any heavy hitters want to weigh in on this?
****EDIT****

You cannot use composer-patches to make changes to the autoloader. See Non-patchable targets. The patch needs to be applied before the installation.
What you need to do is install the theme from the Issue-Repository including the changes to composer.json:

composer config repositories.bootstrap-3369979 git https://git.drupalcode.org/issue/bootstrap-3369979.git
composer require drupal/bootstrap:dev-3369979-drupal-10.1-breaks

Yes #34 is right, just applying the patch to the module does nothing. You might be able to run composer dump-autoload to get the autoload changes picked up without having to make the composer.json changes though.

I think that's probably the right fix for bootstrap so moving back to needs review. I don't use bootstrap so not in a position to test it.

The existing core issue if anyone want to try to help there is #2941757: Extension System, Part IV: Properly register all installed extensions/namespaces during container generation

Hiding patch as is a non patchable target

Change to composer.json does the trick. As @hosterholz says using issue-fork is required given the nature of the change. `composer dump-autoload` did not work on our site using bootstrap sub-themes.

Thank you @hosterholz

Adding repository via composer config and specifying branch with composer require, patch appears to be now working now i.e css and js is now showing with aggregation enabled.

I think that's enough manual testing to mark this RTBC.

Just to clarify the above works for me when running apache with nginx reverse proxy e.g plesk webserver setup

I am still having a problem with css and js aggregation when running nginx locally using wodby stack

I have tried loading additional config using

NGINX_SERVER_EXTRA_CONF_FILEPATH: /var/www/html/locations.conf

and in locations.conf I have

# Passes image style and asset generation to PHP.
location ~ ^/sites/.*/files/(css|js|styles)/ {
  try_files $uri @rewrite;
}

I have also tried as absolute paths e.g.

location ~ /var/www/html/web/sites/.*/files/(css|js|styles)/ {
  try_files $uri @rewrite;
}

I am not sure how to test nginx to see if this additional directive is being applied, but previously I had Drupal 10 running without issue on Wodby stack running nginx without having to add any location directive.

This is different from the issue here as server generates a 404 rather than a 500 error as seems to affect contrib themes.

To get around this I have switched to running Apache on my local.

Added separate issue for broken css and js when enabling aggregation for contrib themes

https://www.drupal.org/project/drupal/issues/3373929

I will be tagging a release with this MR included. I'm going to leave the issue open for a while and see what else (if anything) might be reported on it. I will also keep an eye on the related core issue that @2dareis2do reported. I have marked that as related here. Thanks everyone.

Thanks a lot.

Latest -dev version works with D10.1.1 for me.

The only issue I noticed so far is the following warning that sometimes pop up during 'drush updb' or 'drush cr':

 [notice] The file assets://css was not deleted because it does not exist.
 [notice] The file assets://js was not deleted because it does not exist.

(I use 'bootstrap CDN' option in theme settings, but custom links point to files stored locally, if that is relevant)

@pick_d that notice is harmless, but it might be worth a minor core bug report to suppress it.

@catch
Thanks.

Can't reproduce it now. Maybe it's related to advagg somehow (which I uninstalled as it has issues upon upgrade, while in the same time D10.1 bundles and minifies css and js surprisingly well now). So no info to file a bug.

Anyhow, thanks for your time.

Looking forward to testing this with D10.1.x . Ya so as I suspected but was hesitant to suggest as a fix because it seems there may be multiple fixes for this, patching the json file doesn't help at all, The composer.json change had to be committed to the release for composer workflows to function normally. Otherwise a composer circus has to be drummed up using tricks from deep in the instruction manual of composer that are helpful but it's a lot nicer just doing a composer up and getting the fix.

@shelane, no major issues, I think we can tag a release anytime!

NVM, @Shelane, thanks, you already tagged 3.29, we're good to close this as "Fixed"

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?

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?

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 generates the vendor/autoload.php which IMO bootstrap should be including the release 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.

Did you try this?
composer require drupal/bootstrap:"^3.29"

if this causes an error, look at
composer why drupal/bootstrap
(figure out and resolve)

then rebuild drupal caches?

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.

your composer.json and composer.lock should normally be included or added to git for your project if they aren't already.

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 extension/drupal release tarballs, pretty much same process as drupal had used throughout its history.

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.

That said, I'm willing to try seeing if pulling things in composer magically fixes things in dev, but am mildly skeptical given the issue seems to be that the autoload I generated was not being invoked at all when bootstrap gets pulled in by the subtheme when drupal was doing the aggregation. And, yeah, only going to do it in dev, and it will require quite a few changes to make that work, ones I'm not interested in doing in prod, but it's worth trying as an experiment..

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.

We have customers who operate in an environment where themes cannot be installed via composer, so relying on autoloader is not possible.

To resolve we have been applying a hotfix which just adds an include to the top of bootstrap.theme, we haven't spotted any issues (yet):
require_once('src/Bootstrap.php');

We have customers who operate in an environment where themes cannot be installed via composer, so relying on autoloader is not possible.

Crazy that Drupal developers can not run composer in this day and age.

I do not run composer on a prod environment, but make sure to include and changes to composer including vendor/composer/installed.php files in any git commits.

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.

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

Hello
with require_once('src/Bootstrap.php')
I have the error:
core\includes\bootstrap.inc(164): _drupal_error_handler_real Undefined array key "url" in Drupal\Core\Asset\JsCollectionOptimizerLazy->optimizeGroup() (\core\lib\Drupal\Core\Asset\JsCollectionOptimizerLazy.php line 174)
for css
Warning: Undefined array key "url" in Drupal\Core\Asset\CssCollectionOptimizerLazy->optimizeGroup() (line 160 of core\lib\Drupal\Core\Asset\CssCollectionOptimizerLazy.php).
for javascript
Warning: Undefined array key "url" in Drupal\Core\Asset\JsCollectionOptimizerLazy->optimizeGroup() (line 174 of core\lib\Drupal\Core\Asset\JsCollectionOptimizerLazy.php).

does this error look like
https://www.drupal.org/project/drupal/issues/3359497

This is caused by the libraries defined in bootstrap_library.libraries.yml not having the URL set with the licensing information.
see the solution:
https://www.drupal.org/project/bootstrap_library/issues/3380438

This at #5 did the job for me.

Same as #67 (thanks for the hint):
https://www.drupal.org/project/bootstrap/issues/3257001#comment-15413771
Helped me too.