🇨🇦Canada @deviantintegral

Oh, and re the issue summary:

Nightwatch testing is extremely unreliable and the cause of many random pipeine test failures.

Our experience across multiple projects is that the underlying framework is almost never to blame for "random" failures. I'm not familiar enough with the core Nightwatch tests to know one way or another. If tests are ported as-is I would expect to see similar random failures. But, I think it's confusing to have two frameworks in core plus a lurking one in Cypress with XB, so standardizing on one, even if it's just "all new frontend tests go in X while we iteratively port tests" would be a win for contributors.

We've standardized on Playwright at Lullabot after evaluating several frameworks, including Nightwatch and Cypress, for reasons mostly covered above. But for anyone using Cypress, take a look at https://sorry-cypress.dev which works well and also has the most hilarious project name!

We have a scaffold we use to run Drupal tests in Playwright, in parallel, inside of ddev. Performance is great - on one project, I could run the entire test suite of ~900 tests locally on my M2 Max Macbook in around 6 or 7 minutes. It's using the same cookie-based routing system for setting up databases, and supports both "fresh install" tests like core and "use an existing database" for much faster visual comparison tests where multiple browsers can safely share a Drupal database.

This certainly isn't close to something that could just come into core (it has a dependency on the Task task runner), but perhaps parts could be useful. Feel free to ping me in Slack or here if there's questions!

https://github.com/Lullabot/playwright-drupal

FunctionalJavascript tests for most - but they are flaky consistently. Not sure if it's the tests themselves, the framework, or what

For all of the test frameworks that market "we solve flakes", we've found that 8 out of 10 times flakes are actually performance and sync bugs in the app and not the fault of the text framework. For example, a CI node was slower and a test interacted with a link before JS had attached. That's rare to happen - but is way more likely with slow phones, bad internet, etc. I don't remember if phpunit has support for this, but playwright has both a --repeat-each and --retries flags which are invaluable debugging locally. If a test passes with --repeat-each 100, you can be pretty confident you've solved the flake!

First off, thanks to the folks who worked on putting this together. There's a lot here that resonates! I'll save my words for areas I think could use additional work - assume I'm giving high-fives for all the other parts 🙌!

In the "How will we win" section:

Include Project Browser with support for Recipes: I think for the target audience of CMS Builders, this could be narrowed to just Recipes. Many (or in our customer base's case, all) of the target audience don't want tools like Project Browser except on development environments. This usually comes from security and design consistency concerns. They also often have unique hosting requirements that would mean they'd need to build something different on top of Package Manager APIs instead. Of course, a team building a CMS could pull in Project Browser from contrib if they wanted to , and it's going to work just fine.

Make it easier for people to build third-party integrations: This is often a top reason customers bring to us as to why they use Drupal. They know they can integrate third-party services in new and unexpected ways because Drupal's APIs are so robust. So I'm not saying this is a bad goal... I think it's just already been met and is well known outside of the core Drupal community.

Streamline the Drupal upgrade process through automated version updates: Like Dave says above, there's a mix of perception and truth about WordPress being easier and cheaper to maintain. However, unlike WordPress and the Drupal CMS target user, CMS builders are sophisticated enough to have at least small engineering teams using tools like GitHub with devops pipelines. We've worked with small teams with 2-3 developers in higher education who still have very robust code review, CI, and automated testing processes. In our consulting with those teams, the issue isn't that updates are automatic - in fact, they have that sorted out through Dependabot or Renovate. The pain is the work keeping up with compatibility changes in Drupal major releases. Yes, it is so much better than it used to be! But to my surprise, even user-visible improvements like upgrading from CKEditor 4 to 5 haven't been considered worth the upgrade time. In fact, given a choice, our customers have almost always chosen to delay feature upgrades and improvements once sites are launched unless security support requires it.

In other words, I think if we want to win this audience, we need to extend our code compatibility timelines, work with upstream to make that possible, and leave automated updates to Drupal CMS.

Speaking of...

Any organization that already has sites built on Drupal core and are maintaining them long term, this will include Drupal CMS sites after they are launched: That's a little surprising! I think including launched Drupal CMS sites kind of undercuts the narrowing of the audience in the first paragraph. I think it would be more focused to change that to "The developers of Drupal CMS". Since most no-code users won't be able to differentiate between core and CMS code, wouldn't their bugs and support requests first go to the Drupal CMS maintainers, who then bring them to core as appropriate? If the audience is Drupal CMS developers, it gives core more focus while also making a clear home for those users in CMS.

I can confirm downgrading to 3.1.0 fixes this issue for us.

Also confirmed this fixes the issue. I discovered the bug independently of this patch, and came to the same conclusion for a fix as what's in the merge request. It'd be great to see this merged!

Here's some replication steps I found for this:

1. Install Drupal 11.0.5 with the Standard profile.
2. Log in as user 1.
3. Edit `services.yml` and set security.enable_super_user: false.
4. Clear caches to rebuild the container.
5. Remove the administrator role from user 1.
6. Note user 1 still has access to administrator functions.

Or, from the CLI if you have a Drupal project created with ddev:

cat > web/sites/default/services.yml <<EOD
parameters:
  security.enable_super_user: false
EOD
ddev drush -y si && \
ddev launch $(ddev drush uli) && \
ddev drush user:role:remove administrator admin && \
ddev launch # This browser tab will still have admin until you clear caches.

Here's a screen recording of the issue.

deviantintegral → created an issue.

When installing with the standard profile, UID 1 gets the Administrator role. It's easy to miss this needs to be removed for the policy to be effective.

Interesting idea! You don’t happen to have any mockups of what you’re hoping to build?

Have you thought at all about perhaps doing something with the new navigation menu instead? We’ve thought a little about it but haven’t done anything yet.

Yep, fair enough. We've written a few articles about our ADRs, the ADRs themselves are intentionally not how-to's. Thanks for taking a look!

Yes, sorry I should have said I did read those docs. I just wasn't sure where to consider these. It's kind of "How-to" like?

deviantintegral → created an issue.

> Overall page scale, especially on a 14-inch laptop screen

I agree, this is comically huge on a 27" screen! Here's a comparison to wordpress.org. We don't even get a "Get Drupal" type of button, and WordPress manages to get 3 key sections (the headline / video, the "how to wordpress" block, and "what's new").

With all this in mind, I do want to say how exciting it is to see this work! Certainly from a "look" perspective, this is vastly improved over the current drupal.org home page. I think the guts of the design system are solid, and it's just individual components that need work. High five!

500K websites using Drupal today - this needs a link or a reference. For example, https://trends.builtwith.com/cms/Drupal shows around 200k websites, so are 300k sites actually headless, intranets, and the like? That seems off to me.

Given this is a web site, there's a surprising lack of links! On a desktop-class monitor, there's ~3 viewports worth of page with only two links - Why Drupal and Learn More in the case study section. It would be great if the "Flexible by design" text should include links supporting each assertion.

The issue summary doesn't say "give content feedback", but there's lots of it here so here's mine!

The most accessible, secure open-source DXP available

Earlier in the page it says "fully composable CMS" - so what is it? I think it's important to choose one term and focus on it (which I would guess is CMS).

The "Start your Drupal journey" section has a huge amount of top and bottom margin, at least on desktop class screens.

I'm surprised by this. The field is listed in the config schema, and there's nothing special about it in the form definition.

Given how many module users aren't using group, and from what I can tell group is only used for an integration test, can we make it so that test only runs on Drupal 10, and is skipped on Drupal 11?

Drupal now has a machine name field for options items. However, it kind of makes the experience worse, because it means that generated option keys will always use underscores which can have readability issues in URLs. We likely want to change how this module works so it alters the machine name field to always use dashes.

The 1.0.0 release is marked as compatible with Drupal 11. Nice!

We just ran into a case where images failed to load when using the file_mdm module. Our theme needs to load the source image first to pull out some exif information, but the call to \Drupal\file_mdm\Plugin\FileMetadata\FileMetadataPluginBase::loadMetadataFromFile fails because it doesn't exist.

I have a horrible, horrible hack in place which works by swapping out the exif plugin implementation. But realistically, this would be better if Stage File Proxy swapped out the public stream wrapper so it could intercept file_exists() calls and download as needed.

<?php

/**
 * Implements file_metadata_plugin_info_alter().
 *
 * @param array $info
 *
 * @return void
 */
function MYSITE_stage_file_proxy_file_metadata_plugin_info_alter(array &$info) {
  if (isset($info['exif'])) {
    $info['exif']['class'] = "Drupal\MYSITE_stage_file_proxy\Plugin\FileMetadata\Exif";
  }
}

declare(strict_types=1);

namespace Drupal\MYSITE_stage_file_proxy\Plugin\FileMetadata;

use Drupal\Core\StreamWrapper\PublicStream;
use GuzzleHttp\ClientInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

class Exif extends \Drupal\file_mdm_exif\Plugin\FileMetadata\Exif {

  /**
   * @var \GuzzleHttp\ClientInterface
   */
  protected readonly ClientInterface $httpClient;

  public static function create(ContainerInterface $container,
    array $configuration,
    $plugin_id,
    $plugin_definition) {
    $instance = parent::create($container,
      $configuration,
      $plugin_id,
      $plugin_definition);

    $instance->httpClient = $container->get('http_client');
    return $instance;
  }

  public function loadMetadataFromFile(): bool {
    $localTempPath = $this->getLocalTempPath();
    if (!file_exists($localTempPath)) {
      if (strpos($localTempPath, 'public://') === 0) {
        $stream = new PublicStream();
        $stream->setUri($localTempPath);
        $url = $stream->getExternalUrl();
        // We use an http client because we don't have a good simple API for
        // triggering a download from a public stream.
        $this->httpClient->request('GET', $url);
      }
    }
    return parent::loadMetadataFromFile();
  }

}

I think there's a related bug as well for servers hosting multiple distinct Drupal sites, such as in multisite. In our case, we were running automated tests in parallel and file uploads were failing around 30% of the time for files with the same name. Adding a random string to each uploaded file like mktemp does would solve this, but we just moved to using the private files directory.

It does, thank you so much!

I don't think we've ever broken compatibility on the config.yml file. We've added optional keys over time, but never removed them.

However, I will say that the state of the whole ecosystem is such that it's pretty challenging to build a project that is years out of date. Most commonly, we see things like apt packages going away, or URLs changing, such that you have to do some edits to get an old project going. We'll even see this soon with Drupal, where if Tugboat (or any CI) was installing composer 1 it will no longer work without upgrading to Composer 2.

nicxvan → credited deviantintegral → .

Thank you!

I'm still not sure what exactly is being exposed though. At https://www.drupal.org/drupal-services → we see "2,640 issue credits weighted, last 12 months" for Lullabot. I don't see 2640 anywhere in https://www.drupal.org/api-d7/node.json?nid=1124040 → . I thought that would be "field_org_issue_credit_year": "687", but I'm unclear what 687 is referring to. Is the marketplace showing the field_weighted_org_issue_cred_yr field that is still hidden?

Is it a big deal to run the script on your dev site that updates the annual issue credit stats?

I went to compare against https://fjgarlin-drupal.dev.devdrupal.org/drupal-services but none of the stats are showing there. The stats at https://fjgarlin-drupal.dev.devdrupal.org/api-d7/node/1124040.json don't match what's on production right now either, so I can't confirm that this is exposing the right data.

If you say "trust me, this is right and it will take 3 days to regenerate credits on the dev site" then +1 from me, given that the fields do actually show up in the response.

Nice! Can you share the HTTP basic credentials, or if they can't be public feel free to DM them to me on the Drupal Slack?

FYI there's a new error introduced in 10.3.0:

In Container.php line 149:

  Circular reference detected for service "cache.bootstrap", path: "module_handler -> cache.bootstrap -> cache.backend.apcu -> Drupal\Component\Datetime\TimeInterface -> state".

This is because lightning_scheduler.datetime.time decoartes datetime.time and modifies the constructor arguments, which are not part of compatibility promises by core. It may be more reliable to instead inject that via setter injection.

We've done many, many Drupal sites since this was worked on, and obviously it hasn't come up since. I think this may have been a fixed in core since, or that at the time hook_post_update_NAME wasn't nearly as well known (even though it was in 8.0.0): https://www.drupal.org/node/2563673 →

Let's close this. Thanks for checking in!

This is great to see! I think your current blog posts could be good ways to highlight or announce new ADRs, since I don't see an RSS feed or similar coming out from GitLab.

If you do decide you want to generate a site - we're actually in the process of rebuilding ours in 11ty. We're hoping its done in the next month or so. It's already quite an improvement on build time and developer experience than Gatsby. So, please reach out if you could use that so you don't have to rebuild later unless you want to.

As far as editing ADRs go, we are a little more flexible than "cosmetic" changes. Let's say that a drush command changes names in our example docs. In that case, we wouldn't write a new one since the decision itself hasn't changed - just the implementation. But you have lots of room to try and learn given this is the first time this is being used in core-adjacent development.

This URL doesn't work anymore. Docker community edition no longer exists on the docker store site since they moved to only supporting Docker Desktop. This links to DDEV's docs on installing a docker provider which are kept up to date as the ecosystem changes.

Excellent, thanks for the update! I'll be sure to point members of our team here if they're looking for contribution opportunities.

Good sleuthing! This sounds like a bug to me.

One of our team members recently created a proof of concept to test out recipes as they exist today, and we pretty quickly ran into this. There's three scenarios I can think of where functionality like this would be useful:

1. As a developer today working on recipes, you might want to change and re-apply them on your local without having to do a reinstall.
2. As a future Drupal user, where you are iteratively adding different recipes to your site over time. With the current model, it seems like all it takes is one overlapping config object for a recipe to become un-importable. In many cases, I think updating existing config would be normal and expected, such as a new recipe wanting to change the default home page path.
3. As a Drupal expert, where you want to apply a recipe to an existing site you've inherited. At Lullabot, this would mean us creating recipes to match our ADRs so we could more quickly get a site up to what we consider standard.

As is, I don't see Recipes solving #3 for us - for it to be worth our time creating and maintaining, it's got to work for all of our projects, both greenfield and inherited. Otherwise, it's more effective for us to treat these things as documentation and not code, even if that means annoying point and click (and copy-paste) setup.

Given it's been a year and a half since the last substantial comment, it'd be great to know if this feature is still in scope with the current state of the initiative and where it currently ranks in comparison to other work.

I don't think this is relevant anymore given the changes in Drupal's management of upstream host headers in modern Drupal. Thanks!

Given Context is not widely used in modern Drupal, and that Drupal 7 is close to EOL, I'm going to close this issue. Thanks!

This was totally fixed some time in the Drupal 7 development cycle.

I don't think this is needed anymore in modern Drupal releases, and Drupal 7 is close to EOL, so I'm closing. Thanks!

Given that the indicator is integrated with the toolbar and the future navigation menu, I don't think there's anything to hide anymore.

Closing as we have Drupal 10 support in the 4.x branch.

Good call. Done!

I think https://www.drupal.org/project/navigation/issues/3397058#comment-15331899 📌 Convert navigation sections to blocks and use the menu system Active describes why we walked away from blocks - that the Navigation toolbar will never have a true render context in build() and will never be tied to a theme, whereas blocks are always placed within a theme.

I can still reproduce this in Drupal 10.2.5 with both 2.0.0-rc1 and the latest dev releases of both domain menu access and domain. The above testing steps still work to show the notice.

alexpott → credited deviantintegral → .

ckrina → credited deviantintegral → .

I love this idea! I would lean towards making it a default, as long as it worked cleanly with Claro and can be done in an accessible manner.

I think this is Major based on "Block contributed projects with no workaround.". From what we could see, the only way tot fix this was to patch core and roll back a fairly significant change.

Thanks for the offer! I’ve granted you all project permissions. Have fun!

Nice! I like that we can go back to a simple static variable, I hadn't thought about the fact that PHP won't reload files once loaded. This also saves Drush from having to coordinate a release around this change (not that it's core's responsibility, but it's nice to save downstream users work even for constructor changes).

https://github.com/drush-ops/drush/blob/1f9e78ad1aace1efa26bbaaa2e30c628...

Domain Menu Access issue is at https://www.drupal.org/project/domain_menu_access/issues/3418131 🐛 Do not create the domain access field when importing configuration Needs review .

deviantintegral → created an issue.

deviantintegral → created an issue.

Here's three different profiles testing against Umami. These all compare against a base of b1fbff58cca271a88373115ceb3a818bff1762d2 which is on the 11.x branch.

First: comparing against 5605d11412 from this merge request. This is the first pass with a cache just around getRemovedPostUpdates():

Overall pretty decent, a 2% reduction in time and ~182K less function calls.

Second: comparing against c30cc7f014 which moves the cache to scanExtensionsAndLoadUpdateFiles(). While there's still around 182K less function calls, it actually took ~455ms more CPU time.

I was curious and wondered if the additional calls to delete() needed when caching that whole function were related. So here's a third comparison against 5605d11412 with the additional call to clear caches as needed to pass tests when caching scanExtensionsAndLoadUpdateFiles().

As we can see, the additional delete() calls clearly have an effect.

With the above in mind, I think we should go with the first approach where we just cache getRemovedPostUpdates. While the second approach may be conceptually better, in all cases so far it seems to be slower than the first approach, both in a small install profile like Umami and in a much larger install profile.

Totally, I forgot to unassign it for the weekend anyways.

I made some minor changes to the CR formatting, as I believe we use human-readable sentences. Otherwise, the code changes look good!

I'm kind of amazed tests are passing. With that in mind, I've rebased against 11.x, though this patch applies cleanly to several prior Drupal versions as well.

I haven't added new tests, because this feels like exactly the sort of thing that should be transparent to calling code.

deviantintegral → created an issue.

@hungdo, do you have a use case that can't be solved via a settings override? See https://www.drupal.org/project/twig_temp/issues/3185798 → .

Thanks Prashant! I see two next steps depending on your comfort and interest.

1. Create an issue that does nothing other than create the Content menu, and pull the related code out into that. Don't even worry about displaying the menu; let's just get a menu for Content in that we can reference in future work.
2. Change the current plugin implementation back to having a totally separate plugin manager from Blocks. Our plugin type should still require that they implement or extend \Drupal\Core\Block\BlockPluginInterface. But, the discovery, namespace, and directory should be separated out again.

I've had some things come up that will limit my availability for this, so I'm really glad to see you here offering to help. Thanks!

To followup and summarize on next steps for this:

There's some skepticism that it will be possible to have a single block implementation that can ever work in both a navigation and non-navigation context.
The block system has intentionally been designed to not include any sort of real rendering context in the `build()` method.
There's also some worry that if there are separate blocks implemented to handle these cases, that the regular block admin could have duplicate blocks.
While Blocks have a context system (\Drupal\layout_builder\Plugin\Block\ExtraFieldBlock does this to associate an entity object), in practice they are best used for data and not theme or rendering information.

A good next step would be to walk this back to having a separate plugin implementation, _but_ still have Navigation blocks implement or extend \Drupal\Core\Block\BlockPluginInterface. That interface already defines most of what we need for navigation blocks, and would provide a familiar pattern for contrib modules to implement navigation support, or to more easily extend and share code for existing blocks if it does make sense.

Thanks everyone for the initial work on this. The MR is committed, tests are passing, and I tagged a 2.0.0 release to get us into semver.

https://www.drupal.org/project/system_stream_wrapper/releases/2.0.0 →

I've updated from my review notes earlier. I also fixed up tests and got them running on GitLab: https://git.drupalcode.org/project/system_stream_wrapper/-/pipelines/51933. I've left the old test bot in place for now.

My plan is to merge this Monday, and switch over to a semantic module version release at the same time, tag a 1.0, and opt in to security coverage.

It may be good at the structure of writing, but hallucinations are a challenge still.

There's been some articles over the past 6 months that have felt like AI-generated content in that they were filled with generalizations and so on. But, I'm not confident enough to link to them. I think a policy would get ahead of things so that if content starts publishing problematic content there is a guideline to refer authors and publishers too.

I think it would be great if the policy would apply to content in the drupal.org planet feed too. As written, the policies wouldn't prevent sites from using generated content if they so choose, but requires a baseline of human review, quality, and attribution that would increase the overall quality of content on the feed.

Hey folks, thanks for the efforts on this! I gave it a review. I'd like to sync with Dave Reid too, but he's unavailable right now. Regardless, let's aim to get this committed by the end of the week.

I left a few review notes on the MR. Nothing major, this is pretty close to done.

A total aside:

basically copying the patch in the MR to a patch file and upload it. This will help to keep the repos safe until the patch is committed.

Actually, _technically_ patch files are vulnerable to code swaps too. A regular user can't do it, but there's no authenticity or integrity checks beyond what HTTPS provides in transport. At Lullabot, we've standardized on always committing a copy of a patch to the repository and never referencing them with `https://...`: https://architecture.lullabot.com/adr/20220429-composer-patch-files/

deviantintegral → created an issue.

I've redone how the plugins are handled and I'm much happier with the approach. IMO it's simpler and more robust.

Instead of a separate annotation, we now look for navigation on the normal Block annotation. I've defined it as an array, so we can add keys like default_region, weight, and so on. To do this, we add our own plugin manager that wraps the block manager (it's not really decoration because we don't swap the service). It handles filtering available plugins and validating the additional keys.

Then, I implemented the announcements feed as a demo block. An interesting side effect is that the Announcements menu item works as is, showing the dialog of announcements on the left hand side.

For next steps, it would be great for someone else to look at what I've done with the navigation block manager and share any compatibility concerns or similar I may have missed.

Latest reroll looks good to me.

deviantintegral → created an issue.

Yesterday, we had a call reviewing this with @ckrina, @laurii, @ted.bowman, @tim.plunkett, and myself, along with some followup chats.

This is from my own notes on the call, feel free to comment if I misrepresent anything!

In terms of functionality, site builders:

• Should be able to customize the links in menus, just like they can today.
• Should be able to add brand-new menus that they create from scratch, or menus from other modules.
• Should be able to reorder menu blocks themselves.
• Should be able to add non-menu blocks to the green content area in this screenshot, as long as those blocks have been explicitly tagged somehow as being navigation menu compatible. For example, we could easily imagine site builders wanting to somehow put a list of recently edited content int the menu. While we wouldn't want to expose all Views blocks by default, once we have a way to mark those blocks as good in the nav menu we want site builders, and not developers to be able to manage them.

Developers:

• Should be able to customize the top region and the bottom region, for modules like Workspaces or Environment Indicator.

From a technical perspective, this is actually the first time plugin implementations have been subclassed in core. @tim.plunkett pointed out that there's real dragons as far as backwards compatibility goes, especially with constructors. There are instances of contrib modules doing this (like superfish), but in practice we may make things simpler and just ditch the whole aspect of subclassing. As well, it may be easier to alter in additional block annotation properties than to try and do an entirely separate annotation type.

For next steps, I would like to:

• Implement an example integration for a core module like Announcements or Workspaces.
• Use that to learn what makes sense as far as the existing "as block plugins" approach goes.

I think the nightwatch failures are unrelated to these changes. In the Nightwatch job at Tests/Olivero/oliveroColorTest.js:

unhandledRejection: stale element reference: element is not attached to    ││   the page document 

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

deviantintegral → created an issue.

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

@justafish said to me "isn't drupal.org already pointing users to ddev?".

https://www.drupal.org/download → points people to use the Drupal quick-start script
https://www.drupal.org/docs/getting-started/installing-drupal/drupal-qui... → also makes no mention of anything other than the quick-start script and starts with "install PHP" (on your host)
https://www.drupal.org/docs/develop/using-composer/starting-a-site-using... → doesn't mention ddev either

I couldn't find a page with drupal.org search, but going externally I found https://www.drupal.org/docs/official_docs/local-development-guide → . That does use ddev, but as you can tell from the breadcrumb even though this is a "curated guide" I doubt it's linked to or referenced from anywhere. That page is a great start, but probably needs to replace one or many of the previous pages we use if we adopt this proposal.

marcoscano → credited deviantintegral → .

MR opened.

Yeah, agreed on MRs, I think with the recent hosting changes my prior issues should be solved. I'll file one without the update hook.

I'm curious what your content types are. We've found through user testing that having categories is a significant improvement for editors in understanding how content types relate to one another, even in small sites. Here's an example to illustrate:

As a response to https://www.drupal.org/project/ideas/issues/2965681: →

It’s been two years since the last substantial update! Here's some key points on the state of ecosystem in late 2023.

• Running Docker on Windows and macOS has changed significantly. Windows users can use WSL2 easily, either with Docker Desktop or just by installing Docker CE directly in a WSL2 instance. macOS users can use Docker Desktop, colima, OrbStack, and probably others I've forgotten.
• ddev + mutagen has basically solved the slow IO problems for non-Linux users: https://ddev.readthedocs.io/en/latest/users/install/performance/
• GitPod continues to exist and there's a reasonably well used setup combining it with ddev: https://github.com/shaal/ddev-gitpod
• There's been a major kerfluffle with Docker Desktop licensing. They've replaced previously open source tools with a completely closed-source stack. As well, their licensing requirements are now based on revenue, which many potential users don't have access to at their organizations. As well, performance with Docker Desktop continues to be hit or miss, unless you layer in Mutagen on top.
• Docker Inc. bought Mutagen, but at least Mutagen itself is fully open source and it remains to be seen what Docker's plans are for it: https://www.docker.com/blog/mutagen-acquisition/
• None of the traditional, large-scale Drupal hosts like Acquia, Pantheon, or Platform have moved to a "push us a container and we'll run it" hosting architecture. There's still a need for a significant number of Drupal developers to build a dev environment for locals.
• https://hub.docker.com/_/drupal is maintained by "the docker community" and doesn't really fit typical local dev or production deployment models, since nearly all sites would have their own repository in git - shipping Drupal in the image itself just bloats the image and adds complexity for users.
• DRUD, the company initially behind ddev, has gone out of business and DDEV has transitioned to a fully community led project, backed by a non-profit: https://ddev.com/foundation/

I propose that Drupal adopts DDEV as its official local development environment. The specific stack we would recommend would consist of:

• Docker CE on Linux
• colima on macOS
• Docker CE on WSL2.

However, we’d really just be pointing users to ddev’s getting started docs. We should mention that Docker Desktop is an option, but that it is not open source and warn users about the licensing model.

The DDEV implementation Drupal would consist of two variants. The most commonly used one would be for people creating Drupal sites or evaluating Drupal. The second would be for Drupal core development, using a git checkout of core instead of composer create-project.

One of the big challenges for regular Drupal use is the chicken and egg problem with needing to run composer create-project to have a project to boot up. Ideally users shouldn't need to have PHP on their host. Often, if they do, it's old or broken in some weird way, especially if they've been using Docker for day to day work. Instead of trying to solve this, we would instead treat this use case as "getting started" documentation issue. New users would be directed to install ddev and copy and paste a command along the lines of ddev config --project-type=drupal10... && ddev start && ddev composer install.

Drupal core would ship with a .ddev directory specifically for core development. The goal would be that a user could run git clone... && ddev start && ddev composer install, run the installer, and have a fully functional site with Drupal and MariaDB.

Drupal core would maintain this .ddev directory, doing things like updating the PHP version as needed. ddev has very easy ways for developers to add local-only customizations, such as if they need to test Drupal with a different PHP version or database.

Why ddev, and not something else?

• DDEV easily supports multiple running sites at the same time, complete with HTTPS. Developers can easily run multiple versions of Drupal at the same time, without dealing with port or other conflicts.
• ddev's community governance model matches with Drupal's. There's an active advisory group, and multiple Drupal agencies actively support ddev.
• ddev has support outside of Drupal, with other CMSs like Silverstripe and Craft adopting ddev as their default local: https://ddev.com/blog/expanding-ddev-maintainer-team/
• At Lullabot, we have standardized on ddev for all of our projects with great success: https://architecture.lullabot.com/adr/20211207-ddev-locals/
• Since hosting isn't often using deployed Docker containers, most Drupal developers don't have deep experience maintaining docker compose files by hand. DDEV gives you the option to extend with docker compose files, but it’s in no way required for typical use cases.
• Drupal's built in quick start historically has major bugs and hangs often rooted in PHP itself. For example: https://www.drupal.org/project/drupal/issues/3271178 🐛 quick-start installation stops responding Active
• Drupal adopting ddev as a default environment in no way prevents teams from deciding to use lando, docker-compose, or something entirely different. Drupal implementations wouldn't have a .ddev directory in the way if they didn't use it. Drupal core developers not using ddev could completely ignore it.

Standardizing with a docker-based solution also opens us up to supporting local environments more easily for complex scenarios. For example, it would allow us to ship (perhaps optional due to size) browsers for running functional tests in PHPUnit or Nightwatch. As an example of a potential future goal, at Lullabot we’re running Playwright functional tests in ddev complete with a browser-based VNC desktop environment for functional tests.

Looking at the current maintainers, it’s not clear to me who or what topic area this would fall under. I will see if I can get next steps on this so we can address "Determine which stakeholders need to sign-off on this issue to give if official status" in the next day or two.