🇺🇸United States @rfay

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.

@shaal and I rehashed this again on a call the other day. IMO this is really important. This has already been done for DDEV PRs and ddev-gitpod-launcher.

Thanks to @dalin for noting this and pursuing it. It does seem that this isn't a Drupalpod issue, or at least one that can be resolved in Drupalpod, so we need to be explicit about this for both new gitlab users and new Drupal.org users during the contribution workshops. @dalin has provided the exact steps to resolve.

rfay → created an issue.

@shaal this is a key problem when doing mentoring. Any thoughts about how to proceed with this?

I definitely wish this decision hadn't been made, but want to note that DDEV jumps through all these hoops for you for Drupal 11. It was not easy. DDEV uses the sqlite3 3.45 snapshots from snapshot.debian.org. I think for Ubuntu you might be able to use the snapshots from snapshot.ubuntu.com. But yes, this is a very inconvenient and difficult decision. Debian won't support 3.45 in stable until next year, and even then it will require update to full major version.

Kristen Pol → credited rfay → .

DDEV HEAD has PHP8.4.0alpha2 now, this should help with resolving the various issues. This will be updated and be in the next DDEV release, but is already available easily via HEAD, even using Homebrew. See https://ddev.readthedocs.io/en/stable/developers/building-contributing/#...

nicxvan → credited rfay → .

If you do this, please make sure to leave the `name` out of the `config.yaml`, so it can take the name of the directory it's in.

I would say try to include only the non-default lines of the `.ddev/config.yaml` and probably nothing else.

I'm not entirely sure this is needed, as

`ddev config --auto && ddev composer create drupal/recommended-project && ddev config --update` gets everything done right away. Or just `ddev config --auto` if composer install has already happened.

There are other projects that have moved to including the .ddev; it doesn't do much harm if the `name` is left out, but it does seem like it's a relatively inflexible approach, and it ends up having to be maintained in parallel with DDEV's changes. Not that things change much, but for example, if the default `php_version` changes (as it will this fall) or the `database` defaults change (as they have for D11) then the config has to be updated, whereas DDEV itself would have handled all that.

I demonstrate how to do this without changing composer.json in https://github.com/justafish/ddev-drupal-core-dev/pull/33 - that could be done anywhere. @joachim has more opinions about how to manage this problem. But it's not a very big lift to just install drush and then let git and composer.json forget that you did it.

nicxvan → credited rfay → .

nicxvan → credited rfay → .

nicxvan → credited rfay → .

ChrisDarke → credited rfay → .

Deleting the drupalpod/.git would be a step forward, but they still wouldn't know what to do next.

People don't read anything as you know, but adding more instructions is still OK.

Is there a way to change the default directory? That would also solve it, if we put them in the repos/* directory to start.

Thanks for opening this issue @dalin - All of us helped people who had this class of problem at the mentored contribution at Drupalcon Portland 2024.

I helped quite a few people with this confusion at the Mentored Contribution. They opened drupalpod and ended up in the drupalpod git repo (which is irrelevant to them) and didn't know what to do next. They were fine when I got them into repos/ but not fine before that.

rfay → created an issue.