🇺🇸United States @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.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

FYI for Drupal 11 only, DDEV will pull the Debian Trixie Sqlite3 package in v1.23.1, see https://github.com/ddev/ddev/pull/6137

I do think the 3.45 requirement will cause a lot of pain for the next year while operating systems catch up. People who are deployed on any stable distro other than Ubuntu 24.04 will find pain.

But as we all know... it's not used mostly except for testing. At least I think the installation and dburl are the only places you get complaints?

rfay → created an issue.

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

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to hidden.

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to active.

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to hidden.

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

Just a note here about SQLite 3.45 compatibility. The OP says

> Debian and Ubuntu both have releases scheduled prior to Drupal 11's earliest release date which will support SQLite 3.45.

But that's definitely not true. Debian's next release (13 Trixie) is more than a year away, and current Debian 12 Bookworm has sqlite3 version 3.40.1. Trixie will in fact have 3.45 or later, but it's most likely Summer 2025. See https://en.wikipedia.org/wiki/Debian_version_history

(Ubuntu 24.04 does in fact have sqlite3 3.45.1)

This is a bit of a struggle for DDEV, because the ddev-webserver in v1.23.0 just upgraded to Debian 12 Bookworm, and likely won't get to Trixie for more than a year (certainly it will be after Trixie is released). It's never a stability-builder to mix packages from different distro versions, so I'm reluctant to put 3.45 in ddev-webserver by default, at least using the mixed-debian-version technique.

* DDEV issue: https://github.com/ddev/ddev/issues/6110
* ddev-drupal-core-dev workaround: https://github.com/justafish/ddev-drupal-core-dev/pull/23#discussion_r15...
*joachim-n/drupal-core-development-project - also pending

shaal → credited rfay → .

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

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.

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

DDEV HEAD now has PHP 8.3 support; you can already use it with `brew install --HEAD ddev/ddev/ddev` or other ways, https://ddev.readthedocs.io/en/latest/developers/building-contributing/#...

It will be in v1.22.2 before terribly long.

Not all extensions are there yet, as they're not in the upstream deb.sury.org packaging. So xdebug is still missing, for example.

Totally agreed @longwave, but the flip side is the entire ecosystem has become dependent on Umami because it's so great for demo environments. We all use it like crazy for everything. Maybe it's so very good that it should be promoted from experimental. Obviously it's not for production, but that doesn't mean it's not as valuable as something that should be for production.

Thanks, so glad to understand this better! I'm sure the ddev-drupal9-solr instructions can be improved as well because I've seen this a number of times when testing.