@jabeler

Good for ECA. Its interface is overly complex, and has a steep learning curve with multiple sub modules required for adding even simple single-step actions.

BTW, it's already listed as an alternative module on the main Rules page, and this really has nothing to do with the issue being discussed here.

Rules has a more intuitive interface, and I prefer it over ECA. Not to mention with Rules you can easily get an overview of the entire workflow on a single page without having to dive deep into individual actions or triggers to see details. I suppose ECA could be useful for mapping more complex workflows with multiple, conditions, paths, and actions, but for most things Rules works better.

10.3 does appear to introduce breaking changes and other modules could certainly be affected.

https://www.drupal.org/project/rules/issues/3454056#comment-15652473 📌 [10.3] Update ConditionManager to support PHP Attributes Active

Sure, but that applies to Drupal core as well since 7.x is still the largest install base. Rules is still a fairly widely used module, and having it installed on 10.3 causes things to crash and burn in spectacular fashion.

Of course, people should always keep backups and test updates on a dev/staging site before upgrading live sites but as you see by the early reports linked above that isn't always happening.

I suppose there is a question around whether core release notes should be responsible for listing all known incompatibilities, and I would say the answer is no...but there could be exceptions.

My sites will continue to run 10.2.x until an update for Rules is available (or a replacement is found) so I'm just trying to help others avoid a ton of frustration here.

@TR

Until the necessary changes for 10.3 are added, it may make sense to update the Composer versioning for Rules - which presumably would prevent people from inadvertently updating to 10.3 and breaking their sites.

I believe something like this would do it.

^9.1 || 10.0 - 10.2

jabeler → created an issue.

Following here, and renaming the issue so others can more easily find it (related issue was closed as a duplicate).

Also seeing this with a fresh install of the Rules module with zero rules added.

Uninstalling the Rules module fixes the issue.

jabeler → created an issue.

jabeler → created an issue.

Colors are back to normal in the latest dev build (21 Dec 2023 at 11:42 UTC). Thanks!

Personally, I would go with a bit more space.

I think 6px would be closer to what the original Gin sidebar spacing is.

Here's a few screenshots comparing 4px, 6px, and 8px.

I saw this issue when updating yesterday as well. The packages which were not getting updating automatically (and were blocking the Drupal update) were drush/drush and aws/aws-sdk-php.

Updating these two items explicitly allowed the normal Drupal update to proceed as expected.

jabeler → created an issue.

jabeler → created an issue.

jabeler → created an issue.

I have tracked down a way to workaround this.

Changing the cookie_samesite option in the site’s services.ymlfrom Strict to Lax allows these redirected links in Gmail and Outlook to work normally.

I’m not certain if this broken behavior is expected or can be fixed, but I have added this info to the OP.

Update! I was able to locate a log entry which is created when these links fail.

Path: /user/reset/xxxxxx. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: in Drupal\user\Controller\UserController->getResetPassForm() (line 194 of /home/xxx/xxx/web/core/modules/user/src/Controller/UserController.php).

I can replicate this issue 100% of the time by clicking reset links in both the gmail and outlook webmail UIs.

As before, if I copy paste the link into a browser manually (either before or after clicking in the web UI) the reset link works as expected.

I have seen it in the latest versions of Safari and Brave on Mac, so I don’t think it’s browser specific.

This is also broken when using outlook.live.com to view email.

Links are being routed through: https://na01.safelinks.protection.outlook.com/?link

I haven’t been able to find a workaround for this so far.

I have also tried to replicate this on Drupal.org, but these links appear to work normally. We are running Drupal 10.1.6 on PHP 8.2, but am not sure what versions the main .org site is on. The reports we have been seeing do seem to coincide with the release of 10.1.6, but that could just be a coincidence.

I have tried with and without browser plugins disabled, so I don’t think that is related.

This is definitely not a case of a malware scanner visiting a one-time link and invalidating it, because after clicking the link (and having it fail) I can copy/paste the link into a browser and it works. This of course is a direct link instead of being routed through Gmails servers.

I suppose it could be related to a specific module installed on Drupal, but I can’t say which may be causing an issue as there are no relevant log entires when the links fail. Here’s a list of the modules we currently have installed on the site. If others are seeing issues maybe can we narrow it down to one of these.

• Add To Head 8.x-1.0-beta1
• Admin Toolbar 3.4.2
• Advanced CSS/JS Aggregation 6.0.0-alpha1
• Aggregator 2.1.4
• Backup and Migrate 5.0.3
• Backup and Migrate: AWS S3 5.0.7
• Block Classes 1.0.2
• CAPTCHA 2.0.5
• Chaos Tool Suite (ctools) 8.x-3.14
• CloudFlare 2.0.0-alpha1
• Coffee 8.x-1.3
• Color backport 1.0.3
• Discourse SSO 2.0.0-rc7
• DXPR Theme Helper 1.0.4
• Email Confirmer 8.x-1.0-beta7 (issue predates installation of this)
• External Links 8.x-1.7
• Font Awesome Icons 8.x-2.26
• Gin Login 2.0.3
• Gin Toolbar 8.x-1.0-rc4
• Honeypot 2.1.3
• Key 8.x-1.17
• Login Email or Username 2.1.0
• Mail System 8.x-4.4
• Menu Items Visibility 1.1.0
• Message Banner 2.0.0 (issue predates installation of this)
• Metatag 2.0.0
• Pathauto 8.x-1.12
• Persistent Login 2.1.1
• PHPMailer SMTP 2.2.3
• Purge 8.x-3.5
• reCAPTCHA 8.x-3.2
• reCAPTCHA v3 2.0.2
• Redirect 8.x-1.9
• Redirect 403 to User Login 2.2.1
• Schema.org Metatag 3.0.1
• Simple XML sitemap 4.1.7
• Token 8.x-1.13
• Typed Data API enhancements 8.x-1.0-beta2
• User Name Validation 8.x-1.2
• Views Bulk Operations (VBO) 4.2.5
• Zendesk remote authentication 3.0.0-alpha8
• Bootstrap5 3.0.10
• DXPR Theme | Drupal Theme | Low-code Drupal 10 Bootstrap Theme 5.2.0
• Gin Admin Theme 8.x-3.0-rc7

jabeler → created an issue.

jabeler → created an issue.

That wouldn’t help in this case, since the issue was related to a custom sub-theme and not something that could be installed or updated via composer.

It’s related to how versioning of sub-themes is handled. I don’t think it’s a bug, but IMHO it’s not an ideal behavior since the warning message directs you to the updates page which isn’t ever going to show an update for sub-theme as available.

I managed to track this down. The root issue was I am using a subtheme and the parent theme (DXPR) had been updated.

In the subtheme’s xxx.info.yml file it had references to the original version info of the parent theme, and this was throwing a false positive in Drupal.

To resolve this, I commented out the following:

# Information added by Drupal.org packaging script on 2023-04-20
# version: '5.1.0'
# project: 'dxpr_theme'
# datestamp: 1682004288

Simply updating the version number to match the parent theme also worked, but I didn’t want to deal with this again in the future.

Confirmed 2.1.1 working perfectly on Drupal 10.1.2.

Thx!

@TR

First off, we should all be thankful to you and the other maintainers who have worked to maintain this module over the past ~12 years. Personally, this is the most effective option I’ve found for combatting spam on contact forms without adding tons of frustration for users (like most of the captcha options).

I think this issue in particular went unnoticed by most for so long since Honeypot generally worked fine. The Drupal 10.1 update started flagging this an issue on the status report page, so naturally this is leading people to become more aware of the problem and seek out a fix (myself included).

I totally understand where you’re coming from. Users often have unreasonable expectations for open source projects, and expect/demand prompt support without offering much in return. IMHO, it doesn’t help that Drupal has lost some of the momentum it had in the 7.x days due to the poor transition to 8.x+ which likely has led to some to diverting their focus elsewhere.

With that said, I think there are many who would be willing to support a handful of project such as this that their sites rely on, but don’t have the development skills or time to make meaningful contributions. Instead, they may be willing to offer some sort of monetary support, either one-time or on recurring basis. I don’t know where this falls in the spirit of the Drupal project or organization, but compared to something like Wordpress which has countless paid/or subscription type modules I don’t think it’s too crazy of an idea.

I’m currently running the dev branch on the latest 10.1.1 release of Drupal, and everything is working great. Sure, it would be nice to have a tagged release at some point, but most should be able to use 2.1.x-dev for now or add the patch from @catapipper in post #64 to get things updated to avoid the error flag in Drupal.

Anyways, thanks again for your work here. :)

Thanks for looking into this.

I haven’t had a chance to test of a fresh install, but this is the list of modules from composer. The actual installed versions are the most current.

I thought the items in bold may be affecting the login/registration flow, so I tested with those disabled but that didn’t seem to have an effect on the registration page toggle. I haven’t had a chance to do further elimination tests yet.

"composer/installers": "^2.0",
"cweagans/composer-patches": "^1.7",
"defuse/php-encryption": "^2.3",
"drupal/add_to_head": "^1.0@beta",
"drupal/admin_toolbar": "^3.4",
"drupal/advagg": "^6.0@alpha",
"drupal/aggregator": "^2.0",
"drupal/backup_migrate": "^5.0",
"drupal/backup_migrate_aws_s3": "^5.0",
"drupal/block_classes": "^1.0",
"drupal/captcha": "^2.0@beta",
"drupal/cloudflare": "^2.0@alpha",
"drupal/coffee": "^1.3",
"drupal/core-composer-scaffold": "^10.0",
"drupal/core-recommended": "^10.0",
"drupal/discourse_sso": "^2.0@RC",
"drupal/dxpr_theme": "^5.1",
"drupal/extlink": "^1.7",
"drupal/field_group": "^3.4",
"drupal/flood_control": "2.3.x-dev@dev",
"drupal/fontawesome": "^2.25",
"drupal/gin": "^3.0@RC",
"drupal/gin_login": "^2.0",
"drupal/honeypot": "2.1.x-dev@dev",
"drupal/login_emailusername": "^2.1",
"drupal/mailsystem": "^4.4",
"drupal/masquerade": "^2.0@RC",
"drupal/menu_items_visibility": "^1.1",
"drupal/metatag": "^2.0",
"drupal/pathauto": "^1.11",
"drupal/persistent_login": "^2.1",
"drupal/phpmailer_smtp": "^2.2",
"drupal/purge": "^3.4",
"drupal/r4032login": "^2.2",
"drupal/recaptcha": "^3.1",
"drupal/recaptcha_v3": "^2.0@alpha",
"drupal/redirect": "^1.8",
"drupal/rules": "3.x-dev@dev",
"drupal/schema_metatag": "^3.0",
"drupal/simple_sitemap": "^4.1",
"drupal/username_validation": "^1.2",
"drupal/views_bulk_operations": "^4.2",
"drupal/views_data_export": "^1.3",
"drupal/zendesk": "^3.0.0-alpha7”

Ok, as a last resort I did a quick restart of the server and can no longer reproduce these errors.

Strange, but fixed I guess.

I've done a search and haven't found anything. Also searched the database, and no luck there either (except for references in Watchdog).

The only other related plugin installed on this site is schema_metatag 3.0.1. I'm not aware of anything else that would be calling MetatagServiceProvider.php

These are the full error messages I'm seeing.

Warning: include(): Failed opening '/home/XXX/d10/web/modules/contrib/metatag/src/MetatagServiceProvider.php' for inclusion (include_path='/home/XXX/d10/vendor/pear/archive_tar:/home/XXX/d10/vendor/pear/console_getopt:/home/XXX/d10/vendor/pear/pear-core-minimal/src:/home/XXX/d10/vendor/pear/pear_exception:.:/opt/cpanel/ea-php81/root/usr/share/pear') in include() (line 571 of /home/XXX/d10/vendor/composer/ClassLoader.php)

Warning: include(/home/XXX/d10/web/modules/contrib/metatag/src/MetatagServiceProvider.php): Failed to open stream: No such file or directory in include() (line 571 of /home/XXX/d10/vendor/composer/ClassLoader.php)

Was installing 2.0 (via composer) directly on top of 8.x-1.26 the proper way to update, or should have I followed a special process?

Thanks for the help!

I've tried that a few times (also tried using drush cr). The action of clearing the caches is actually what triggers this in the logs.

If I don't clear the caches there are no new errors like this in the logs.

jabeler → created an issue.

jabeler → created an issue.

+1 for a tagged release. Thanks!

jabeler → created an issue.

That makes sense.

I guess it also makes troubleshooting a lot simpler if most sites are using the same set of components.

I guess to me it seems odd to keep this as a direct dependency at all, unless there is something specific in 2.0 (or Promises in general) that is required by core. I agree with @catch and would simply allow Guzzle to set its own dependancies in all versions moving forward.

Just my 2c, and I’m sure you guys know better than me what impact this has on core.

I can understand that, but since 'core-recommended’ is the recommended option the implications are effectively the same, no?

I don’t imagine that 2.0 is in fact required by core - so this comes down to a packaging issue.

AWS a popular component used on many sites for backups an other things, so allowing these sites to update to 10.1 is likely in Drupal’s best interest.

Actually, I think I read the tree wrong…and Promises is actually a direct dependency of Drupal 10.1.
https://packagist.org/packages/drupal/core-recommended

Here is the full tree.

├──drupal/core 10.1.0
│  ├──asm89/stack-cors ^2.1
│  │  ├──php ^7.2|^8.0
│  │  ├──symfony/http-foundation ^4|^5|^6
│  │  │  ├──php >=8.1
│  │  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  │  └──php >=8.1
│  │  │  ├──symfony/polyfill-mbstring ~1.1
│  │  │  │  └──php >=7.1
│  │  │  └──symfony/polyfill-php83 ^1.27
│  │  │     ├──php >=7.1
│  │  │     └──symfony/polyfill-php80 ^1.14
│  │  │        └──php >=7.1
│  │  └──symfony/http-kernel ^4|^5|^6
│  │     ├──php >=8.1
│  │     ├──psr/log ^1|^2|^3
│  │     │  └──php >=8.0.0
│  │     ├──symfony/deprecation-contracts ^2.5|^3
│  │     │  └──php >=8.1
│  │     ├──symfony/error-handler ^6.3
│  │     │  ├──php >=8.1
│  │     │  ├──psr/log ^1|^2|^3
│  │     │  │  └──php >=8.0.0
│  │     │  └──symfony/var-dumper ^5.4|^6.0
│  │     │     ├──php >=8.1
│  │     │     └──symfony/polyfill-mbstring ~1.0
│  │     │        └──php >=7.1
│  │     ├──symfony/event-dispatcher ^5.4|^6.0
│  │     │  ├──php >=8.1
│  │     │  └──symfony/event-dispatcher-contracts ^2.5|^3
│  │     │     ├──php >=8.1
│  │     │     └──psr/event-dispatcher ^1
│  │     │        └──php >=7.2.0
│  │     ├──symfony/http-foundation ^6.2.7
│  │     │  ├──php >=8.1
│  │     │  ├──symfony/deprecation-contracts ^2.5|^3
│  │     │  │  └──php >=8.1
│  │     │  ├──symfony/polyfill-mbstring ~1.1
│  │     │  │  └──php >=7.1
│  │     │  └──symfony/polyfill-php83 ^1.27
│  │     │     ├──php >=7.1
│  │     │     └──symfony/polyfill-php80 ^1.14
│  │     │        └──php >=7.1
│  │     └──symfony/polyfill-ctype ^1.8
│  │        └──php >=7.1
│  ├──composer-runtime-api ^2.1
│  ├──composer/semver ^3.3
│  │  └──php ^5.3.2 || ^7.0 || ^8.0
│  ├──doctrine/annotations ^1.14
│  │  ├──doctrine/lexer ^1 || ^2
│  │  │  ├──doctrine/deprecations ^1.0
│  │  │  │  └──php ^7.1 || ^8.0
│  │  │  └──php ^7.1 || ^8.0
│  │  ├──ext-tokenizer *
│  │  ├──php ^7.1 || ^8.0
│  │  └──psr/cache ^1 || ^2 || ^3
│  │     └──php >=8.0.0
│  ├──egulias/email-validator ^3.2.1|^4.0
│  │  ├──doctrine/lexer ^2.0 || ^3.0
│  │  │  ├──doctrine/deprecations ^1.0
│  │  │  │  └──php ^7.1 || ^8.0
│  │  │  └──php ^7.1 || ^8.0
│  │  ├──php >=8.1
│  │  └──symfony/polyfill-intl-idn ^1.26
│  │     ├──php >=7.1
│  │     ├──symfony/polyfill-intl-normalizer ^1.10
│  │     │  └──php >=7.1
│  │     └──symfony/polyfill-php72 ^1.10
│  │        └──php >=7.1
│  ├──ext-date *
│  ├──ext-dom *
│  ├──ext-filter *
│  ├──ext-gd *
│  ├──ext-hash *
│  ├──ext-json *
│  ├──ext-pcre *
│  ├──ext-pdo *
│  ├──ext-session *
│  ├──ext-simplexml *
│  ├──ext-spl *
│  ├──ext-tokenizer *
│  ├──ext-xml *
│  ├──guzzlehttp/guzzle ^7.5
│  │  ├──ext-json *
│  │  ├──guzzlehttp/promises ^1.5.3 || ^2.0
│  │  │  └──php ^7.2.5 || ^8.0
│  │  ├──guzzlehttp/psr7 ^1.9.1 || ^2.4.5
│  │  │  ├──php ^7.2.5 || ^8.0
│  │  │  ├──psr/http-factory ^1.0
│  │  │  │  ├──php >=7.0.0
│  │  │  │  └──psr/http-message ^1.0 || ^2.0
│  │  │  │     └──php ^7.2 || ^8.0
│  │  │  ├──psr/http-message ^1.1 || ^2.0
│  │  │  │  └──php ^7.2 || ^8.0
│  │  │  └──ralouphie/getallheaders ^3.0
│  │  │     └──php >=5.6
│  │  ├──php ^7.2.5 || ^8.0
│  │  ├──psr/http-client ^1.0
│  │  │  ├──php ^7.0 || ^8.0
│  │  │  └──psr/http-message ^1.0 || ^2.0
│  │  │     └──php ^7.2 || ^8.0
│  │  └──symfony/deprecation-contracts ^2.2 || ^3.0
│  │     └──php >=8.1
│  ├──guzzlehttp/psr7 ^2.4.5
│  │  ├──php ^7.2.5 || ^8.0
│  │  ├──psr/http-factory ^1.0
│  │  │  ├──php >=7.0.0
│  │  │  └──psr/http-message ^1.0 || ^2.0
│  │  │     └──php ^7.2 || ^8.0
│  │  ├──psr/http-message ^1.1 || ^2.0
│  │  │  └──php ^7.2 || ^8.0
│  │  └──ralouphie/getallheaders ^3.0
│  │     └──php >=5.6
│  ├──masterminds/html5 ^2.7
│  │  ├──ext-dom *
│  │  └──php >=5.3.0
│  ├──mck89/peast ^1.14
│  │  ├──ext-mbstring *
│  │  │  └──php >=7.1
│  │  └──php >=5.4.0
│  ├──pear/archive_tar ^1.4.14
│  │  ├──pear/pear-core-minimal ^1.10.0alpha2
│  │  │  ├──pear/console_getopt ~1.4
│  │  │  └──pear/pear_exception ~1.0
│  │  │     └──php >=5.2.0
│  │  └──php >=5.2.0
│  ├──php >=8.1.0
│  ├──psr/log ^3.0
│  │  └──php >=8.0.0
│  ├──sebastian/diff ^4
│  │  └──php >=7.3
│  ├──symfony/console ^6.3
│  │  ├──php >=8.1
│  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  └──php >=8.1
│  │  ├──symfony/polyfill-mbstring ~1.0
│  │  │  └──php >=7.1
│  │  ├──symfony/service-contracts ^2.5|^3
│  │  │  ├──php >=8.1
│  │  │  └──psr/container ^2.0
│  │  │     └──php >=7.4.0
│  │  └──symfony/string ^5.4|^6.0
│  │     ├──php >=8.1
│  │     ├──symfony/polyfill-ctype ~1.8
│  │     │  └──php >=7.1
│  │     ├──symfony/polyfill-intl-grapheme ~1.0
│  │     │  └──php >=7.1
│  │     ├──symfony/polyfill-intl-normalizer ~1.0
│  │     │  └──php >=7.1
│  │     └──symfony/polyfill-mbstring ~1.0
│  │        └──php >=7.1
│  ├──symfony/dependency-injection ^6.3
│  │  ├──php >=8.1
│  │  ├──psr/container ^1.1|^2.0
│  │  │  └──php >=7.4.0
│  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  └──php >=8.1
│  │  ├──symfony/service-contracts ^2.5|^3.0
│  │  │  ├──php >=8.1
│  │  │  └──psr/container ^2.0
│  │  │     └──php >=7.4.0
│  │  └──symfony/var-exporter ^6.2.10
│  │     └──php >=8.1
│  ├──symfony/event-dispatcher ^6.3
│  │  ├──php >=8.1
│  │  └──symfony/event-dispatcher-contracts ^2.5|^3
│  │     ├──php >=8.1
│  │     └──psr/event-dispatcher ^1
│  │        └──php >=7.2.0
│  ├──symfony/http-foundation ^6.3
│  │  ├──php >=8.1
│  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  └──php >=8.1
│  │  ├──symfony/polyfill-mbstring ~1.1
│  │  │  └──php >=7.1
│  │  └──symfony/polyfill-php83 ^1.27
│  │     ├──php >=7.1
│  │     └──symfony/polyfill-php80 ^1.14
│  │        └──php >=7.1
│  ├──symfony/http-kernel ^6.3
│  │  ├──php >=8.1
│  │  ├──psr/log ^1|^2|^3
│  │  │  └──php >=8.0.0
│  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  └──php >=8.1
│  │  ├──symfony/error-handler ^6.3
│  │  │  ├──php >=8.1
│  │  │  ├──psr/log ^1|^2|^3
│  │  │  │  └──php >=8.0.0
│  │  │  └──symfony/var-dumper ^5.4|^6.0
│  │  │     ├──php >=8.1
│  │  │     └──symfony/polyfill-mbstring ~1.0
│  │  │        └──php >=7.1
│  │  ├──symfony/event-dispatcher ^5.4|^6.0
│  │  │  ├──php >=8.1
│  │  │  └──symfony/event-dispatcher-contracts ^2.5|^3
│  │  │     ├──php >=8.1
│  │  │     └──psr/event-dispatcher ^1
│  │  │        └──php >=7.2.0
│  │  ├──symfony/http-foundation ^6.2.7
│  │  │  ├──php >=8.1
│  │  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  │  └──php >=8.1
│  │  │  ├──symfony/polyfill-mbstring ~1.1
│  │  │  │  └──php >=7.1
│  │  │  └──symfony/polyfill-php83 ^1.27
│  │  │     ├──php >=7.1
│  │  │     └──symfony/polyfill-php80 ^1.14
│  │  │        └──php >=7.1
│  │  └──symfony/polyfill-ctype ^1.8
│  │     └──php >=7.1
│  ├──symfony/mime ^6.3
│  │  ├──php >=8.1
│  │  ├──symfony/polyfill-intl-idn ^1.10
│  │  │  ├──php >=7.1
│  │  │  ├──symfony/polyfill-intl-normalizer ^1.10
│  │  │  │  └──php >=7.1
│  │  │  └──symfony/polyfill-php72 ^1.10
│  │  │     └──php >=7.1
│  │  └──symfony/polyfill-mbstring ^1.0
│  │     └──php >=7.1
│  ├──symfony/polyfill-iconv ^1.26
│  │  └──php >=7.1
│  ├──symfony/process ^6.3
│  │  └──php >=8.1
│  ├──symfony/psr-http-message-bridge ^2.1
│  │  ├──php >=7.2.5
│  │  ├──psr/http-message ^1.0 || ^2.0
│  │  │  └──php ^7.2 || ^8.0
│  │  └──symfony/http-foundation ^5.4 || ^6.0
│  │     ├──php >=8.1
│  │     ├──symfony/deprecation-contracts ^2.5|^3
│  │     │  └──php >=8.1
│  │     ├──symfony/polyfill-mbstring ~1.1
│  │     │  └──php >=7.1
│  │     └──symfony/polyfill-php83 ^1.27
│  │        ├──php >=7.1
│  │        └──symfony/polyfill-php80 ^1.14
│  │           └──php >=7.1
│  ├──symfony/routing ^6.3
│  │  └──php >=8.1
│  ├──symfony/serializer ^6.3
│  │  ├──php >=8.1
│  │  └──symfony/polyfill-ctype ~1.8
│  │     └──php >=7.1
│  ├──symfony/validator ^6.3
│  │  ├──php >=8.1
│  │  ├──symfony/deprecation-contracts ^2.5|^3
│  │  │  └──php >=8.1
│  │  ├──symfony/polyfill-ctype ~1.8
│  │  │  └──php >=7.1
│  │  ├──symfony/polyfill-mbstring ~1.0
│  │  │  └──php >=7.1
│  │  ├──symfony/polyfill-php83 ^1.27
│  │  │  ├──php >=7.1
│  │  │  └──symfony/polyfill-php80 ^1.14
│  │  │     └──php >=7.1
│  │  └──symfony/translation-contracts ^2.5|^3
│  │     └──php >=8.1
│  ├──symfony/yaml ^6.3
│  │  ├──php >=8.1
│  │  └──symfony/polyfill-ctype ^1.8
│  │     └──php >=7.1
│  └──twig/twig ^3.5.0
│     ├──php >=7.2.5
│     ├──symfony/polyfill-ctype ^1.8
│     │  └──php >=7.1
│     └──symfony/polyfill-mbstring ^1.3
│        └──php >=7.1
├──egulias/email-validator ~4.0.1
│  ├──doctrine/lexer ^2.0 || ^3.0
│  │  ├──doctrine/deprecations ^1.0
│  │  │  └──php ^7.1 || ^8.0
│  │  └──php ^7.1 || ^8.0
│  ├──php >=8.1
│  └──symfony/polyfill-intl-idn ^1.26
│     ├──php >=7.1
│     ├──symfony/polyfill-intl-normalizer ^1.10
│     │  └──php >=7.1
│     └──symfony/polyfill-php72 ^1.10
│        └──php >=7.1
├──guzzlehttp/guzzle ~7.7.0
│  ├──ext-json *
│  ├──guzzlehttp/promises ^1.5.3 || ^2.0
│  │  └──php ^7.2.5 || ^8.0
│  ├──guzzlehttp/psr7 ^1.9.1 || ^2.4.5
│  │  ├──php ^7.2.5 || ^8.0
│  │  ├──psr/http-factory ^1.0
│  │  │  ├──php >=7.0.0
│  │  │  └──psr/http-message ^1.0 || ^2.0
│  │  │     └──php ^7.2 || ^8.0
│  │  ├──psr/http-message ^1.1 || ^2.0
│  │  │  └──php ^7.2 || ^8.0
│  │  └──ralouphie/getallheaders ^3.0
│  │     └──php >=5.6
│  ├──php ^7.2.5 || ^8.0
│  ├──psr/http-client ^1.0
│  │  ├──php ^7.0 || ^8.0
│  │  └──psr/http-message ^1.0 || ^2.0
│  │     └──php ^7.2 || ^8.0
│  └──symfony/deprecation-contracts ^2.2 || ^3.0
│     └──php >=8.1
├──guzzlehttp/promises ~2.0.0
│  └──php ^7.2.5 || ^8.0

You’re right! It looks like Promises is actually a dependency of guzzlehttp/guzzle.

I was able to replicate this on a new project by running composer create-project drupal/recommended-project which installs Guzzle 7.7.0, which requires Promises 2.0.

Here is a snippet of the relevant Composer tree.

├──guzzlehttp/guzzle ~7.7.0
│  ├──ext-json *
│  ├──guzzlehttp/promises ^1.5.3 || ^2.0
│  │  └──php ^7.2.5 || ^8.0
│  ├──guzzlehttp/psr7 ^1.9.1 || ^2.4.5
│  │  ├──php ^7.2.5 || ^8.0
│  │  ├──psr/http-factory ^1.0
│  │  │  ├──php >=7.0.0
│  │  │  └──psr/http-message ^1.0 || ^2.0
│  │  │     └──php ^7.2 || ^8.0
│  │  ├──psr/http-message ^1.1 || ^2.0
│  │  │  └──php ^7.2 || ^8.0
│  │  └──ralouphie/getallheaders ^3.0
│  │     └──php >=5.6
│  ├──php ^7.2.5 || ^8.0
│  ├──psr/http-client ^1.0
│  │  ├──php ^7.0 || ^8.0
│  │  └──psr/http-message ^1.0 || ^2.0
│  │     └──php ^7.2 || ^8.0
│  └──symfony/deprecation-contracts ^2.2 || ^3.0
│     └──php >=8.1
├──guzzlehttp/promises ~2.0.0
│  └──php ^7.2.5 || ^8.0

jabeler → created an issue.

I agree, this was great to have for D7 sites and would be nice to have for D10.

If anyone else is looking for the answer, I ended up checking for 'if teaser' to differentiate between items displayed in a blog listing versus full article. This does exactly what I need.

{% if display_submitted and teaser %}
    <a href="{{ url }}"><h2 class="inline-block">{{ label }}</h2></a>
{% else %}
<h1 class="inline-block">{{ label }}</h1>
{% endif %}

jabeler → created an issue.

I believe I may have uncovered the reason why I was seeing issues.

The Drupal.gin.darkmode key is being cached in local storage, and this doesn't seem to get updated if the setting is changed. Clearing the cache doesn't seem to affect this.

If I explicitly delete this key and refresh the page, it does get updated and everything works as expected (see screenshots).

Since this site is not yet live, I don't expect this to be a problem moving forward since all users would get the correct 'auto' key. However, I suppose this could affect sites which are already live and need to change the setting.

Anyways, the login page looks great so thanks for making this available.

No JS errors in any of the browsers.

Very strange.

I can test later on another Mac.

Running Drupal 10.0.8.

It turns out this may be browser dependent.

Works
Chrome (112.0.5615.137)
Firefox (112.0.2)

Doesn't work
Safari (16.4)
Brave (1.50.121)

Tested on macOS 13.3.1 (a)

jabeler → created an issue.

jabeler → created an issue.