🇺🇸United States @rfay

Present and accounted for

Transfer ownership of the ddev-drupal-suite add-on from the current repository to the official DDEV namespace for greater visibility, credibility, and community adoption.

We certainly appreciate add-ons maturing into the ddev namespace, but not until they have a track record of usage and maintenance.

A casual look says that ddev-drupal-suite doesn't even have the `ddev-get` topic yet, doesn't have tests, and I don't think the README even explains why it exists and doesn't have a comparison to other (mature and existing) add-ons for the drupal world. It looks like this add-on wasn't created from the template, and doesn't subscribe to the best practices expounded in https://ddev.com/blog/ddev-add-on-maintenance-guide

(I've subscribed to all activity in the add-on)

I ruined everything.

Good luck, but this isn't the place to discuss it. Maybe folks in the Drupal slack #support can direct you to the right place. You have a problem with your git.drupal.org setup or your use of it. This class of problem is almost always fully confirming the git.drupal.org account or using the correct ssh key, etc.

Hi @rraney - I imagine you haven't confirmed your git.drupalcode.org account? Can you fork other repositories?

• Installation is now done with a GUI installer instead of a PowerShell script
• wslu explanation is outdated; ddev launch now uses explorer.exe
• Prefer drupal11 in examples

There are a number of updates here as time has moved along.

• The path to WSL is now `\\wsl.localhost\<diistro>`
• `wsl --install` now does the UAC itself, so it's not necessary to install from Admin PowerShell
• Windows Terminal now ships with Windows

Yes, that link is fine. It's completely baffling to have two competing MRs and have an issue be marked RTBC without reference (that I understand) to which MR :)

I'm fine with whatever you come up with to see how it works out. This is not critical stuff.

But please, please, leave the `name` element out of the config.yaml so you don't have the wired project name in there. It's far better IMO for it to take the name from the enclosing directory.

I was there!

Related conversation in search_api: https://www.drupal.org/project/search_api/issues/3520659#comment-16149749 ✨ Enabled local development env with DDEV Active

I rarely recommend adding a .ddev/config.yaml, and never recommend adding the `name` element, since it means you've wired the name of the project. (It can be omitted)

The best approaches are DDEV add-ons like https://github.com/ddev/ddev-drupal-contrib

Just committing everything like this is really inflexible, compared to an add-on where it can be maintained properly and updated easily.

I guess https://github.com/PHPCSStandards/composer-installer/issues/239 needs a better or more complete repro case to convince the maintainer there?

Hi, DDEV maintainer here. I don't usually encourage committing .ddev in contexts like this.

And here, it seems especially inappropriate, with included add-ons at specific versions, etc.

IMO it would be much better to just explain to people in the README how to configure DDEV for local development.

We encourage committing the .ddev to projects, for a team to standardize and maintain, but this is a completely different situation

Present.

lostcarpark → credited rfay → .

rachel_norfolk → credited rfay → .

Gitpod Classic sunset seems to be delayed to Fall 2025, and they seem to be suggesting flex might work in the future.

DrupalCon Atlanta BoF Results.

My summary:

Some thoughts from the BoF about future of DrupalPod:

• Drupalpod actually has two uses: Just letting people contribute easily to Drupal, and as a great technique for contribution day at Drupal events. Those are related but somewhat different uses.
• Ofer doesn't seem to have the passion for it any more.
• Darren's generous contribution in making DrupalForge follow the DrupalPod platform may have a future, although it's a very different thing, not DDEV based, not Docker based, and doesn't use the practices we normally recommend. My own experience with it has been that it isn't performant enough to be usable, but I imagine this is a solvable problem.
• @mradcliffe long maintained the quicksprint package, which is a way to build a full set of DDEV artifacts that can be pre-distributed or distributed via a flash drive or whatever. It worked back in the day, and Matthew has refreshed it already in a fork. It might not be easy to make "picker" that gets the right issue fork and all. So this gets DDEV and related tools, but doesn't necessarily simplify the overall contribution workflow. We used Quicksprint in the days before issue forks (and before WSL2, etc. etc)
• There are systems like Gitpod that might be candidates for another look. GitHub Codespaces is fully supported by DDEV, if it's going to have a "picker" browser extension like Drupalpod it would probably have to be implemented a different way. Coder has been recommended, but I don't think there's a free community-usable version.
• Mike Anello asked what a MVP might be. We don't know what it might be or how we would accomplish it, or who has the passion for it.

The recording of the BoF is attached.

mradcliffe → credited rfay → .

volkswagenchick → credited rfay → .

rfay → created an issue.

mradcliffe → credited rfay → .

@capelilic, not the problem with the new GitPod Flex is that it needs to be installed on your machine (and only supports mac at this point). So it has no advantage over a Docker/DDEV setup. We had a meeting with them to get them to demonstrate it working self-hosted like on AWS, but they weren't able to get it going, although they made a big deal out of it. I'm really surprised they don't even support Intel macs.

kristen pol → credited rfay → .

mradcliffe → credited rfay → .

mradcliffe → credited rfay → .

`time composer update --with-all-dependencies` (with no changes to the composer config) took 1m20s.

When it completed, I got an untrusted URL for the VS Code interface at https://cs-dev-306b2ae7-80a772f5-aft17lcv.cms-devpanel.click/

The cert was issued to `localhost`, not to *devpanel.click.

Your connection is not private
Attackers might be trying to steal your information from cs-dev-306b2ae7-80a772f5-aft17lcv.cms-devpanel.click (for example, passwords, messages, or credit cards). Learn more about this warning
net::ERR_CERT_AUTHORITY_INVALID
Subject: localhost

Issuer: localhost

Expires on: Jan 18, 2038

Current date: Mar 10, 2025

PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIICNzCCAd2gAwIBAgIRAOOlAFcVJt3VNDllSx6THDEwCgYIKoZIzj0EAwIwdTEL
MAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBG
cmFuY2lzY28xDTALBgNVBAoMBEtvbmcxFjAUBgNVBAsMDUlUIERlcGFydG1lbnQx
EjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0yNTAyMTgxMzMyMTFaFw0zODAxMTkwMzE0
MDhaMHUxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQH
DA1TYW4gRnJhbmNpc2NvMQ0wCwYDVQQKDARLb25nMRYwFAYDVQQLDA1JVCBEZXBh
cnRtZW50MRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAAQiE6cjCQcKa68YCAfbPtQnm1mCaQZaY8+6Efom3/0zTkwzVrbu09BPQjn0
T4I/ehSkLZN7mpOeCZvk2ovlf/wXo04wTDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUpDjlZngv5rZGPUElbikL
pKPQMTEwCgYIKoZIzj0EAwIDSAAwRQIhALNrzY6ooNfEkXIiEQNg1hus8i43YzRH
RZhSblU7kfGYAiAs6NzbzHvUM37ZRHlslOVja2pioONHMwTbVREAX/eGcA==
-----END CERTIFICATE-----

I tried again this morning. Waited 25 minutes for the build before moving on to something else. https://dev.drupalforge.org/drupalpod/bcec9fb8-ef6b-4dcc-984e-9c4d23d09662

I think the goal should be <2-3 minutes to be useful.

Thanks, I'll give it another go when you say it's ready.

mradcliffe → credited rfay → .

Updated OP to show that the Chrome extension is no longer obsolete, has been updated, so that's not a problem.

Thanks for your work on this. @shaal did a competing v3 update and it's deployed and is working.

Oh, I see drupal is installed in repos/drupal, as it was in Drupalpod. I always hoped that would get fixed and be more obvious, it's too bad that it has landed here :(

The suggestion in Drupalpod was that the drupal code might land in /workspace/drupal and the VS Code interface be opened there by default. Maybe you'll be able to do something like that.

The build completed after 20-25 minutes.

I see it's PHP 8.3, and `composer install` worked.

`composer require drush/drush` never seemed to return, no output given. I guess this is just amazingly slow.

I also tried `time composer require drupal/search_api_solr` to see what would happen and if it would be usable after that. It took 6 minutes.

I tried to log into the application, but was unable to, not knowing the username (or maybe the password?)

`composer require drush/drush` got me able to do a `drush uli`, but it took 5:40 to complete

Having two separate UIs (the application and the VS Code) is a little complex, but I would think people could learn how to navigate it.

Right now, it's the overall performance that makes this way too hard to use.

@darren I don't see any option in the extension UI to choose a PHP version, and since it can't be changed other ways, it's a bit complex. I would certainly think people would expect that capability.

The git version I checked out is not what I expect, I asked for 11.x, but I get drupalforge instead. It's really unclear what I should be doing to look at the MR I checked out.

Thanks for working on this important project!

I'm trying this out. Some nits in the presentation: The grammar and usage can be improved.

"This can take up a few minutes" -> "This can take a few minutes"

"Access to DevPanel to work more Powerful" -> (Rethink this to say what you want. It's not meaningful currently in normal English usage). Maybe "Use DevPanel to empower your work" or "DevPanel helps power your work" ?

* The build of this took a really, really long time and it didn't give any idea of how it was progressing or when it might complete. I gave up after waiting 15 minutes, but will leave the tab open to see if it ever completes. (https://dev.drupalforge.org/drupalpod/3dde90ea-f4e2-4e39-9b6d-7fa13f1d43bf)
* Since I haven't seen it yet... Is there a way to configure PHP version or related configuration?

volkswagenchick → credited rfay → .

Please add testing instructions to your PR. It seems to have all the coderabbit nonsense but nothing to say what was done or how to test it.

Oh, sorry, I didn't even know about the other repository, and didn't read carefully enough!

All of the code from GitHub came over here, https://git.drupalcode.org/project/drupalpod

Thanks for working on this @darren - The authoritative code for Drupalpod is here, not on github. Please do your update as an MR here, thanks.

When you do it, please provide instructions on how to test your updated extension, and what it has done.

You can certainly use `.ddev/.env` in gitpod/drupalpod.

Well, you don't have to *use* the zipball :) Or tell anybody it exists!

I guess I would have removed the zipball entirely and just done the `ddev composer create`. What's the value of the zipball here?

Even though most DDEV blogs are not specifically Drupal-focused, they probably do generally benefit the Drupal community.

There is a BoF Scheduled for this at Drupalcon Atlanta, 04:00pm - 04:30pm Tuesday, March 25, 2025, join us!

I do have a question here that is a bit meta. Why are we using a complex launcher script that requires all this maintenance, when we can do the exact same thing with `ddev composer create` as with the suggested `composer create-project`? The DDEV-recommended technique in https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal-drupal-cms is to do the `ddev composer create` and it's very easy. I'm baffled why we need a launcher script and a zipball. Or perhaps if we want a launcher script, why doesn't it just do the `ddev composer create` ?

I'm happy to open another issue, but this one could be put aside if we just went with simpler instructions.

rfay → created an issue.

mradcliffe → credited rfay → .

This looks just right to me. Note that when add-ons change, or an update is needed, somebody needs to do an MR with the change.

phenaproxima → credited rfay → .

You do have to do a `ddev restart` one time. After doing that and moving on with the `ddev rebuild` command I expect you won't see the warning. The command to set up the database happens on start (post start) with a Drupal project.

phenaproxima → credited rfay → .

phenaproxima → credited rfay → .

mradcliffe → credited rfay → .

mradcliffe → credited rfay → .

mradcliffe → credited rfay → .

mradcliffe → credited rfay → .

I'm able to confirm this error, using both Lima and Orbstack as Docker providers, but only on Safari version 18.2. I had to upgrade the mac to Sequoia 15.2 to get it.

I can reproduce reliably with this procedure:

1. unzip drupal-cms.zip
2. mv drupal-cms . For example, `mv drupal-cms dc6`
3. cd dc6
4. ./launch-drupal-cms.sh
5. When it opens web browser, switch over to Safari, with the right URL, like https://dc6.ddev.site
6. Select all of the options, next
7. Use admin@example.com/admin for username/pass
8. Say "never for this site" when it prompts to save password.
9. It dies after a long pause after "Applied projects recipe"

The website encountered an unexpected error. Try again later.

Error: Call to a member function getPath() on null in drupal_cms_installer_theme_registry_alter() (line 286 of profiles/drupal_cms_installer/drupal_cms_installer.profile).
Drupal\Core\Extension\ModuleHandler->alter() (Line: 434)
Drupal\Core\Theme\Registry->build() (Line: 276)
Drupal\Core\Theme\Registry->get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry->initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry->__construct() (Line: 314)
Drupal\Core\Theme\Registry->getRuntime() (Line: 141)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 176)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->makeSubrequest() (Line: 132)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->on404() (Line: 109)
Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I did not manually test, but this should be perfect. (Manual testing hasn't been working today anyway)

I'm fine with just `--php-version=8.3`, think everything should work fine that way.

phenaproxima → credited rfay → .

Please note in the OP that `https://shaal.github.io/DrupalPod/` is not the URL of gitpod any more. I assume you're actually using this repo? https://www.drupal.org/project/drupalpod →

This is the script I've been using to create a new directory for testing:

#!/bin/bash

set -eu -o pipefail
set -x

ddev delete -Oy project-template
rm -rf ~/tmp/project_template && cp -r project_template ~/tmp

@bhanu951, you have to get the test directory *outside* the repository, which has its own .ddev folder. Otherwise DDEV discovers the parent directory (as it told you) and refuses.

So copy the directory to ~/tmp/project-template or something.

When this gets deployed, the directory will be standalone, it won't be living as a part of this repository.

I tested this repeatedly in
* WSL2
* macOS
* With the COMPOSER_CREATE set to use the temp special repo
* Without that.
* Introducing deliberate syntax errors into the script to simulate random errors.

I think it behaves quite well enough for our purposes right now, and it can mature as we get feedback.

The sh `[ ]` format is shorthand for running the built-in `test` command. So `if [ -f /path/to/file ]` means `if test -f /path/to/file`

But the general use is `if somecommand` where success is `somecommand` returning 0. `test` is a special command.

`command` is part of the POSIX spec, so should work everywhere.

It should be OK, it will get more eyeballs if deployed. Thanks for the quick action!

This is looking good. I don't know how to manually test it, but I like it.

I would remove the `php_version`, `use_dns_when_possible` and `composer_version` lines from the provided config.yaml in the zipball. And I would change the `ddev_version_constraint` to `>= 'v1.24.0` just because we don't need to chase old weirdness that could crop up.

`php_version` 8.3 is default with current DDEV. And corepack_enable is true for drupal11 project type

rfay → created an issue.

rfay → created an issue.

@john-cook, I imagine you have a different problem, and I'd be happy to help you chase it. If your mutagen sync takes forever, it normally means you have huge files some place that `upload_dirs` doesn't know about.

I just tried this and it worked fine.

Please make sure you start by creating an empty directory, *then* unzip the zipball into that empty directory. Then `cd` into the directory and `ddev start`.

For example:

mkdir my-drupal-cms && cd my-drupal-cms
unzip ~/Downloads/drupal-cms.zip
ddev start
ddev launch

The mutagen sync should take less than 30 seconds in this situation.

There are a few problems here.

1. Please use DDEV's `drupal11` or `drupal` project type. (`ddev config --project-type=drupal --docroot=web`). If you had done that, the database information would have been filled in for you automatically,, and you wouldn't have had to know what the database settings were.
2. Please use the current version of DDEV, v1.24.0, rather than an older one, especially when debugging problems.
3. The database settings used with DDEV are explained many places, including the FAQ, "How can I connect to my database", see https://ddev.readthedocs.io/en/stable/users/usage/faq/#how-can-i-connect.... In DDEV, from the web container, the hostname is "db" (NOT localhost), username "db", password "db" and database "db". (not "test", although you could create one named "test", but we'll leave that for another time. (Read more about databases at https://ddev.readthedocs.io/en/stable/users/usage/database-management/ )

Happy to help you get farther along in #ddev in Drupal slack or DDEV's discord, https://discord.com/invite/5wjP76mBJD

Please use current stable DDEV (currently v1.23.5). If that doesn't solve it, come on over to DDEV and we'll be happy to help. AFAICT this has nothing to do with Drupal CMS, but it may have to do with using an old version of DDEV.

I note that the project README still only references Drupal 9 and Drupal 10.

> The 4.3 release of this module is works for Drupal 9 and 10! And it supports a wide range of Solr versions from 3.6 to 9.

As there hasn't been a commit to this project for 7 years, and you seem interested, I made you a maintainer of the project @jenlampton.

@samuel.mortenson, DDEV does it for Debian 12 Bookworm like this, which is very ugly: https://github.com/ddev/ddev/blob/a82397976cb06a440b23a81a474ceda13a428a...

Or build an Ubuntu 24.04 image and you can just apt install it.

Or you can use DDEV, which has been doing this for some time.

I don't know what `com.ddev.app-url` might have been used for, but I imagine it can be removed. It's not a required label (https://ddev.readthedocs.io/en/stable/users/extend/custom-compose-files/...)

In passing, note that the docker-compose.chromedriver.yaml there can only be used on AMD64 machines, so leaves out lots of local development environments. It would be better to remove that and refactor slightly to use `ddev add-on get https://github.com/ddev/ddev-selenium-standalone-chrome`

There shouldn't be a `~/.ddev/docker-composer.chromedriver.yaml` at all (that ~ means your home directory) but you may have a `.ddev/docker-compose.chromedriver.yaml` (not `docker-composer.chromedriver.yaml`).

There is also not a .ddev directory provided by this project. And there are no yaml files in this project.

So something about your setup is the problem.

I do find a reference to docker-compose.chromedriver.yaml in https://github.com/ddev/ddev-contrib/blob/41113f04f060177002de4a7b64086f... - you probably somehow had that obsolete recipe in your world somehow.

As it says there, "**The recommended approach for running tests that require ChromeDriver is to use [ddev-selenium-standalone-chrome add-on](https://github.com/ddev/ddev-selenium-standalone-chrome) instead.**"

Hi - DDEV maintainer here. I took a look, and there is no instance of DDEV_URL at this point in DDEV core, and there hasn't been for a year or two, but there used to be an instance of that in the GitHub Codespaces setup for DDEV.

I searched the entire DDEV org on github and didn't come up with anything. But I imagine you'll find out what's happening if you `grep -r DDEV_URL .ddev` in your project directory.

This was apparently a problem with Gitpod and was resolved in https://github.com/gitpod-io/gitpod/issues/20263 thanks to your effort, right?

Please close this if it can be closed now. Thanks for chasing that!

Just stopping by to say thanks for all your work on this!

Docker is complex, technical, and intimidating to set up, which I think makes it an inappropriate choice for the kind of end users we're targeting.

I don't think most DDEV users would agree, but I might be wrong. Most users set up OrbStack or Docker Desktop or Rancher Desktop in moments using the standard installers. There is no complexity any more than any other app they might install. DDEV users generally don't need to know anything at all about Docker, unless they start to get way out of the box. There are capabilities there, but I'll bet 95% of DDEV users don't add a custom Dockerfile or `docker-compose.*.yaml`

rfay → created an issue.

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

Congratulations on getting this to RTBC!

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

Rebased against examples 4.0.x

This was accepted and solved

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.