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).

@pick_d - heads up that bootstrap 3.28 works great on Drupal 10.0.9 if you want to get started on the D10 major upgrade. Fix the version: "composer require drupal/core-recommended:10.0.9".

I would caution against a D10.1.0 upgrade until we figure this out.

Annoyingly, I can't replicate this on my lando local - it works great with aggregated CSS. Investigating.

Thanks, will try that with 10.0.9.

There are entries in the D10.1.0 changelog that imply D10.1 handle building css and js aggregation differently. See: https://www.drupal.org/node/2888767 →

Basically the theme file is failing to load the library with "use Drupal\bootstrap\Bootstrap;". The use command is there but it can't find it. But my contrib *.module files similarly use "use" statements with no issues.

What bugs me is the fact that this is working on my local (after I turned on caching and re-enabled css/js aggregation) but failing on my deployed dev server. There are small mismatches in apache, php, mysql versions and some libraries, but nothing that quite adds up.

"drush cr" kind of kicks it in the pants, but not enough. It's the oddest behaviour.

I'll think about this and see what I come up with tomorrow.

I'm experiencing the same problem.
After upgrading to Drupal 10.1.0, Boostrap them breaks when 'Bandwidth optimization' for 'CSS' and 'JS' files is 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).

mademo → made their first commit to this issue’s fork.

Could also be this: https://www.drupal.org/project/drupal/issues/3368769 🐛 10.1.x breaks Nginx + PHP-FPM with too many redirects even when nginx config is changed Closed: works as designed

@KlemenDEV: Two pieces of evidence that contradict the nginx/PHP-FPM theory:

1) This is happening to me on apache.
2) This isn't happening on other themes like Claro.

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 tried tackling this again this evening, without much headway. I did determine a few things:

1) This isn't a bootstrap subtheme issue. The same error 500 occurs on both subthemes and bootstrap.

2) Full stack trace for anyone who can decipher what might be happening:

The website encountered an unexpected error. Please try again later.

Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of themes/contrib/bootstrap/bootstrap.theme).
Drupal\Core\Extension\Extension->load() (Line: 137)
Drupal\Core\Theme\ThemeInitialization->loadActiveTheme() (Line: 74)
Drupal\Core\Theme\ThemeInitialization->initTheme() (Line: 150)
Drupal\system\Controller\AssetControllerBase->deliver()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 583)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I'm going to bump this up to Major - obviously something is bootstrap specific and clashing with the 10.1 update. Anyone who thinks that's overkill can come help us solve this nasty issue.

Possibly related to: https://github.com/drupalprojects/bootstrap/blob/8.x-3.x/autoload-fix.php ?

Why does bootstrap need an "autoload-fix.php" in the first place? Anyone know the history of this? Could this fix finally have broken?

There's a function _find_autoloader() in scripts/bootstrap.php that makes reference to Drupal 8 - I'm wondering if this mechanism needs a tuneup.

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.

I get that this solution does work... but why does it work? I'm a little cautious about a solution where we don't understand the root problem.

I see that this change adds the following to autoload_psr4.php and autoload_static.php:

$ diff site_fixed/vendor/composer/autoload_psr4.php site_old/vendor/composer/autoload_psr4.php 
68d67
<     'Drupal\\bootstrap\\' => array($baseDir . '/web/themes/contrib/bootstrap/src'),
$ diff site_fixed/vendor/composer/autoload_static.php site_old/vendor/composer/autoload_static.php 
119d118
<             'Drupal\\bootstrap\\' => 17,
384,387d382
<         ),
<         'Drupal\\bootstrap\\' => 
<         array (
<             0 => __DIR__ . '/../..' . '/web/themes/contrib/bootstrap/src',

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

I would have guessed this has something to do with bootstrap's slight of hand tricks with autoload, but I'm still really unclear why this is working fine without the autoload fix on my lando local but not working on my production sites.

I really don't want to delay a working fix though.

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 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

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

Seems to behave in a similar way

This also looks similar to closed issue when using devel module https://www.drupal.org/project/devel/issues/2853398 →

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.
   */

The patch didn't resolve the issue.

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

@shelane, patch 29 should very likely be pushed into the dev branch and likely warrants a release, it's a chicken and egg thing with composer.

Any heavy hitters want to weigh in on this?

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 📌 Extension System, Part IV: Properly register all installed extensions/namespaces during container generation Needs work

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 bootstrap.

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.

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 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 I have

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

I have not really tested 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

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

https://www.drupal.org/project/drupal/issues/3373929 💬 CSS and JS returns 404 when enabling css and js aggregation on nginx Closed: works as designed

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"

Automatically closed - issue fixed for 2 weeks with no activity.

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 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.

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

if this causes an error, look at
composer why drupal/bootstrap
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 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.

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)

does this error look like
https://www.drupal.org/project/drupal/issues/3359497 🐛 Log an error message when library definitions have a license with no URL defined Needs work

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 🐛 Undefined Library Licence URL - PHP Warning Needs review