🇺🇸United States @micahw156

Thank you, @mandclu!

Hi,

This patch was applied to the 4.1.x branch, but it's not included in the 4.2.0 release. Fortunately, the patch still applies fine for me against that release.

I've reopened the issue so this can get fixed in the current branch.

Please read my comment above and the updated project page for this theme.

I will not accept or merge any patches for this issue.

Hello,

This is very intentional. This theme was built to have no opinion about how the page header and menu should be styled.

The purpose of this theme is to be a starting point that can be extended with a sub-theme that will handle tasks like styling the headers and menus. I have updated the description for this theme to hopefully clarify the intent.

Marking won't fix.

Hello,

This is very intentional. This theme was built to have no opinion about how the menu should be styled.

The purpose of this theme is to be a starting point that can be extended with a sub-theme that will handle tasks like styling the menus.

Marking won't fix.

I tested the dev release with copies of existing sites and was able to log in after running the update. I can't speak for everyone, but it worked for me, so +1 vote for RTBC.

Thanks!

I can confirm with above. I had to do the same fixes on one of our custom modules earlier today.

micahw156 → created an issue.

For what it's worth, we've been running the patch from #3 above in production for nine months with no ill effects.

Tagged 1.1.0 and rolled new release. Marking fixed.

Marking fixed.

Marked 📌 Automated Drupal 11 compatibility fixes for yayb Closed: duplicate duplicate.

Marking this duplicate of 📌 Preparing for Drupal 11 Active . I will perform needed updates manually.

micahw156 → created an issue.

micahw156 → created an issue.

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.