Problem/Motivation
Creating a new multi-site or site with settings.php not in docroot/sites/default/ causes aggregated CSS and JS assets to 404 by default. Setting
$settings['file_public_path'] in settings.php to a valid path fixes the problem, but that feels broken that we should have to do that by default when we previously did not.
10.1 has updated CSS/JS aggregation to a lazy method that only generates the files when the resources are requested:
https://www.drupal.org/node/2888767 →
.
Tracking down the issue, I see that the dynamic route provider Drupal\System\Routing\AssetRoutes creates a dynamic path using getDirectoryPath() on Drupal\Core\StreamWrapper\AssetStream which in turn calls basePath on Drupal\Core\StreamWrapper\AssetStream. basePath has the following code:
return Settings::get(
'file_assets_path',
Settings::get('file_public_path', 'sites/default/files')
);
This will always default to sites/default/files if $settings['file_public_path'] isn't explicitly set.
AssetStream's parent class PublicStream, however, has a version of basePath that uses the DrupalKernel service to get the site path, and it correctly uses sites.php to find the correct path by default.
$site_path = \Drupal::getContainer()->getParameter('site.path');
I feel like AssetStream should be updated to be closer to PublicStream.
Steps to reproduce
1. Download Drupal 10.1 via composer
2. Create docroot/sites/www folder and copy docroot/sites/default files to new folder.
3. Update docroot/sites/sites.php to point to docroot/sites/www by default.
4. Install Drupal using standard profile.
5. See JS/CSS aggregated files not rendering.
Proposed resolution
Update basePath on AssetStream to be closer to basePath on PublicStream and use the following to get the correct site path if one isn't explicity set in settings.php
$site_path = \Drupal::getContainer()->getParameter('site.path');
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet