Aggregation is not working correctly

Created on 17 August 2023, about 1 year ago
Updated 21 August 2023, about 1 year ago

Problem/Motivation

I previously opened this issue here https://github.com/drush-ops/drush/issues/5728 but I was advised to open it here

After updating the sites to Drupal 10.1 and Drush 12, my css and js stopped clearing when I run drush cache:rebuild. If I run this command on Drupal 10.1 with Drush 11 or on Drupal 10.0 with Drush 12, then css and js are cleared.
Also, if cache rebuild through the admin toolbar, then css and js clears.

I then set up Xdebug to find out at what step everything goes wrong. As it turned out, everything goes on the step when the CSS and JS should be cleared. It does not see "assets://css" and "assets://js" as directories, and therefore cannot remove them.
If I start clearing the cache through the admin toolbar or through Drush 11, then it see and clears these directories

Steps to reproduce

  1. Update Drupal core to 10.1.1 or 10.1.2
  2. Update Drush to 12.1
  3. Set up Xdebug and set breakpoints in FileSystem::deleteRecursive. (Through this method, css and js should be cleared)
  4. Listen for Xdebug
  5. Run drush cache:rebuild in console
  6. When it reaches the breakpoint, enter is_dir($path) in the debug console and your will see that it gives FALSE. That is, it does not find directories and cannot remove them.

If listen to Xdebug through Drush 11 or through the admin toolbar, and enter is_dir($path) in debug console it gives TRUE

P.S. When I run drush cache:rebuild on Drupal 10.1.1 with Drush 12 I get the following messages:

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

On Drupal 10.1.2 these notices not displaying but the problem remains

Ubuntu + Apache 2.4.52 + PHP 8.1.14

πŸ› Bug report
Status

Closed: works as designed

Version

10.1 ✨

Component
Asset libraryΒ  β†’

Last updated 1 day ago

No maintainer
Created by

πŸ‡·πŸ‡ΊRussia BadWebCoder

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @BadWebCoder
  • πŸ‡ΊπŸ‡ΈUnited States cilefen

    Can you test on the 10.1.x dev release please? There have been a few very recent commits to the asset library system to address some bugs with the asset library changes introduced in 10.1.0.

  • πŸ‡·πŸ‡ΊRussia BadWebCoder

    @cilefen, I tested on 10.1.x dev and the problem remains

  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Are you running your webserver and drush as the same user? What are the owner, group and permissions on your files directory? Have you configured file_assets_path in settings.php? (You do not need to, but if it is set to an invalid location then perhaps this can happen)

  • πŸ‡·πŸ‡ΊRussia BadWebCoder

    @longwave,

    Are you running your webserver and drush as the same user?

    Yes

    What are the owner, group and permissions on your files directory?

    korotkov:korotkov (like all files on my local server) and 775 permissions

    Have you configured file_assets_path in settings.php?

    No, but assets:// the default is sites/default/files/public/

    But css and js cleans with the same settings if I do it through Drush 11, or through Drush 12 but on Drupal 10.0

  • πŸ‡¬πŸ‡§United Kingdom catch

    Can you try applying this patch and see if the directory gets deleted. I'm wondering if it's something to do with drush and the new assets:// stream wrapper.

  • Status changed to Postponed about 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom catch

    Re-reading this sounds like a drush 12 issue.

    I've commented on https://github.com/drush-ops/drush/issues/5728 which is unfortunately closed. I'm postponing this on more investigations on the drush side.

  • Status changed to Postponed: needs info about 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom catch
  • πŸ‡·πŸ‡ΊRussia BadWebCoder

    Well, it turns out it's something else. My Drush 12 ignores my settings.php and uses default values
    And I remembered that I had a similar problem earlier when I was just updating sites on Drush 12 when I run drush cr I got error:
    Missing $settings['hash_salt'] in settings.php.

    And now, I tried getting the path of public:// and assets:// during debug and I got /sites/default/files` through Drush 12 and /sites/default/files/public through Drush 11 or Admin Toolbar.

    My settings are arranged like this: sites/settings.php contains my main settings, which are used both on prod and on dev. In sites/default/settings.php I have individual settings depending on the environment. There via require_once DRUPAL_ROOT . '/sites/settings.php'; I connect the main settings to the individual ones. And Drush 12 sees only those values that I directly specified in sites/default/settings.php. He stopped seeing what I get from sites/settings.php and for this I have to transfer the necessary parameters from sites/settings.php to sites/default/settings.php
    And after I set $settings['file_public_path'] = 'sites/default/files/public in sites/default/settings.php', then when I run drush cr css and js clears

    I'm closing the issue because the problem turned out to be something else

  • Status changed to Closed: works as designed about 1 year ago
Production build 0.71.5 2024