<p>There was no weirdness going on (Thanks CraftQuest in the comments), just my lack of fluency in the command line and newbie status with DDEV leading me to think the problem was somehow to do with database connectivity ( in my context, <code>ddev</code> is <em>my</em> <code>craft</code> CLI ‘owner’, not <code>php</code>).</p>
<p>Looking more carefully at the error logged by <code>composer update</code> I could see that I had left <code>useProjectConfigFile=false</code> in my <code>config/general.php</code> and that was why the upgrade was not running: see <a href="https://craftcms.com/docs/4.x/upgrade.html#configuration" rel="nofollow noreferrer">leaving legacy settings in general.php will throw an error</a>.</p>
<p>Once removed, <code>composer update</code> ran just fine.</p>

CC BY-SA 4.0
2023-07-03T10:49:48.563Z
2023-07-06T11:42:55.137Z
2023-07-06T11:42:55.137Z
Jonathan Schofield
<p>I've been through the following steps on a local instance of a Craft 3.x project:</p>
<ol>
<li>Followed <a href="https://craftcms.com/knowledge-base/migrating-from-craft-nitro-to-ddev" rel="nofollow noreferrer">Migrating from Craft Nitro to DDEV</a> and got the instance running on DDEV</li>
<li>Updated to latest version of Craft 3: 3.8.14</li>
<li>Gone through all the <a href="https://craftcms.com/docs/4.x/upgrade.html" rel="nofollow noreferrer">Upgrading from Craft 3</a> checks</li>
<li>Attempted to run the update to 4.0.0 with plugins</li>
<li>Had a fail</li>
<li>Reverted to 3.8.14 from backup</li>
</ol>
<p>I've done steps 4 to 6 a few times and after looking at a couple of possible points of failure not got anywhere.</p>
<p>Now that I'm back at 3.8.14 I thought I'd try garbage collection with <code>php craft gc</code> and curiously I get:</p>
<blockquote>
<p>Craft can’t connect to the database. Check your connection settings.</p>
</blockquote>
<p>…even though my instance clearly <em>can</em> connect, as I can navigate around the Control Panel and make changes!</p>
<p>Which makes me wonder if there's something related blocking the upgrade to 4.x.</p>
<p>My <code>config/db.php</code> has standard ENV references:</p>
<pre><code>return [
    'dsn' =&gt; App::env('DB_DSN') ?: null,
    'driver' =&gt; App::env('DB_DRIVER'),
    'server' =&gt; App::env('DB_SERVER'),
    'port' =&gt; App::env('DB_PORT'),
    'database' =&gt; App::env('DB_DATABASE'),
    'user' =&gt; App::env('DB_USER'),
    'password' =&gt; App::env('DB_PASSWORD'),
    'schema' =&gt; App::env('DB_SCHEMA'),
    'tablePrefix' =&gt; App::env('DB_TABLE_PREFIX'),
];
</code></pre>
<p>and my local <code>.env</code> has what I believe to be correct for ddev:</p>
<pre><code>DB_DRIVER=&quot;mysql&quot;
DB_SERVER=&quot;db&quot;
DB_PORT=&quot;3306&quot;
DB_DATABASE=&quot;db&quot;
DB_USER=&quot;db&quot;
DB_PASSWORD=&quot;db&quot;
</code></pre>
<p>Where might I be going wrong?</p>
<hr />
<h2>Update</h2>
<p>I just ran <code>ddev craft db/backup</code> and that went fine with a new file in the reported location.</p>
<p>So clearly I have db connection!</p>

CC BY-SA 4.0
2023-07-03T05:57:43.793Z
When you ran garbage collection did you run it with ‘ddev craft gc’?

Also, what happened when you “had a fail”?
CraftQuest
CC BY-SA 4.0
2023-07-03T10:12:48.283Z
Oh, of course! That makes sense. Thanks. I'm not used to thinking natively in the command line. Now onto the next bit.
Jonathan Schofield
<upgrades><nitro><ddev>
Can't upgrade to v4.x after migrating from nitro to ddev – db connection weirdness
# Can't upgrade to v4.x after migrating from nitro to ddev – db connection weirdness

(Asked by: username_0 on 2023-07-02)

I've been through the following steps on a local instance of a Craft 3.x project:

Followed Migrating from Craft Nitro to DDEV and got the instance running on DDEV
Updated to latest version of Craft 3: 3.8.14
Gone through all the Upgrading from Craft 3 checks
Attempted to run the update to 4.0.0 with plugins
Had a fail
Reverted to 3.8.14 from backup

I've done steps 4 to 6 a few times and after looking at a couple of possible points of failure not got anywhere.
Now that I'm back at 3.8.14 I thought I'd try garbage collection with php craft gc and curiously I get:

Craft can’t connect to the database. Check your connection settings.

…even though my instance clearly can connect, as I can navigate around the Control Panel and make changes!
Which makes me wonder if there's something related blocking the upgrade to 4.x.
My config/db.php has standard ENV references:
return [
    'dsn' => App::env('DB_DSN') ?: null,
    'driver' => App::env('DB_DRIVER'),
    'server' => App::env('DB_SERVER'),
    'port' => App::env('DB_PORT'),
    'database' => App::env('DB_DATABASE'),
    'user' => App::env('DB_USER'),
    'password' => App::env('DB_PASSWORD'),
    'schema' => App::env('DB_SCHEMA'),
    'tablePrefix' => App::env('DB_TABLE_PREFIX'),
];

and my local .env has what I believe to be correct for ddev:
DB_DRIVER="mysql"
DB_SERVER="db"
DB_PORT="3306"
DB_DATABASE="db"
DB_USER="db"
DB_PASSWORD="db"

Where might I be going wrong?

Update
I just ran ddev craft db/backup and that went fine with a new file in the reported location.
So clearly I have db connection!

**Tags:** upgrades, nitro, ddev
> **Comments:**
> **username_1**: When you ran garbage collection did you run it with ‘ddev craft gc’?  Also, what happened when you “had a fail”?  
> **username_0**: Oh, of course! That makes sense. Thanks. I'm not used to thinking natively in the command line. Now onto the next bit.  

---

## 1 answers

### Answer by username_0 on 2023-07-03. Score: 3

There was no weirdness going on (Thanks CraftQuest in the comments), just my lack of fluency in the command line and newbie status with DDEV leading me to think the problem was somehow to do with database connectivity ( in my context, `ddev` is *my* `craft` CLI ‘owner’, not `php`).

Looking more carefully at the error logged by `composer update` I could see that I had left `useProjectConfigFile=false` in my `config/general.php` and that was why the upgrade was not running: see [leaving legacy settings in general.php will throw an error](https://craftcms.com/docs/4.x/upgrade.html#configuration).

Once removed, `composer update` ran just fine.


---

