🇺🇸United States @wells

Thanks, @natts -- not sure how I missed that one initially. I came via ✨ Support Google Analytics consent mode Fixed and failed to check for an existing issue!

Added. Thanks!

I opened 🐛 Form default value of configuration setting "Enforce Privacy Consent Policy" is incorrect. Needs review to address #19.

wells → created an issue.

I'm also dealing with the issue of lost events after updating from 2.0.2.

I'm not sure how the consent flag was set initially but one thing I just noticed is that the "Enforce Privacy Consent Policy" checkbox always loads in the google tag setting form as checked even if consent mode is disabled. So if other unrelated changes are made in the UI it resets consent mode to true.

Not still in active development. I’ll be happy to review and merge an MR if anyone does want to work on the OAuth flow though.

Added -- thanks!

Ok yeah this makes sense. Hopefully this is good enough to get folks through review. Will cut a new release now.

Re-roll of #45 attached for Drupal 10.2.x.

Thanks for reporting -- fixed in version 3.0.0.

wells → made their first commit to this issue’s fork.

I'm also experiencing this issue however the patch here just leads to an exception further down the line:

Error: Call to a member function load() on null in Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget->formElementEntities() (line 831 of /app/docroot/modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php).

wells → created an issue.

In Drush 11 I'm also getting a similar exception. Patch in #12 fixes the issue.

Error: Call to a member function getSelf() on null in /app/docroot/modules/contrib/warmer/src/Drush/Commands/WarmerCommands.php on line 118 #0 [internal function]: Drupal\warmer\Drush\Commands\WarmerCommands->enqueue(Array, Array)
#1 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#2 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#3 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#4 /app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#5 /app/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#6 /app/vendor/symfony/console/Application.php(1081): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#7 /app/vendor/symfony/console/Application.php(320): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#8 /app/vendor/symfony/console/Application.php(174): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#9 /app/vendor/drush/drush/src/Runtime/Runtime.php(124): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#10 /app/vendor/drush/drush/src/Runtime/Runtime.php(51): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /app/vendor/drush/drush/drush.php(79): Drush\Runtime\Runtime->run(Array)
#12 /app/vendor/drush/drush/drush(4): require('/app/vendor/dru...')
#13 /app/vendor/bin/drush(119): include('/app/vendor/dru...')
#14 {main}
Error: Call to a member function getSelf() on null in Drupal\warmer\Drush\Commands\WarmerCommands->enqueue() (line 118 of /app/docroot/modules/contrib/warmer/src/Drush/Commands/WarmerCommands.php).
 [warning] Drush command terminated abnormally.

Note this idea is approved and implementation is now happening over at #3398293: Consolidate local development environment documentation to recommend DDEV → . I don’t think concerns around the idea were adequately addressed but continuing the conversation here is not productive.

[...] the overall goal is reducing the barriers for less technical people who may not be doing development at all (evaluators, designers, etc) for several reasons stated in the original issue summary.

I missed that point in the initial read of the issue. Recent discussion seems a lot more focused on DX while the issue description does indeed target "less technical people". Honestly I don't think either DDEV or Lando really fits that purpose. In both cases there is still a chain system dependencies and general technical know-how required just to get up and running.

Consider a non-technical user taking the DDEV path. Presumably it would look something like:

1. Arrive at Get Started with DDEV
2. Determine OS in use.
3. Select appropriate OS tab.
4. Verify system requirements.
5. Click to Docker Installation (assuming macOS here just because that is what I'm using).
6. Choose between Colima and Docker Desktop (lets assume Colima since it's DDEV's recommendation).
7. Figure out how to run a terminal command.
8. Navigate to Homebrew and figure out how to install it.
9. Install Colima with Homebrew.
10. Start Colima via CLI.
11. Navigate to DDEV Installation.
12. Install DDEV with Homebrew (as recommended).

There's no real guidance from that point but presumably for our Drupal example the user would navigate to CMS Quickstarts - Drupal and follow the guidance there.

Compare to Lando:

1. Arrive at Getting Started.
2. Read a lot of text.
3. Eventually make your way to Installation.
4. Determine OS in use.
5. Verify system requirements.
6. Optionally watch installation procedure video.
7. Navigate to Lando's GitHub releases (recommended path).
8. Determine your system architecture 😱.
9. Download the lando-x64-v3.20.4.dmg (again, just using my own environment as an example).
10. Open the DMG and follow the installation procedure (a reasonably started macOS thing but even that is often debated).

Here again not much guidance from there.

I don't think either experience is any better than the other and neither is appropriate for an evaluator/less technical user. Drupal's own documentation could address some of this friction but absolutely not all of it. And I don't think even a significant amount of it.

I don't think we can solve this for less technical users by defining a default/recommended/official tool. We can certainly provide some improved DX and knock out some very old recommendations though by presenting a couple of good starting points for developers.

I think we're past the point of personal attestations adding much here. Recent comments seem to establish that DDEV and Lando are equal features-wise and there are Drupal community members using both. Which is great!

With that in mind I would be happy to get behind language like this:

Drupal development is best with the help of a tool that can manage Drupal's dependencies quickly and easily, without needing to install everything on the developer's computer. The Drupal community recommends the following options:

• DDEV: CMS Quickstarts - DDEV Docs
• Lando: Drupal Lando Plugin - Getting Started

From there let additional options be added or removed, ordered alphabetically. As long as a tool is being actively developed and has shown a commitment to Drupal (as both DDEV and Lando are and have) it should be added to the list.

[...] I do actively want to discourage people from using XAMPP, and we have a lot of documentation on how to use XAMPP

Yes that's perfectly reasonable.

DDEV and Lando at least have their own primary references for how to get started in Drupal. Instead of defining a default could Drupal's documentation point directly to those sources for each tool?

@wells I don't use an IDE at all, I just use vim with a minimal plugin configuration, and Drupal runs fine.

Vim may not be an IDE but it is still a decision you made to use as an editor. One could still argue, for example, that vim (or whatever else) be the default or official code editor for getting started with Drupal. My point there is not about the tool but about the concept of setting a default.

It doesn't however run fine without PHP and a database, so I don't think these are equivalents.

True but we're talking about defining a default for how to bring those dependencies in to a developer tool chain, not about the dependencies themselves. Those requirements are the same with or without a development container or defined default.

We do however recommend MySQL, while also supporting PostgreSQL and sqlite (see https://www.drupal.org/docs/getting-started/system-requirements/database → ...) - this is a much more permanent decision that which local development environment to use and we've been opinionated on that more or less forever.

This actually strikes me a very interesting example. Yes, Drupal does support PostgreSQL and sqlite but how often are those DBs used in practice? I'll grant I have no data for this but I imagine the vast majority of projects use the default recommendation of MySQL because it's the default. If anyone has actual data on this I'll certainly concede the point if those DBs have a non-trivial use share.

PostgreSQL and sqlite are certainly not harmed by that because they are general purpose tools. DDEV, Lando, etc. are also (mostly) general purpose tools but I'd argue they have a much greater reliance on the frameworks they support. If Drupal picks a default it seems much more likely the others will be harmed for it.

Let's change 'official' to 'default' in the issue title, but it's another reason the issue summary could use an update.

My only concern here is... what is the real different between "official" and "default". Obviously the two words have different meanings but if we're talking about changing every instance of documentation to use DDEV as the default the practical difference seems almost non-existent.

Maybe this is a strawman but... would we do the same thing for an IDE? In theory you could make a similar argument that we don't want new users to have to weight 3-5 different options before selecting an IDE to use for Drupal development.

I have used Lando, DDEV, and Acquia Dev Desktop and ultimately ended up with Lando. I have not interacted with DDEV developers or community for comparison but support from the Lando community has been great when I've needed it. Lando also has a very nice plugin system that is easy to build on.

I don't think it makes sense to promote any one solution over another unless it is maintained and supported as part of Drupal's core offering (think Laravel Homestead).

FTR I reverted https://git.drupalcode.org/project/panelizer/-/merge_requests/1/diffs?co... as it broke Drupal 9 compatibility.

wells → made their first commit to this issue’s fork.

I didn't mean to imply Social Auth Twitter could be an alternative -- was just pointing out that module is more up-to-date but still only supports the older Twitter API.

This module should be able to work with a similar process but may or may not need code changes as well.

I'm happy to review a patch if anyone is able to get things working but I'm not a Twitter user myself so this isn't something I've been able to dig in to.

Are you saying that you cannot post tweets with Oauth 2 but you can with v1?

I believe that to be the case. Yes. Even with the latest version of Social Auth Twitter (where things are more up to date) the v2 API is not supported.

Attaching patch to use Drupal's once functionality.

wells → created an issue.

Test failures were in the base branch. This is good to go. Thanks for contributing!!

Ok, thanks for the info!

Ok -- I see that more clearly in the documentation now.

How is "active" determined for these cases? The term is used a lot in the documentation but not really defined. E.g. @MaskyS's most recent activity I see is from Jan 2018.

Ok so I've been through this process a number times now and I'm still a bit confused... after the initial 14 day waiting period and moving to this queue, we need to wait another 14 days?

Yes.

On 7 Sept 2023 I reached out to @gvso about this as he has helped with numerous other projects in the Social Auth ecosystem. Unfortunately he does not have enough privileges on this project to add other maintainers.

On 8 Sept 2023 I reached to @MaskyS and @neel24 via their drupal.org contact forms but have not heard back from either of them.

Edit: oops sorry -- just realized that question is probably for @apaderno.

Moving to project ownership queue.

Thanks for the catch and fix!

wells → created an issue.

Thanks for you work on this, @aleix! This is a great new feature.

wells → created an issue.

wells → made their first commit to this issue’s fork.

And that is indeed the issue. Thought it was just a 10.x thing hah.

I have opened 🐛 $defaultTheme missing for tests Fixed to address the tests issues. Once that is merged tests here should pass again.

And here's a plain diff of the MR since tests are run automatically.

Ah but this is still an issue on the 8.x-1.x branch...

Oops the last patch was just run against the wrong branch... trying 9.x again now.

Oops wrong branch!

wells → created an issue.

@VladimirAus -- tests are failing on the base branch, not this patch.

Drupal\Tests\dfp\Functional\GlobalSettingsTest::testGlobalSettings
Exception: Drupal\Tests\BrowserTestBase::$defaultTheme is required. See https://www.drupal.org/node/3083055 → , which includes recommendations on which theme to use.

@jzavrl thanks for the issue and PR -- could you look in to why the tests are failing on D10.1?

Committed and included in 4.0.2 -- thanks for the patch and tests!

I would support this as an admin option. Thanks for sharing!

Yeah. Unfortunately I got too far away from #19... I was trying to prototype a way to keep everything under one module but without having to group tags in to submodules. Parts of that are very confusing and it just feels a little silly to have e.g. 10+ classes that each represent the "@id" property exactly the same way.

Following up on the token lead... in my metatag.metatag_defaults.global.yml config I have (among other things):

uuid: 0031d9a6-85cc-41f3-aa0b-46660705ab08
langcode: en
status: true
dependencies: {  }
_core:
  default_config_hash: sL588ui1E_8-2c_UupwyYxcqX2OVyMFp3HTLbbFqvPc
id: global
label: Global
tags:
  title: '[current-page:title] | [site:name]'
  canonical_url: '[current-page:url]'
  og_url: '[current-page:url]'
  og_site_name: '[site:name]'
  og_title: '[current-page:title]'

I found that if I remove the two references to [current-page:url] from the config the issue goes away. So it seems this somehow has to do with the handling of that particular token for Media entities (or at least for Media entities as configured on my site).

And thinking about it now having current-page references in the global config is probably unwise. So at least in this case I will probably work around the issue but making those configuration more precise.

On the 2.0.x-dev version this is at least somewhat related to 📌 Support JSON API, REST, GraphQL and custom normalizations via new computed field Fixed .

In my testing I found the issue is triggered somewhere along the line when the metatag_computed field is computed in \Drupal\metatag\Plugin\Field\MetatagEntityFieldItemList::computeValue. Specifically it seems to come up after all the relevant entities for the media library view have been computed (i.e. there doesn't appear to be a specific entity or anything triggering the issue).

I further traced this to \Drupal\metatag\MetatagManager::processTagValue where if I comment out the line handling token replacement the issue goes away. This obviously is not a solution as it disables token replacement in tags but maybe it points to something deeper in \Drupal\Core\Utility\Token::doReplace? There were kind of recent changes to that handling in #2580723: Fix token system confusion, with new function Token::replacePlain() → but I haven't made it so far as testing this with different versions of Drupal core (and I'm thinking that's a dead end anyway).

I also haven't been able to test this with a fresh Drupal installation and the relevant modules yet so I'm not ruling out something specific to our entity configurations or hooks.

I never saw this in 8.x-1.x versions but I am now seeing the exact same issues as described in the initial issue report after upgrading to 2.0.0. Looks like there isn't much here to go on but I'll try to dig in and follow up on what I find. Downgrading to 8.x-1.26 works around the issue (at least in my use case).

I'm leaving the version as 8.x-1.x-dev here since the issue still seems to be active there as well.

Committed -- thanks (again) for the report and patch!

@AlvaroDeMendoza thanks for the patch --

+    // Links can either be reset or deleted, not both.
+    if ($this->isResettable()) {
+      $operations['reset'] = [
+        'title' => $this->t('Reset'),
+        'url' => $this->getResetRoute(),
+      ];
+    } elseif ($this->isDeletable()) {
+      $operations['delete'] = [
+        'title' => $this->t('Delete'),
+        'url' => $this->getDeleteRoute(),
+      ];
+    }

Since these links are not ressetable lets just have the delete operation here (i.e., get rid of the unnecessary if-else structure).

FTR I just sent drupal.org contact emails about this issue to as many of the maintainers of this module as I could (I got blocked after sending 10, hah). Hopefully someone will pop in to look at this.

Oh damn I thought this already got committed, hah.

These test fails looked valid. Anyone on this issue know what they stem from?

Thanks for flagging.

Looks like this is a result of changes in 📌 Entity operations for menu links are hardcoded in edit menu form Fixed (change record: Operations link for MenuLinkContent entity are moved along with entity list builder → ).

The two methods that need to implemented are getResetRoute and getOperations.

I'm not quite sure why \Drupal\colossal_menu\Entity\Link is inheriting \Drupal\Core\Entity\ContentEntityBase instead of \Drupal\Core\Menu\MenuLinkBase. Worth looking in to whether that change should be made as the base class already provides getResetRoute and getOperations.

Yep -- thanks for flagging. This is indeed fixed upstream.

Thanks for reporting and providing a patch!

Looks good. Thanks for contributing!

I think this same pattern should be used across all implementers (I just did something similar for Social Auth PBS) so while I'm happy to merge this to improve the current situation ideally we eventually make a change for this upstream in the Social Auth module itself.

@joseph.olstad OK that makes sense -- do we have anything else to do here?

I can reproduce using just the Umami demo profile and it's default menu items.

Here is a menu item with no active trail from the current 9.5.x HEAD:

And here is the same environment with 🐛 copyRawVariables should support default route parameters Fixed changes reverted:

@larowlan could it be relevant I'm using the standard profile and not Umami?

I'll try Umami next...

@joseph.olstad what happens you upgrade a text format from CKE4 to CKE5? Do the configuration settings get migrated correctly?

@larowlan thanks -- appreciate the explanations!

I'll try to get a test in with 11.x as well. Is it relevant that your new test failed (#19)?

@Rajab Natshah -- thanks for getting this started. Note that this particular implementer will take a good deal more effort than others because of Twitter's 3-legged OAuth flow. Upgrading for 4.0.x compatibility is definitely doable but will require more extending and customization of the newly added base functions.

Thanks for reporting. This issue exists in the Social API module: https://git.drupalcode.org/project/social_api/-/blob/4.0.x/src/User/User...

Moving over to the Social API issue queue.

To address what you said in point 1 and 2, Maybe the view could be placed in config/optional as said in: https://www.drupal.org/node/2453919 → , so view will be installed when dependencies are met.

Yep I think that makes sense. Though it would still only address new installs -- we'd want an update hook as well.

Referring the 4th point, are you thinking with dynamic field with a fieldwidget to be seen in edit form? Or a block with entities list shown in edit form?

I think a block with entities shown in the edit form (with the delete option for each entity). Social Auth Twitter is the module I was thinking of that does something like this -- see: https://git.drupalcode.org/project/social_post_twitter/-/blob/3.x/social.... Not sure if that approach is still the best for 10.x+ but that's the idea.

@aleix --

Thanks for taking this up! I have tested the branch out and it works as designed however I have a few bigger concerns:

1. I'd rather not have a hard requirement on Views. While it's highly likely for sites to have Views installed and enabled I don't think Social Auth should be requiring it. We'll want to make this an optional feature.
2. There is currently no migration path. We'd want an update hook that checks if Views is enabled and installs the new view.
3. The view itself is pretty basic. Ideally there should be a way to search on username and filter by provider.
4. While the view is useful I would rather be able to see/manage profiles directly from the user edit form. This would take better advantage of the core user functionality and I think entirely eliminate the need for a custom view. I can't recall off the top of my head but I know there is a some module that has entities related to a user that can accessed and managed from the user edit page easily. This would provide a good example and I'll update again if I can remember what module it is...

@larowlan I'm a little unclear on where/how I should be testing this. My test steps are from the 9.x branch and I can still reproduce this issue with the latest commits there. I'm not sure if this regression affects 10.x (and tangentially I'm unclear on what the 11.x branch is for).

Should I be testing from the 11.x branch? Would this not be addressed in 9.x with the upcoming EOL?

Thanks for catching! Patch looks good. Applied and new version incoming...

Using patch #5 the missing sections of the site are rendering again, but the patch creates new problems with the site breadcrumbs. The site has both current_page_crumb and menu_breadcrumb installed and with patch #5 applied (no issues with #2 reversion applied) I'm getting duplication on the last breadcrumb entry and only on term pages. Sorry, I have not been able to isolate why.

Thanks for sharing. This at least confirms my assumption that my attempted fix there has some issue. I'm at least going to remove that patch from display on this issue for now.

Not using taxonomy_menu and yeah those core repro steps are in this issue description as well.

I'm not sure if that's necessary though. And it will likely introduce complications w.r.t. configuration management for someone wanting to migrate an instance between the two modules and/or ultimately upgrade from CKE4 to CKE5 (not sure if we can properly handle config from a different module for the update path).

Hm, in theory this should be possible, I think? Back when I got the 3.0.x version started things were still a bit fluid w.r.t CKE5 API in Drupal and I think at the time it was not possible to do both (or at least I wasn't able to find a good solution for it).

I'm definitely open to this but I don't have the use case myself or extra time to dig in on it. Happy to support anyone who wants to work on this however I can, or I will take a look at it some time in the future.

Thanks for testing, @roman.haluska. Be aware that some tests are still failing with the patch so you may face other regression. I haven't had the time yet to take a look at the fails.

@goodboy -- I'm not able to reproduce this error. Could you provide reproduction steps that start from a clean install of just Drupal 10 and this module? Otherwise more detailed information about the configuration where you are having this issue or a complete backtrace of the error would be helpful.

@danielspeicher you may want to inspect your phpcs config. Here is the output from your branch:

~/PhpstormProjects/http_client_retry 3358215-set-retry-enabled > vendor/bin/phpcs                                 
.................E. 19 / 19 (100%)

FILE: src/Http/HttpClientMiddleware.php
-------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-------------------------------------------------------------------------------------------
 78 | ERROR | [x] TRUE, FALSE and NULL must be uppercase; expected "NULL" but found "null"
-------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
-------------------------------------------------------------------------------------------

Time: 2.52 secs; Memory: 14MB

Anyway yeah I'll put in a quick fix for this before merge. Thank you!

All sounds good. Thanks for your work on this!

Interesting. I'm open to this and I think it's different enough from 💬 Redirect to registration page Active . There could be other use cases for sending users off to different pages of any type after registration specifically.

Closing in favor of ✨ Provide safe storage of client's secrets for implementer modules Active which has a bit more context.

Yes, this would be ideal. We had 📌 Implementing Key for storing API Credentials Closed: duplicate planned for the 4.0.x work but unfortunately we didn't get to it in time. I'm not totally sure this would be breaking but I'm guessing it would...

Regardless I'm happy to consider this for anyone who has some time to spend on it.

This ticket has more details so I'm gonna close 📌 Implementing Key for storing API Credentials Closed: duplicate as a dup.

Congrats! I have added Social Auth Nextcloud to list of 4.0.x implementors over on the Social Auth project page.

I'm gonna close this issue and we'll track the ongoing work in ✨ Derivative network plugins Fixed .

Aleix -- thanks for your work on this. A few CRs and one question --

+    // network id filtering the colon that adds plugin derivative system
[...]
+    // network id filtering the colon that adds plugin derivative system

I don't think either of these comments are needed. What's happening here is pretty clear from the method names. If you think there is something worth documenting here these comments can be improved with some more details (I think they are out of date now, anyway?).

+    $network_config = $this->configFactory->get("{$network_id}.settings");
[...]
+    $this->configFactory->getEditable("{$network_id}.settings")

You don't need to curly-brace variables -- let's change these to use get("$network_id.settings");.

And looking at your NextCloud implementation I just have one clarifying question: did you end up dropping the idea to use colons? Your Drupal\social_auth_nextcloud\Form::getEditableConfigNames method has a seemingly unnecessary str_replace(".", ".", $network->getDerivativeId()); and Drupal\social_auth_nextcloud\Form::getFormId has str_replace(":", ".", $network->getPluginId());. Just trying to understand the pattern used.