🇺🇸United States @micahw156

This module will likely need updates for 📌 Convert drupal_rebuild() and drupal_flush_all_caches() functions into cache Rebuilder class Needs work . That will break compatibility with ^8 | ^9 | ^10, so this module will need a version bump, too.

Confirming this patch worked for me on 10.1.6 as well.

I've back-ported a number of fixes from our internal base theme.

Tagging release and marking fixed.

Confirming the patch for #3389715 resolved my use case for diff module errors.

I figured out how to uninstall the module and why it's showing null, but I'm not sure where it needs to be fixed.

The solution was in #3257390: It is not possible to uninstall slick → , to open and save every exiting filter configuration.

Before touching the filter configurations, none of my filter configurations had any dependencies (except markdown). Saving all configurations added the blazy and slick dependencies. Once those dependencies were added, the uninstall worked as expected.

These missing dependencies seem more like an installation problem than an uninstall problem, but this workaround should help anyone who gets stuck until a patch can be provided.

Yes, this is still a problem. I encountered it today.

I did some debugging, and determined that in my case, $config->get('dependencies') is returning an empty array, therefore $dependencies['module'] is not set.

I don't have time to write a patch right now, but it would seem that writing a check to verify this value is set should resolve the problem.

We could not find \Drupal\file\ManagedFileFetcher or file.fetcher.managed but it appears that the file.repository service will do what we need.

  $data = (string) \Drupal::httpClient()->get($url)->getBody();
  return \Drupal::service('file.repository')->writeData($data, $destination, FileSystemInterface::EXISTS_REPLACE);

Also, could not find TransferException but FileTransferException appears to be the replacement.

Note: This issue seems to be mitigated by enabling the new file_assets_path setting → and moving JS/CSS aggregation files out of public://.

I found this issue while researching another problem.

As noted by @kalabro in https://www.drupal.org/node/244924#comment-8186447 → this should actually be set in decimal.

I just tested setting my desired permissions of 2775 using $settings['file_chmod_directory'] = 1533; and it worked as intended for both mkdir and chmod with the file_system service.

I'm pretty sure this is just a documentation issue.

I thought about creating a patch for this, using the octdec() conversion for clarity, but I don't love the solution, so I'm just going to insert a diff here instead. Hopefully someone can improve on this.

diff --git a/sites/default/default.settings.php b/sites/default/default.settings.php
index 5615be3dc0..6b6bae14ea 100644
--- a/sites/default/default.settings.php
+++ b/sites/default/default.settings.php
@@ -481,10 +481,11 @@
 /**
  * Default mode for directories and files written by Drupal.
  *
- * Value should be in PHP Octal Notation, with leading zero.
+ * Value should be converted to decimal from PHP Octal Notation,
+ * with leading zero.
  */
-# $settings['file_chmod_directory'] = 0775;
-# $settings['file_chmod_file'] = 0664;
+# $settings['file_chmod_directory'] = octdec('0775');
+# $settings['file_chmod_file'] = octdec('0664');
 
 /**
  * Public file base URL:

New branch.

micahw156 → created an issue.

Tagging release and marking fixed.

Fix issue title.

micahw156 → created an issue.

Marking fixed and rolling release.