Document using DDEV as the recommended Drupal local development environment

It would be nice to have something simple but robust enough for common development purposes, meaning it has XDebug available if needed, it is easy to get up and running quickly on Mac, Windows, and Linux, it requires a minimum of dependencies (e.g. just Docker CE), and it can run with 2GB of RAM or less (many devs at DrupalCon seem to have 4GB of system RAM available; we can’t count on having 8+GB).

In the Laravel and Symfony communities, Homestead is the official environment (Vagrant and VirtualBox-based). In many other communities there’s a simple docker-compose.yml file included with the project or quickly downloadable, which brings up a minimum set of containers for development (or in some cases even running it in a simple production environment!).

If you use Composer to manage your Drupal codebase, having a development environment that’s one composer require away (like this) is awesome, and doesn’t require anything to be added to core itself. I’m not saying we go this way, since it’s not likely we’ll require everyone to use Composer to manage their codebase anytime soon, but it is a pretty compelling way to do local development IMO!

To write it out, we've got basically four use cases/personas:

1. I found out about this Drupal thing I want to just look at it real quick and evaluate. => Demo/hosted/simplytest.me.
2. I'm more technical and I want to get something working locally so I can see a webpage fast but be able to poke at the files. => The single command installer that is getting installed in core.
3. I want to do more than evaluate now, and do more than just kick the tires, but still need to get up and running quick. Maybe I'm new to this. Maybe I'm at a sprint. => ?
4. I have complex requirements, build Drupal, WordPress, NodeJS, etc and want something I'm going to stick with professionally and do lots of stuff with. => DDEV, Docksal, Lando, etc.

I think we're aiming here to solve the third one.

I agree with Jeff about performance. We need to be mindful of that. We should also be careful about download size so downloading is faster and easier and gets someone to a functioning site faster.

+1 to the breakdown by @davidhernandez in https://www.drupal.org/project/ideas/issues/2965681#comment-12586229. The "sprinter" use case is one where some additional packaging around a tool (dependencies, default containers, some scripts to glue it together) can be valuable. This was the basis for the "quick sprint" repo, which attempts to do this across all 3 OSes. https://github.com/drud/quicksprint. I originally came out of the meeting thinking we were trying to address use case #4 (...I'm going to stick with professionally and do lots of stuff with...), but I can see option #3 as a good stopping point. FWIW, and this was brought up in the Lando Slack channel, it's conceivable that the repo used in quick sprint can be tailored to package various Docker based tools (e.g. Lando, DDEV, and Docksal) so as to avoid the "one tool to rule them all". However, if we're pushing into territory #4, I think that would start to get unwieldy.

I agree that the scope of the idea should be #3 listed above.

#4 is probably where everyone will eventually end up so anything that explains how to get from #3 -> #4 would be helpful, which probably means providing explanations (as a learning process) of what is going on in #3 so that an user can evaluate if they need to use #3 or #4.

Sprints have a slightly more complex approach because a "core sprint" is unique in checking out Drupal directly from git rather than the composer/composer project work flow that is mostly (?) recommended for creating sites so how can we reconcile the differences in development environments when contributing back to Drupal versus site-building and site development?

I'm really sad that I missed the BoF :(

Does https://hub.docker.com/_/drupal/ already serve this purpose somewhat? Could it be made official on the d.o side? (it's the first thing that comes up when you search in Docker Hub for Drupal and also labels it as "Official" since it's in the docker-library namespace). Using Docker directly instead of something abstracted on top of it is a much more transferable skill.

@justafish Yes, I can see this potentially in the direction of adopting that or some other official docker container, but the problem we need to solve is the infrastructure that supports that. To run it you are already at the point where you have docker setup and supported. These existing tools put a lot of work into things like port management, file access, etc. We'll need to figure out the architecture we want to build/support that can make this mostly transparent to the user.

There has been a significant amount of work in some of the local development tools by fairly decent engineering teams. I understand that there may be a strong desire to build from scratch. However, it may be worth considering some of the exposure and experiences of these other tools before jumping into building a replacement. I do believe you'll find the existing projects are willing to support this initiative to solve the problem.

Thanks for putting this together. Looking forward to next steps.

@cyberswat That is correct. And thankfully representatives from all the tools mentioned in the summary attended the BoF at DrupalCon and I'm sure will be involved in the initiative.

@daveidhernandez Docker's Kitematic UI already handles ports and volumes (as well as a tonne of other stuff), and works on Mac and Windows. Here's a video of how easy it is to find and run the "official" Drupal image, and change the port:
https://www.dropbox.com/s/9u6476ni41mxt6x/Kitematic-Drupal.mov?dl=0 (45.2mb)

It would be far more valuable to our users if we have them use a tool that is now ubiquitous across hosting platforms instead of rolling, and maintaining, our own custom ecosystem.

Also to note that both Docker and Kitematic come as proper installers for those platforms, so you don't need to fiddle around with brew or anything.

I’d also like to vote for using a broader standard tool, like Kitematic, or just plain Docker and Docker compose with no port so they can pick one that’s free. I am leery of recommending any beginner or new-to-drupal developer to start out with a tool that first requires installing a custom/bespoke CLI management tool like ddev, lando, fin, etc.

I also would love if we could use the official Docker Hub image for this... so many other software platforms and apps seem to use that resource as their ‘go here to get started’ tool at least as far as Docker goes. Who owns that image?

I agree with geerlingguy about a broader standard tool like Docker for Mac or Docker for Windows (suggested to use Kitematic). A broader tool also opens up Windows 7/8 users who need to use Docker Toolbox.

Kitematic isn't bundled with Docker for Mac/Docker for Windows. It is only bundled with the Docker Toolbox, and the documentation around Kitematic suggests it is a legacy tool, but it is still listed in the Finder menu of Docker for Mac and suggests its compatible.

Kitematic looks very cool. I've never used that before.

The image belongs to docker-library where the "official" images are located. I don't know what governance/access exists around that.

To highlight the (potential future) level of effort / timeline that these efforts can take, here's an article written by Tandem.io (maintainers of Kalabox/Lando) https://thinktandem.io/blog/2017/10/24/journey-to-lando-mistakes-pivots-.... It's refreshingly honest on the challenges/complexity that it takes to package these tools in a way that meets a variety of use cases, remains stable enough for users to depend on them, keep up with changes in technology, etc. The maintainers of DDEV, Docksal, and Drupal VM could probably write similar stories (although they may vary in duration/intensity of effort).

Scoping this will be very important and a desire to start from scratch shouldn't be taken lightly. What may not have been stated in this article is that support is a big big deal and can consume a lot of time.

I think @justafish's suggestion is right on. Good to see @geerlingguy and @mradcliffe on board with her idea.

Kitematic might be an example that's worth referencing. It's something that we evaluated in product roadmaps and have been watching for multiple years. We've put in a decent amount of time considering it as a full alternative to building a GUI because we've literally been working on docker based tooling for years. It's a really slick tool. It works really well on Mac. It only recently started working on windows. It doesn't work on Linux unless you run it inside of containers with more complexity. It doesn't solve the cross-platform UI needs of the people trying to work on websites in the way that I believe we are attempting to do for this community.

We've also spent a lot of time looking at how to package containers and what a monolithic container approach could be. There is so much information that could be shared from the projects that have been working in this space.

I do love the idea of a first class installer where it makes sense to have one. Those are easy to create and integrate into automated builds. We do that now with windows. We've also had more requests for native packages in different linux distros.

@justafish makes a really good case for avoiding a lot of work that reinvents the wheel.

The article on Lando (https://thinktandem.io/blog/2017/10/24/journey-to-lando-mistakes-pivots-...) makes a similar point: "Irrespective of the technology that powers such a solution, telling people you are going to build what amounts to a push-button PaaSS (yes, I mean a Platform as a Service Service) and application migration utility that they can run on their own computer, regardles of operating system and that will JUST WORK is QUITE the promise. In fact, it's such an obviously impossible promise I feel a considerable amount of shame in reading what I just wrote."

I've used Lando and ddev, and they're great tools for ongoing development. I have no doubt some of the other tools like Docksal are equally compelling. All of those seem focused a lot more on #4 than #3.

Leveraging existing resources makes a lot of sense. Not taking on the burden of making things work across multiple OS systems, versions and customizations makes a lot of sense. Maybe there are some points that could use some additional thought on how to mitigate potential issues, but the approach of not creating a new island makes a ton of sense.

tl;dr listening to @justafish is a good call.

I'd like to update everyone on what I'm doing with the Provision project. Provision 3.x and earlier is just a set of Drush commands for the Aegir project. Provision includes Apache and NGINX templates, code to connect to database servers, and do all the rest that is needed to automatically get a Drupal site running on a traditional LAMP stack.

As anyone who has ever tried to use these commands, they know the user experience is rather lacking. This is almost by design: They have to be machine operable so the front-end drupal site can trigger the commands.

For Provision 4.x, I am separating the project from the Aegir organization, it now lives at https://github.com/provision4/provision. The Provision4 CLI is a symfony console tool that replaces the provision3 drush commands and stands on it's own as a user interface for configuring and launching sites.

Provision and drush actually have very closely tied histories, so it has been really fun to follow Drush into the modern symfony composer console world.

I'm trying to make it as user friendly as possible but that is not the primary goal.

The primary goal is service agnosticism. It is being designed to work with anything that Drupal can use to run.

I cannot assume to know what the "best" development or production environment is now or will be in the future, but we will know that Drupal will always require some kind of PHP server and some kind of database server.

So I'm designing provision4 to be able to work with service that Drupal can work with.

Please note that everything mentioned here works now except for things labelled (not implemented).

Use Cases

Drupal Previewer

• Built in PHP Server & SQLite.
• Provision is included in drupal-composer as a packagist library. Drupal composer project includes reference to it's commands in composer commands array, so installation of a second app (provisionCLI) is not needed.
• Launched with composer run-server or similar. (not implemented yet. There is some code in provision for using run-server).
• Provision library writes settings.php, checks that sqlite is installed, checks for a port and launches the server. User only has to run install profile, not configure database settings.

Native Development

• Native Apache/PHP/SQLite or MySQL. Native meaning either core macOS apache, brew apache, MAMP... If provision can write a new vhost to a folder, it can leverage any web server.
• Native will always be faster unless on linux! If MacOS Apache was easy to configure, maybe we would use it? Works now!
• Launched with composer run-server (not implemented) or global provision CLI pro @sitename verify

Container Development

• Same Apache or NGINX templates from Native mode, with Docker containers wrapped around them, prepared with Docker Compose. Works now. See https://docs.provision4.org/customizing-provision for the myriad ways to customize.
• Works natively with docker-compose, Docker for Mac, docker-machine, etc.

Production Hosting

• Native Apache/NGINX/MySQL
• Docker compose Apache/NGINX/MySQL
• Kubernetes (not yet implemented)

Just something to consider. It's all just PHP classes that know how to setup different kinds of web servers.

I've believed for a long time that one tool could be created to handle all of these use cases, with Provision4 I'm finally close to achieving that goal.

Would love your feedback.

Thanks!
Jon

It is important for this issue to have a list of all the available Local Development solutions that already exist for Drupal as also as to define the characteristics we want to evaluate for each solution. Without a matrix we cannot make a decision.

https://drupaltools.github.io/ is a collection of such "Drupal related" tools and I think it would be useful to mention it here.

Gitpod kinda change things too

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
• 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.

@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.

I second DDEV support whole-heartedly, and this is after maintaining our own internal Docker Compose stack for years. I heard of DDEV but didn't take a good look until this year, we easily shifted over with little downtime. We had everyone on Windows, Mac or Linux up and going, even WSL2 - for non technical people. Design, UX, or BSAs... they could preview Drupal/modules/themes and or run real client projects locally for review. It is completely viable, well maintained, and easily extendable. Most of all, open source.

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.

DDEV negates that need - the ultimate goal would be all tools in the environment and not on the host. It is high time we rally and improve this user experience.

❤️ ddev!

Note that it would be relatively easy to create a ddev-addon for Drupal core development, to perform tasks like running the CS checker, run-tests.sh, and setting up an environment for stuff like javascript functional tests.

So the project here might be to spec out an add-on.

Another issue is that we don't want to 'pollute' the core composer.json, so we'd need the path repo or similar approach to including core in the dev environment. I believe https://github.com/joachim-n/drupal-core-development-project does this. I think there might be other projects as well, which do this.

Landing on some type of "official" tooling would be great. I know that ddev has been used for mentor onboarding for some time. So there is already some precedence here.

From DDEV maintainer: I note that TYPO3 adopted DDEV as official local dev years ago, and Craft CMS and Ibexa more recently. In all cases it has made so many things so much clearer for those organizations, and their docs just show you what to do, not assuming vast amounts of alternative knowledge.

Both TYPO3 and Craft have DDEV instructions embedded right into all their docs, so the path is clear and unambigous. They don't dodge the fact that there's more than one way to do it, but it doesn't require guesswork. They just tell you "here's how you do it with DDEV". Being unambiguous about a way to do things is not a sin. And as you see in these cases, DDEV is not offered as an exclusive choice, just as an easy and straightforward one.

TYPO3 installation instructions:

Craft CMS Installation instructions:

Craft CMS plugin installation:

The DDEV community has always considered Drupal a special friend and would love to support it more "officially", and it would make usage by newcomers ever-so-much easier.

+1

DDEV is a great fit.

- https://github.com/ddev/ddev-drupal-contrib: DDEV integration for developing Drupal contrib projects.
- https://github.com/shaal/DrupalPod: Great workflow for testing and developing patches / MRs.
- 73 addons including 20 official addons (varnish, solr, redis, selenium-standalone-chrome, elasticsearch ...)
- Gitpod and Codespaces support.

It also supports Drupal 7, 8, 9, 10 (even Drupal6); we would not be locking out Developers supporting unsupported versions of Drupal (they'll update Drupal soon right?).

I've worked with several folks during the past year to get them set up with Drupal, and the experience has been everything except smooth. Even folks with years of experience from development struggled with this.

Most folks seemed to try to find this info from Installing Drupal-page, which is the first link in the "Resources" dropdown. However, as #24 points out, the actual page we probably want to get people on is Local development guide. I tried to find this info under the "Installing Drupal"-page, but could not find it from there. Also, it looks like https://www.drupal.org/download links to a different set of instructions. Making these consistent could be a good start.

Once I've been able to point folks with the right documentation, I've had to provide them with additional guidance for installing plugins to make the environment fully functional. There's been some pain points here that we can hopefully smooth out. For example, I tried to help an upstream maintainer set up Drupal so that they could run all different types of Drupal tests, and we failed to get some of the test suites run even after several attempts. 😬

To my surprise, I just noticed that Local development guide is also in the menu. From this perspective, it seems that the decision to use ddev as the official local development environment has already been made to some extent. It would be great to get confirmation from Drupal core framework managers on this, since they are responsible for the developer experience.

I personally think committing to one development setup, and promoting it as the recommended way is an excellent idea to try to solve this problem. I believe this would allow us to provide an easy way for developers and site builders to set up Drupal not only to run Drupal, but in way that let's them have proper tooling for Drupal core / Drupal module development.

Personal opinion:

It takes me years to adopt any new tooling, I still use vim and not any kind of IDE etc. A couple of years ago I started using ddev and it has made everything significantly easier, not just setting up new installs, but tweaking things like PHP version, and also deleting installs when I want to get rid of them. I have not tried any of the other tools because I did not feel the need to.

Framework manager opinion:

If I understand the scope of this issue correctly, then we would not make any core changes here (except perhaps changes to the quickstart install one-liner), but this is more about having opinionated documentation on Drupal.org that recommends, clearly, with a short number of steps, ddev.

I guess one more question is would we include a reference to ddev in core's README.

We could still have a page with descriptions and links to howtos for alternatives like lando and this wouldn't affect projects that are already using them at all. That makes it a decision analogous to how much we recommend MySQL vs. MariaDB vs. postgresql etc. - it doesn't preclude changing our minds at a later date, and it doesn't stop new development environments emerging, it just promotes one as the default so that people who don't have a preference don't have to research five competing solutions first.

If that's the correct scope, then a very firm +1 but I think the wider question is how do we edit/delete all those bits of documentation, this previously hasn't been under the control of the core committer team.

To my surprise, I just noticed that Local development guide is also in the menu. From this perspective, it seems that the decision to use ddev as the official local development environment has already been made to some extent. It would be great to get confirmation from Drupal core framework managers on this, since they are responsible for the developer experience.

True, but the "Evaluator Guide" above it should then also follow the same guide - its method is more difficult (for the non technical audience) and should align with the Local Development Guide for consistency.

https://www.drupal.org/docs/official_docs/evaluator-guide

+1 for making DDEV the official local development tool for Drupal. It works really well, with extremely great support.

Making things easier is good and much needed. And DDEV is great. So I'd fully support it.

I don't use ddev or lando, so don't have any bias here. But +1 to the scope from @catch in #31

I don't currently use ddev or lando but have used them both in the past. I think one huge drawcard for ddev is the unparalleled support from @rfay and the ddev community.

Big +1 from me.

During usability group meetings we are regularly spinning up sites to test things, quite often that’s using DDev, it easily allows one person on the call to spin up a site, and make that site available to for everyone on the call to access. So having a “core supported” .ddev directory that just works out of the box, and uses the latest core supported versions of PHP, etc would be a nice bonus!

Development environment was a huge pain point for me when getting started with Drupal. It still creates a significant barrier to contribution for me.

I use Lando happily enough, but would switch to ddev if that became the standard.

Another +1 for DDEV. I've used Lando in the past, although not recently, and it's a capable and solid system but ddev is incredibly simple to get going and support from @rfay is second to none as well as the #ddev on drupal slack being a little more noticeably active than Lando.

Re-titling since there's so far broad consensus on ddev.

The issue summary needs to be updated here. I think we should list the various documentation places mentioned above where things would need to be updated (or possible consolidated with redirects), as well as any changes to the Drupal core project page or README that might need to be made.

Thanks @catch, and let's also use the official brand name, which is DDEV:

Use Correct Proper Nouns

DDEV != ddev

DDEV is a product and ddev is a binary or console command. DDEV should always be uppercase, and ddev should always be in backticks. DDEV-Local and DDEV-Live are former product incarnations that shouldn’t be found in modern documentation.

Write This 👍	Not This ❌
DDEV is wonderful!	Ddev is wonderful! ddev is wonderful! DDEV-Local is wonderful!
Run ddev.	Run ddev. Run DDEV.

From Writing Style Guide > Use Correct Proper Nouns.

Use of the Word Mark DDEV

The product DDEV is always referenced in capital letters.

When referring to the binary ddev, lowercase letters are preferred.

From Brand Guide > Use of the Word Mark DDEV.

Another +1 for DDEV. I've used Lando in the past it is good but it used to have a frequent crash when handling a bigger project with large database on a low configuration system, but I havent faced such issues with DDEV so far.

And top of that the main selling point is DDEVs community and especially @rfay's support to the users.

We already have DDEV integrated to Gitlab in the form of DrupalPod, so it makes even more easier to get familiarise with DDEV for new contributors.

+1 for DDEV, but I'd strongly hope that I'd be able to run core's quick-start command without any docker requirements also on future.

Big +1 from me, but I'd also like to note that while @rfay's dedication to DDEV is amazing, he is actively working to increase the number of core contributors, funding sources, and governance structure to DDEV.

If we decide to adopt DDEV as the official local development environment, I would hope that we also make a commitment to the project as contributors as well.

I've been using DDEV for teaching and consulting for more than a few years now and donate financially to the foundation every month (in addition to some minor documentation and support contributions).

I would be in favor of DDEV! This is a weak argument, but please don't make me change all my quick keys!

Absolutely! DDEV has always been great and ACTIVELY supported. It is very fast (especially with Colima).

-1 ddev. Creates a heap of trash dot files. Plugins are scattered around the internet. Relies on non standard file systems. Complex compared to alternatives.

Regionally Lando is more popular to aus/nz/india. So I have bias here.

Lando has less friction looking outside of php and Drupal, making it nicer to work with in “Agency Land”, and the v4 dockerfile layering is not to be overlooked.

+1 for DDEV. Its user-friendliness, simplicity, and stability enhance the experience for beginners in Drupal development.

+1 for DDEV! I've used DDEV, Lando, Docksal, Acquia Dev Desktop (now discontinued), and Docker4Drupal. DDEV is by far the easiest to set up and maintain.

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).

DDEV is great, but the idea of a single sanctioned "official" environment is dangerous. There are lots of reasons developers and teams prefer different environments, as voiced above. Plus the landscape is constantly changing. I'd be in favor of recommending a certain environment in any Quick Start guides and demos, but leave it open so that developers don't feel like they are doing a bad thing if they choose something else. DDEV as a default environment, but not the official environment.

Although DDEV definitely has some nice features and is easy to use, I have to say it certainly has some shortcomings. I have been using Lando for several years and although it is missing some features that are available in DDEV, I find it more flexible in many regards. I consider this more valuable than baked in features because of the potential for future growth. While it would be nice to have one solution to rule them all, I think "competition" between projects is healthy and can foster improvement in each project overall. That said, I'm not really in favor of making any project "official" because that just elevates one above all others.

I agree with both @wells and @heatherwoz.

Any "official" solution here should be one that is actually/actively maintained by the core drupal team itself again a la Laravel Homestead. While I have a ton of faith in the work, mission, vibe and robust durability of @rfay dev tools, tech ecosystems, come and go, change, etc. There is not a sufficiently strong feedback loop and incentive alignment between ANY third party tool and Drupal itself to ensure with a reasonable probability that said tool is going to work well into the future.

I say this as a maintainer of a dev tool that 10,000+ drupal developers use every month and would feel the same way about a proposal suggesting that it become the official tool. To me this is not about the various merits of DDEV (of which there are many) vs some other thing but that a mission critical part of Drupal should not be handed over to any third party tool.

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

The only thing being proposed here, at least initially, is that all Drupal.org docs (and maybe README.md) should suggest using DDEV consistently as the default option for new development environments, so that someone who just wants to get started can do so without having to weight up 3-5 different options first.

For a random example, this is one of the first results for 'drupal local development environment' on duckduckgo and it recommends XAMPP https://www.drupal.org/docs/develop/local-server-setup/windows-developme...

Another high ranking page is https://www.drupal.org/docs/develop/local-server-setup/linux-development... which assumes you're going to run PHP and apache natively and references an unsupported Ubuntu version (and unsupported PHP version).

I'm in agreement with @pirog #53 - the solution should be something that's maintained by core Drupal team. I would rather see core contribs work to maintain easily accessible and excellent documentation and build recipes for the most common / popular local dev tools (listed over and over in this thread... docker compose, ddev, lando, docksal, etc) than have Drupal have one dev environment framework be anointed as The One. Getting people spun up quickly is critical but the reality is that after that initial experience, even new Drupal devs are going to encounter projects where they will be asked to use different tooling for different organizational reasons.

Though while I was typing this the idea of a "default" as opposed to 'official' was presented which I support just because it would make startup docs really consistent.

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.

@wells I don't use an IDE at all, I just use vim with a minimal plugin configuration, and Drupal runs fine. It doesn't however run fine without PHP and a database, so I don't think these are equivalents.

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.

I'm a long-term Lando fan and I've been using ddev for a couple of months (and also dabbled in a few others in the meantime). While i still prefer some of lando's polish, I think ddev is the correct choice as an official tool because it has good DX/UX for both ends of the user spectrum. As a technical user I feel closer to the docker-compose layer, while it still "just works" when I'm not feeling technical. I've been playing with light hacking of the docker-compose configuration, which really is a must if you need to incorporate some arbitrary images in a your setup - you can just use a native docker-compose file that is included pretty seamlessly. A great fit for code sprints and so on.

In case it's useful to anyone, this is a conversational look at ddev, where I ignored the ddev wizard and hand-wrote a config file. https://www.youtube.com/watch?v=aqEhYOWaxZc

@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.

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.

Our sqlite support is used on gitlab, so Drupal core's entire development pipeline depends on sqlite (although not to run Drupal, it just writes test results to sqlite).

We know anecdotally that some sites use PostgreSQL in production because bug reports and etc. get posted for it from real sites. I don't think anyone runs sqlite on production unless they're using a static site generator like Gin where it's not really on production, or at least I've not really seen that.

If Drupal picks a default it seems much more likely the others will be harmed for it.

I don't have anything against Lando, just haven't used it. However I do actively want to discourage people from using XAMPP, and we have a lot of documentation on how to use XAMPP: https://www.drupal.org/docs/develop/local-server-setup/windows-developme...

"default" is definitely a better word than "official" but i think my point in #53 remains the same.

When we started Lando the overwhelming majority of our users were Drupal developers. Now they are one of many different groups and Lando has become a more generic development solution. We did not really anticipate that happening, or happening as quickly as it did but it did happen and these things do happen naturally, organically and by no ones fault in tech all the time. Things drift apart.

We come from Drupal, started Drupal companies, organized and sponsored Drupal events, love Drupal and have a vested personal interest in Drupal's success but even with that background Lando is not solely a Drupal development tool and as long as that is true it, or any other generic dev tool, is just not a good choice as an "official" or "default" solution because fundamentally these things are not trying to solve THIS PROBLEM but a different, sometimes aligned, sometimes adjacent, sometimes completely not related set of OTHER PROBLEMS.

The best way to solve THIS PROBLEM especially for the long haul is for Drupal to take ownership of it and solve it itself because its sort of the only thing that can do so well.

[...] 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?

Drupal core isn't going to maintain an alternative to ddev and lando, that might have been something to consider before they existed, but it would be adding more noise rather than less to what people need to choose between.

@catch what im thinking is probably closer to what @geerlingguy very wisely suggested at the start of this thread.

ddev and lando are pretty feature rich and totally overkill for that "first spin up" experience so "alternative" is probably a strong word. im thinking more like a distillation or lowest common denominator. makes sense to me to provide the absolute minimum "official" tool and then as @elly points out people will move onto other things as they get their feet wet and discover what their needs actually are. Not sure i agree it would add more noise: "start with this, the official thing, when you're ready here are the power tools.". that seems like an improvement to what exists now.

if Drupal core doesnt want to maintain something like that, trust me, i get it. i'm just pointing out that its going to be hard for any generic third party dev tool to consistently solve this problem well for Drupal over time because things changes. Could end up not being a problem at all but could also be a big deal and i would hate to see Drupal get "PHANTOMJSed".

And yes obviously XAMMP should not be spoken of ever again.

There's been lots of enthusiastic input here and I see broad support for improving developer onboarding, but I don't see that there's consensus in the issue at this point, and since there was mention of "broad consensus" a few posts back I want to name that so we don't rush ahead.

To build consensus, we'd first need to know what it means to choose a default (still under discussion), which means the issue description here definitely needs the update mentioned in #56. Let's continue to do that so the proposal is clear - I think what's on that task list isn't what's happening at present :)

IMO as a community we need to be wary of unintended consequences. I think Drupal benefits at present from having multiple teams invest effort in competing to provide solutions in this space. Are we sure that we'd see things improve at the rate they have if we scared away business investment by picking a preferred solution? Would we take that risk in other market spaces like hosting or IDE? I think we as a community would have intuition to avoid picking a recommended partner in at least some of those spaces. Is there something special about local development?

We might similarly consider costs (or perceived costs) to agencies who've worked to standardise on a tool, then one day found out Drupal "switched" to a different tool. Sure, those agencies can continue to use tool y, but I worry about it reducing trust or introducing friction we didn't anticipate.

I'm very interested to know more about what "promote as the default" looks like (I think it's "document x by default", but that's not where the ID points). In this issue there's reference to DDEV being chosen for Craft CMS (see Craft CMS docs) and SilverStripe (can't find a link). (It'd be really interesting to see the discussions those communities had choosing a "default" or go-to solution! We should learn from other communities' experience if we can.)

I support the documentation style shown in Randy's screenshots, noting that the tabbed format used is explicitly supporting multiple paths (bash, powershell, ddev in that link). That'd be a great improvement which can happen with or without picking any single product as the default.

Full disclosure! I sponsor Lando FIVE BUCKS A MONTH on Github. But my level of personal investment is that I'm deeply grateful to people like @pirog, @rfay, @geerlingguy doing the work of making the multiple tools that make devs lives easier.

I've catched them all! Over my professional years as a Drupal Consultant, visiting many different companies and development teams I've used a lot of different tooling.

- Full custom Docker images (docker-compose)
- Basic LAMP/WAMP Stack
- VM's
- Acquia Dev Desktop (Yes... I know 😅)
- DevilBox
- Lando
- DDEV
- ...

And I must say, the experience between Lando and DDEV felt similar to me. At the time I don't think DDEV was a "thing" yet. So Lando was a huge improvement already over all the shenanigans that you had to do/install in order to work with plain docker compose. I think that at the moment, it is personal preference if you would prefer Lando or DDEV.

Given the similarities, it might be useful to go for the tabbed approach and let the user decide what they want to use. I also don't feel like we should be starting to duplicate a lot of documentation, because we all know they will go out of sync some day, rather quickly.

However, I have enormous gratitude to how involved @rfay is with Drupal and the community. Very inspiring to hear him talk, involve with people and always willingly to help out people, being it IRL, on Slack, GitHub,... 👏

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

What about the word "recommended"? In the end it's up to the developer what they choose, we can only recommend and express our preference.

I was going to make the suggestion about "recommended" vs "default" as well. Updated the title so that it's clear we're not going to do "marketing" for DDEV, from #54 :

The only thing being proposed here, at least initially, is that all Drupal.org docs (and maybe README.md) should suggest using DDEV consistently as the default option for new development environments, so that someone who just wants to get started can do so without having to weight up 3-5 different options first.

We have problems today about onboarding that needs to be solved as soon as possible, and anything more opinionated is better than the current state (this issue is from 2018 btw). People mentioned that Lando and DDEV are similar and both are a good solution to the problem we have today, so the choice is not going to be based on technical abilities. It reminds me of the situation when choosing a WYSIWYG editor a few years ago, one of the deciding factor was the willingness of the team behind the WYSIWYG editor to support the Drupal community in the integration/support phase, not the technical merits.

There are many praises towards DDEV support, as shown earlier in the issue many contributors use it (myself included), at the last drupalcon @justafish made a DDEV addon ddev-drupal-core-dev to setup everything for testing core (nightwatch, selenium, etc.). It could have happen in Lando I'm sure, it happened in DDEV. Lagoon just integrated with ddev, that's pretty interesting. It seems like DDEV is setting up to become a non profit and hired a maintainer paid by the foundation, which is reassuring.
If we settle on one tool today it does not mean that we won't ever discuss this again when the landscape changes. At this point DDEV seems like a more future-proof choice.

Given that we use DDEV as a core part of making Mentored Core Contribution possible at Drupal events around the world already, and that it has proved to be the most successful approach by far, I wholeheartedly support a move to declare DDEV as the “official” dev platform.

Whilst there are many benefits to Drupal being such a flexible system, where solutions can be reached by many different approaches, one massive problem is that that flexibility leads to a huge learning curve (okay, I have to include the cliff diagram!) to get started. We put off *so many people* from using our great CMS.

Where we can take strides to just say “This is the official approach but other approaches exist and are valid” helps people new to Drupal enormously.

We need d.o docs, articles, manuals and books to really all get behind consistent approaches to things if we are ever to build a great funicular railway up the cliff…

DDEV nowdays feels superior to Lando/Docksal. Regionally there might be tendencies in favour of on or the other, but avoid biases, DDEV wins in tricky areas:

- xdebug is a one click breeze with ddev. Can't say that with Lando and Docksal
- ddev get, the addons market, has too many option readily available, and it is easy to create your own and add it to the market
- snapshots! Unless the other two added them and I lost the notication. Snapshots are amazing, especially when dealing with DB updates. It's very easy to get to the previous state and re-test
- overall it is faster than the competition

I'm also in favour of promoting DDEV.

I frequently work with both Lando and DDEV, but when it comes to recommendations, DDEV stands out, especially for its ease of customization. This includes effortlessly integrating custom commands, toggling Xdebug, and incorporating add-ons such as Elasticsearch. Due to these features, DDEV is an exceptional tool, particularly beneficial for newcomers to Drupal development.

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.

People already using a method don't have to 'change' - 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. Power users can still use what they want - and again this is not solely about solving 'how to develop' in Drupal (though it does solve that very well). Its about making one way front and center, promoted in the docs and by core. This would remove the guesswork and high difficulty of even trying to run Drupal on your own. Later, if that person felt like they wanted another tool, or their agency wants to use another tool, etc, so be it. But at least they wouldn't be finding outdated docs and methods on drupal.org and it was more clear what was strongly advised to be used.

[...] 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 absolutely love DDEV! I use it on my MacBook with Colima and on a Linux (linux mint) machine with docker and I have never had any issues with it. @rfay does a great job of maintating DDEV and he is always around to answer questions!

I can see that declaring a single default/official/recommended tool could help someone coming in literally on their own (i.e. not part of a team that has input on what tool they use), who sees two choices and is like "er, ok but, now what? how am I supposed to pick??" To me, it's a not-nothing consideration, but not enough of a reason to recommend a single tool. So far, I don't see other ways it'd help less technical users more than "knock out some very old recommendations [...] by presenting a couple of good starting points for developers" (@wells #74) would help less technical users.

And, I think declaring one recommended tool will definitely have other effects. I think with these kinds of things (like SO many other tech things) (and non-tech things), people have their preferences and comfort zones, and a declaration like this would be something some folks would point to when trying to insist that the tool they use is Better and not just Better, significantly better, and their colleagues should all have to switch.

More importantly, I think one tool being officially recommended does imply more than just "we narrowed it down for you," I think it implies Drupal expects there will be better ongoing support of that tool. I don't think anyone is saying ddev is better supported than lando (right?), but I think it's a reasonable thing for a team lead to think if they see this kind of official/default recommendation -- and meanwhile, I think the implication alone can be a self-fulfilling prophesy (i.e. implying one is better leads to less use/support of the other).

Yes, I'm primarily a lando user. I've used ddev, I have no complaints, it's excellent, and, lando is what's comfortable for me -- and lando is also excellent (I don't think anyone's saying "lando is garbage"). And, I know no one's going to take lando away from me, BUT, as others have said, I don't think making a declaration like this will help less technical users -- I'd add, I don't think it'll help less technical users enough to outweigh the side effects on the local dev ecosystem overall.

-------

Extra thoughts:

@kevinquillen #73:

This would remove the guesswork and high difficulty of even trying to run Drupal on your own.

Totally agree, but as I say above, I don't think it's worth the effect it'll have on the ecosystem. (But removing outdated docs, yes please!)

@wells #56:

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.

Agree.

@wells #63:

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?

Agree -- and, I really like the language suggested in #72 (@wells)

There is definite support here for updating Drupal documentation to make it is easy as possible for someone new to Drupal to install and get started, no matter what there role. And DDEV does have support as the choice.

However the title "Recommend DDEV as the default Drupal local development environment" concerns be because I don't know what 'default' means in this case. This is referred to in #56 and #88. And I too need to understand what the community means by 'default'. And, by extension, what does it mean if I choose a non-default environment?

I currently do not support "a default Drupal local development environment'. What I do support is 'a recommended installation environment to get started with Drupal'.

Also, it would help if the issue summary included the current text on each doc page that is to change and the suggested new text.

And does this need a follow up to discuss wiki pages such as, https://www.drupal.org/docs/develop/local-server-setup?

I took another look at the pages to change

a) update the evaluator guide
This look like a complete rewrite, so adding text changes in this issue does not make sense.
b) update the download page
This has instructions and links to Drupal wiki pages, non of which refer to ddev. What is to change here?
c) Drupal Quick Start Command
This is linked from b). What needs to be changed here? Are the instructions incorrect?

Adding to #78

I looked for documentation with the "I want to set up drupal at a code sprint" persona, and starting with:
https://www.drupal.org/community/contributor-guide

* Some paths lead to Drupal Ladder http://drupalladder.org/drupal-core-ladder
* Some paths lead to how to roll patches, which leads to https://www.drupal.org/community/contributor-guide/reference-information... and
* this link which already has DDEV https://www.drupal.org/community/contributor-guide/reference-information...

(Reflecting.... it really is quite inconsistent and we really should be saying "What if they chose something, what would be the least regrettable decision that would make it easiest for us to help them.")

What I do support is 'a recommended installation environment to get started with Drupal'.

Is indeed more what I had in mind as well with my comment in #67. Tried to rename the title to reflect better what actually needs to happen.

With all recent comments I think we need to re-do the issue summary a bit as well.

I made a minor update to the issue summary to as well to remove words official and default to make it clear that the intention is to make to make a clear recommendation on a local development environment setup that sets users on good path when they get started with Drupal.

We don't need to hash out a detailed proposal for the documentation changes in the ideas queue. The purpose of this issue queue is to receive feedback from stakeholders on early stage ideas to avoid contributors from wasting time on work that would later get rejected.

I hear the concerns on recommending a single solution. I agree that we need to balance between making a recommendation and valuing the freedom for users to choose the platform they use to develop their sites. We need to be clear that our intent is to provide guidance for users who would have hard time making the decision themself, and not dictate a solution for others. Something along the lines of what Craft CMS has done seems like a good starting point for this (See #28). The specific wording is something we could discuss in the specific issue where we implement the changes to the documentation.

From Drupal core Product Manager perspective, the problem is valid and the plan to update documentation to recommend DDEV as the Drupal local development environment seems like a good solution to help new users be more successful with Drupal.

Once we have implemented the changes to the documentation, the next step would be to do some usability testing on getting started with Drupal. This way we can find challenges and points of friction that can be used for further improve the onboarding process.

-1 It would be great to have Lando as a default development env.

As salmunnings mantioned:

Lando has less friction looking outside of php and Drupal, making it nicer to work with in “Agency Land”, and the v4 dockerfile layering is not to be overlooked.

Also I agree with wells

Recent comments seem to establish that DDEV and Lando are equal features-wise and there are Drupal community members using both. Which is great!

I've opened #3398293: Consolidate local development environment documentation to recommend DDEV for implementation, we can identify pages to update, and sort out the wording etc. on that issue.

@lauriii, thanks for response, it was very helpful. And you are right, that the wording doesn't need to be here, in a an ideas queue issue. It was my mistake to not realize this was in the ideas queue.

I still have reservations about recommending a single development setup, whichever one it may be. However, their is definitely support for this to be approved. I'll wait to read the documentation changes.

I was about to set this to RTBC but I see it is now an 'Approved Plan'. I am not sure of the flow here, but should this be RTBC first? And what needs to happen for it to be Fixed?

I appreciate the discussion. Many of the recent comments addressed exactly my concerns and I like where this is ending up. I think this sums up my feelings best.

What I do support is 'a recommended installation environment to get started with Drupal'.

The tone of this really captures my feelings and I hope we include notes links about actively developed environments like lando and encourage people to try them because the all have strengths and that diversity helps our community and software be better. Something like a Tip section would provide a direction for people already familiar with those tools without distracting from the flow of on-boarding newer or less experienced developers.

reverted the unintentional changes. sorry.

One big strength of DDEV is that it is legally controlled by a friendly NOT-for-profit organization called "The DDEV Foundation" :) Usually, NOT-FOR-profit organizations value people above money. For you, this means lower risk of future Lock-In.

In comparison, Lando and Docker4Drupal are legally controlled by FOR-profit organizations. Usually, FOR-profit organizations are at higher risk to value money above people :( Docksal's legal control intent is not yet know. Because it is neither controlled by a NOT-for profit nor a FOR-profit organization. :|

Details and sources, starting with the 4th paragraphs, at https://www.drupal.org/forum/support/module-development-and-code-questio...

That' a very valid point!

Docksal is created by FFW. I do not wanna say it is for-profit (FFW certainly is) as things might have change since it was created. I believe they are still the ones behind docksal, but can't tell for sure.

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.

Re #74: if there is an intent to support less technical contributors as well, maybe we should consider to mention also DrupalPod/GitPod (https://www.drupal.org/docs/develop/development-tools/drupalpod), though it is aimed mostly at working with specific issues (not as a general development environment).

Devils advocate:
Acquia Dev Desktop was a perfect solution for Drupal 7. It "just worked" for any site I threw at it. But as we know, whether by coincidence or affected directly by the move to Composer requirement in D8 and the increased complexity of the Drupal theme stack, ADD was dropped like a bad habit. This was the tool developed and maintained by the largest, and Dries-run*, Drupal company, and it was simply forgotten. They moved on, no migration

This does not bode well for me when considering a "default" platform. Especially one open source supported. Key developers come and go, and the drop-off with Drupal 7-10 has been disheartening at the least, and downright destructive at the worst. Drupal is iterating and developing at a break-neck pace, with massive system changes and new requirements each upgrade.

We must consider that development in todays fast-paced market changes frequently, we've moved "off the island" but into tribes. Lets try to avoid a tribal mindset.

Hope this doesn't come off as a rant, but I've seen this time and time again, we've been on three different platforms for our D7,D8, and now D10 sites, each completely different than the last, and the knowledge of one does not transfer to another.

I hope you are talking about Drupal developers working on Drupal and not the rest of us using Drupal to create websites. No one in their right mind is going to want to use Docker. All you are doing is replacing normal development with a bunch of rigmarole that does the same damn thing. Why make it "official" anyway?

Disclaimer: I haven't looked at Lando or Docksal in years, but I did switch to using ddev locally (instead of MAMP Pro and Virtualbox) a number of years ago.

A few points I'd like to make:
* Instead of "official" or "default", how about considering this the "recommended" solution? IMHO this moves it from being perceived as the only solution to preferred solution, while still supporting others. Think of it similar to how Drupal supports MySQL and PostgreSQL, but MySQL is the recommended option.
* Something ddev has in its favor is a small, inexpensive book written by ultimike that IMHO can go a long way towards helping people learn the ropes.

FYI you can use ddev with different container providers - Docker, Colima, Orbstack, etc. I ditched Docker and Colima for Orbstack recently - it's notably less resource-intensive than Docker and more reliable than Colima.

Acquia Dev Desktop was a perfect solution for Drupal 7. It "just worked" for any site I threw at it. But as we know, whether by coincidence or affected directly by the move to Composer requirement in D8 and the increased complexity of the Drupal theme stack, ADD was dropped like a bad habit. This was the tool developed and maintained by the largest, and Dries-run*, Drupal company, and it was simply forgotten.

You can use Composer on Drupal 7 sites if you want, ADD had no bearing on that. No, MAMP died as Vagrant/Virtualbox rose. ADD was more or less a wrapper over MAMP. After that they advised to use DrupalVM (created by Jeff Geerling while at Acquia), and the virtualization generation now is containers everywhere you look. Acquia now advises using DDEV (and or sporadically Lando) all around their documentation. Again, it isn't forcing everyone to do this. It's solidifying a recommended approach that is already seemingly soft-recommended. Use whatever you want otherwise.

No one in their right mind is going to want to use Docker.

Container based development or running of services regardless of their runtime (Docker, Colima) etc is extremely popular across a majority of languages/platforms and not going anywhere. Again, this doesn't force everyone to use it or break anything you already have.

Keep in mind that DDEV is increasing in popularity for other platforms too, so it's not going anywhere anytime soon. Developers love it, companies love it (saves them money). So we be at peace knowing it's not gonna have ADDs fate.

Recommending it sounds like a nice step forward. After all, power users can use whatever they want, but newcomers will benefit a lot from seeing a recommended solution instead of going with WAMP/MAMP nowdays, which I still see people do! I even see ADD more often than it makes sense.

And if people contribute towards DDEV (financially or otherwise) the situation is only going to improve

Why would it be preferred? Lando is the better solution :troll:

But seriously re-iterating the jist of my previous comment, I think a lot of the discussions around official/default/recommended is kinda misplaced and based on a misleading title that also had me kinda ruffled. The goal of the issue based on the IS and most of the discussion seems be to provide a better first time experience. On boarding sprinters, getting started, demoing a working development environment, etc.

To me, pushing DDEV over Lando or something else as _the_ development environment would be like suggesting the Official/Recommended/Default browser for development is Firefox. Developers are going to choose the best too for them. And again, that diversity of environments is a strength we should nurture.

Imagine if we included an official WYSIWYG editor in core... no... wait. That's actually an example where the overhead required to avoid choosing a default direction was a constant drain on limited resources for many years. Including CKEditor in core didn't completely exclude alternative WYSIWYG editors, but it certainly made the work required to maintain them MUCH less appealing and the projects stalled and died fairly quickly after the decision to include CKEditor in core was made.

I think this is a healthy conversation to have, but I'm not sure that local development environments are in the same place WYSIWYG editors were when we compared CKEditor to TinyMCE and Aloha (remember Aloha?). While I have a lot of confidence in Randy Fay and the DDEV Foundation not to pivot towards a less open licensing/service model, picking a default anything for the project/community that kills alternatives only to see the default pivot to a less open structure that limits features and choice is a lesson I'd like to believe we learned from.

It is completely unrelated to CKEditor. The editor was about users and builders, the dev environment is about developers. Making the user experience better meant the world for them.
Alternatives died because they were not up to the competition.

A Dev or company can pick their environment, but suggesting something for newcomers and those looking for a shift from old ways is only going to help.

And like said above, DDEV is a non profit: https://ddev.com/foundation/

It is hard imagining it will go less open source. Keep in mind that Acquia controls much of Drupal and is not an open source company, or non profit. Why would you fear DDEV more than Acquia?

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.

It is completely unrelated to CKEditor. The editor was about users and builders, the dev environment is about developers. Making the user experience better meant the world for them.

I think it is very much related, whether it's the user experience or the developer experience, the goal is the same, to make it easy for people to choose and recommend Drupal, by making the [developer/user/site-builder/insert-word-here] experience better. That is what so many of our initiatives are aiming towards these days.

One of the direct benefits of including a WYSIWYG editor in core was that people installing Drupal didn't have to (or even need to know how to) do that, Drupal now comes with a damn-good editor out of the box. We lowered the barrier to entry for getting started with Drupal, we made it easier for people to choose and recommend Drupal.

Making the developer experience better for those first picking up Drupal, for those first getting started with it, is incredibly important, because today's developers, who choose Drupal now, are tomorrow decision makers, they are the ones who will be recommending their organizations adopt and choose Drupal.

We shouldn't forget that. It's not about us, the experience users, it's about the people who will become the experience users of the future and keep Drupal alive.

re #99 I would say if there was a discussion for why the decision was wrong this would be the place so as to not derail the implementation.

That said, most of the discussions seems to be arguing that we should choose DDEV? But that's already approved at least as the recommended on-boarding starting point. So I agree that's probably not productive and further clarifications can should happen on the related issues.

Thanks @AaronMcHale. I thought about responding to @bserem's comments, but when the decision was made to move forward with this, I was just going to let it go. Since the debate/discussion seems to be continuing here, I'd like to clarify a few things.

Alternatives died because they were not up to the competition.

This is not true. If you know much about the history of this decision, you know that the core team's original decision was to include Aloha. As someone who used TinyMCE on most projects, it was less about major differences between the WYSIWYG options and more about the custom buttons and integration work that needed to be done for one or the other on every project. It was less that the Aloha or TinyMCE weren't "up to the competition" and more that once an "official" recommended solution was chosen, you were swimming upstream to ask users to disable CKEditor and add jump through the hoops required to add a different editor module and javascript library. It no longer made sense to use an alternative so we gave up on TinyMCE and started contributing and customizing CKEditor instead.

And like said above, DDEV is a non profit: https://ddev.com/foundation/

Now. The origin story of DDEV is similar to Slack. DDEV is managed through a non-profit NOW, but it started within https://newmedia.com/ and was spun out with https://web.archive.org/web/20210926102655/https://ddev.com/news/ddev-co.... DRUD ultimately failed to gain traction in the competitive PHP hosting space. I love Randy, but he maintains DDEV as a Platform.sh employee. I've attended several of the sessions in the series of live training Randy has been doing to increase the size of the DDEV contributor community, but I think Randy would be the first to admit that if he were to step away from DDEV right now, the project would struggle. It is not yet self-sufficient.

Why would you fear DDEV more than Acquia?

I don't. I've been sponsoring Randy's work at https://github.com/sponsors/rfay long before it was even possible to sponsor DDEV directly. I DO worry about Acquia's influence and post about it often, but until FOSS funds and direct sponsorship become more popular, adding value on top of an open solution through closed, commercial services is still a very effective way to fund open source development.

In the "great WYSIWYG wars", I found myself on the losing side having to redo work. When it comes to local development, I've been using DDEV for years and would rather contribute DDEV configurations like https://www.drupal.org/project/operations/issues/3389217 or https://github.com/EqualifyEverything/equalify/issues/40#issuecomment-12... than get involved in a project I can't run in DDEV.

All of that said, the Drupal community needs to learn from history and be prepared for what is likely to happen when an official/recommended solution is chosen. If DDEV or Drupal pivot in a way that no longer aligns in the future, it's possible we'll find that Lando went the way of Aloha rather than continue swimming upstream competing with a recommended solution.

I don't think you can meaningfully compare DDEV with CKEditor. The CKEditor choice means we're using it for a long time, so we hope we were right. On the other hand DDEV has almost no risk in terms of regrettable choices. I have run DDEV alongside Lando and native docker compose on various projects. Lando will remain relevant. If rfay moves away we could literally find/replace DDEV with something else in the documentation and tell people to run a couple of commands to switch over.

For the CKEditor comparison you can look at ckeditor5. Porting Drupal 10 to ckeditor5 took well over a year and the release was delayed by six months, as well as all of the fallout with contrib modules which is only just about now catching up. We could have had that problem with any other wyswyg editor choice but the fact it's included in core puts all of the maintenance burden on core. Conversely, if it wasn't in core would we have ckeditor5 support at all by now?

Unless we actually rolled our own solution and shipped it with core (which no-one is volunteering to do), that's not an issue with development environments. I also think the impact of this decision on the relative popularity of DDEV vs. lando is unlikely to be seismic considering they're used for other projects/frameworks too, all we're doing is talking about updating and consolidating a handful of documentation pages in the end, some of which don't even mention DDEV or lando at all but XAMPP.

I switched like a year ago to ddev. I was using lando before and I definitely would approve the use of ddev,
I had so many weird issues with lando due to incompatible docker images used together., so far I got none with ddev.
Ddev is in my opinion easier to install/use and the fact that you have automatically additional tools such as Mailhog or PHPMyAdmin by default, that's a bonus.

I confirm that DDEV on WSL2 + docker-ce (no docker4windows) works like a charm.

Docksal was our default dev env for years (Linux & Windows), but we are seriously thinking about changing for DDEV if it becomes the suggested Drupal dev env.

+1 for DDEV! Switching to DDEV drastically improved the maintainability of my dev environment and the ease of getting someone else started on it, as it's easy to learn, configure, and update. It's also well-documented and has a great community.

Ddev is in my opinion easier to install/use and the fact that you have automatically additional tools such as Mailhog or PHPMyAdmin by default, that's a bonus.

Actually, PHPMyAdmin isn't a default anymore (it's now an addon). Also, DDEV now uses Mailpit, not Mailhog, which is a dead project.

I'm switching to ddev, thanks to this post and comments too:)

+1k to make it simpler to kickstart a Drupal with recommended Docker-based development tools 🎉 !

But I'm surprised we want to push one tool over the other 🤷.

I read comments expressing personal tastes but I didn't read any actual statistics about usage. Some numbers are available in this survey about Drupal developer local environments for instance. We see that the diff is very small (350 DDEV users vs 306 Lando users) but DDEV + Lando >= 50% of respondents.

If we want to cover the 80% use case as we often do, we should recommend at least both - they are different but both great anyway.

PS: I use Lando for years and DDEV since last year for different project/teams. IMHO Lando is better for newcomer because it is transparent. DDEV is more Drupal-oriented, with a learning-curve, because of its file structure. I'd like to show the diff between Lando and DDEV thought for a newcomer (see attached screenshot).

• Left file tab: the one-file Lando config after executing lando init --recipe drupal10
• Right file tab: the root config file after ddev config --project-type=drupal --php-version=8.3 --docroot=web

---

I hope we produce very easy install process to avoid our learning-curve effect #69.

Let's support diversity and recommend to try both tools 👐

@matthieuscarset FYI there is a 2024 dev survey and ddev seems to have taken a clear lead.

Oh, merci @pameeela. DDEV took a clear lead indeed! I guess I was wrong about the proportions 😄 Long live DDEV !

@matthieuscarset we wouldn't completely remove mentions of lando or other methods, but the problem at the moment is that by not recommending one, we're adding an up-front decision (with pages and pages of text if you include all the various pages collected in the issue summary) about what to use, on top of the work to actually set it up.

https://www.ironstar.io/devsurvey24/#local-environment suggests that ddev has taken over due to this issue, but for me that seems unlikely because we haven't redone the documentation yet, so that might be a bit of correlation vs. causation but it also does reinforce the direction here.

After switching to DDEV, I published a little guide for installing Drupal 10 with PostGIS on DDEV. Since then, my experience is better, if I compare with lando and docker4drupal.

I have also used both Lando and DDEV for many years. Lando is really great, but DDEV is just that much better in some aspects, that it should be recommended over the other solutions.

@Orkut Murat Yılmaz: Great write up! Since DDEV 1.23.0 (Apr 17, 2024) it's simply --project-type=drupal and --create-docroot is not needed:

• New drupal project type to cover Drupal 8+.
• ddev config no longer requires the --create-docroot flag, as it will create docroot automatically.

Plus, DDEV has the ddev-drupal-contrib addon, which makes it super easy to contribute to merge requests for contrib projects, and it allows you to easily run PHPCS and PHPUnit tests.

It's nice that Lando has a simple-looking file, but when it doesn't show any other options, you would have to go hunting if you want any more customization. DDEV has all of its config options documented in the config YAML.

@ressa, thanks for correcting, I'm adding your comment to that post too:)

Great! Also: --project-type=drupal10 is now just --project-type=drupal.

Adding credit for everyone who participated in this lively discussion :)

Thanks to everyone who chimed in. Since this has been approved by a product manager and has moved into implementation, I'm going to mark this issue as fixed. Ongoing discussion should take place at #3398293: Consolidate local development environment documentation to recommend DDEV.

Updating the issue summary with an "Outcome" section to clearly and definitively state that the resolution has been accepted. (It wasn't 100% clear to me without reading quite a few comments.)