Using DDEV for local ProcessWire development (tips & tricks)

[3fingers]

Just wanted to share what I've just found:

https://get-deck.com/

It looks like a nice Docker environment with a simple GUI and lots of options.
I'll try it for the next projects.

[bernhard]

For several days I've had issues with connecting to my host from within the ddev container when using RockShell for a quick

php rockshell db-pull staging

I got the following error:

Quote

Received disconnect from ... port 22:2: Too many authentication failures
Disconnected from ... port 22

Turned out that the problem was that I had too many SSH keys in my container (4) and the webhost seemed to block the request before ddev could use the correct key.

The solution was to put only the two necessary keys in a dedicated folder ~/.ssh/ddev and then provide that folder as parameter on ddev auth ssh:

ddev auth ssh -d ~/.ssh/ddev

It have been tough days having to restore the database manually from staging to my local development ? 

I guess nobody will ever have problems with this as it's a quite specific situation but maybe it helps someone googling for it...

[netcarver]

Not sure how rockshell works, but I find SSH's config file very helpful. Perhaps something like this in ~/.ssh/config this could help here (if not already in use)?

Host *
    IdentitiesOnly=yes
    
Host staging
    IdentityFile ~/.ssh/<YOUR STAGING KEY FILE>
    #User bernhard ## Uncomment and change if server account doesn't match your local name
    #Port 22 ## Uncomment and change if server not listening on port 22

Any time an ssh connection is attempted to staging, it should use the correct identity file (or files if you add more IdentityFile lines,) rather than have SSH try all your keyfiles until the server complains.

[bernhard]

Hey @netcarver thx ssh config files are great for sure, but they do not work when using DDEV because you are in a container and not on your host's filesystem with the ssh config file in place.

That's why ddev has the ability to do "ddev auth ssh" where it grabs all SSH keys from the host and copies them into the container. Then you can do ssh magic in the container just as if you were working on the host. Almost. The issue I explained above was only occuring inside the container. On the host machine "ssh foo" just worked because the ssh config file was in place.

Hope that makes sense.

RockShell's db-pull command uses exec() to connect to the remote server via SSH, then it creates the remote dump, it copies it to the local filesystem, then it restores the dump and then it triggers all migrations.

That way you can quickly develop locally, do anything you want, try crazy stuff and if you want to start over you just do "php rockshell db-pull staging" and you get a clean version that you have on your remote. Same goes if you added a feature locally and you want to make sure that everything works when pushing to remote. Then you can do a db-pull as well and fire all migrations to see if you forgot anything.

Hope that makes sense as well.

[bernhard]

It's just a link to the docs, but maybe it's not so obvious for some that you can even use DDEV to share the project on your local network, so you (or hackers) can access the site from a mobile phone or any other device: https://ddev.readthedocs.io/en/latest/users/topics/sharing/#exposing-a-host-port-and-providing-a-direct-url

ddev config --host-webserver-port=8080 --bind-all-interfaces

Then ddev restart and then you can access your site locally at something like 192.168.1.2:1234

To find your local ip address you can use

ifconfig | grep "inet " | grep -v 127.0.0.1 | awk '{print $2}'

 

[rastographics]

This may be helpful for others who are using DDEV inside of WSL2 on Windows...

Although Mutagen fixed the page loading problem, it introduced a (lesser) problem of creating a delay between when code is changed and when the change is picked up by the file system.

See my post below for the correct solution to both problems.

Do yourself a favor and Enable Mutagen!

I did not enable Mutagen because the DDEV docs say it doesn't make a difference when using WSL2. 

IT MADE A HUGE DIFFERENCE for me. Every page request was about 1 to 2 seconds before. After mutagen, it's about 200ms.

Edited February 14, 2023 by rastographics
new information

[MarkE]

22 hours ago, rastographics said:

Do yourself a favor and Enable Mutagen!

I stopped doing that a while back because it was taking longer to recognise code changes. But it may have been down to some problems I was having with PHPStorm, so I’ll try again now those problems seem to be fixed ?. Thanks for the nudge. 

[rastographics]

20 hours ago, MarkE said:

I stopped doing that a while back because it was taking longer to recognise code changes. But it may have been down to some problems I was having with PHPStorm, so I’ll try again now those problems seem to be fixed ?. Thanks for the nudge. 

You are correct. I didn't realize it until I went back in to work on my code, that there is a delay about 1-2 seconds to recognize code changes. (I'm using VS Code). So it is not without a downside.

However, since browsing the site is now practically instant, it more than makes up for it for me, as opposed to 1-2 seconds per page load (in my case) which really adds up especially navigating around the backend. 

I wish I could find a way to realize instant page loads (~200ms) without enabling mutagen, to get the best of both worlds. But I can't find an answer yet. (I have Xdebug disabled btw)

To be clear, I believe the underlying issue is with the WSL2 filesystem and/or DDEV and docker. This is NOT a processwire issue.

The next thing I might try is to open my project completely from the WSL2 environment and see if that can give me the same great performance instead of mutagen.

[MarkE]

8 hours ago, rastographics said:

The next thing I might try is to open my project completely from the WSL2 environment and see if that can give me the same great performance instead of mutagen.

I now have my project files in the WSL2 environment and that does seem to improve things without mutagen. I also tried running PhpStorm in WSL2 but it was a bit of a pain and no quicker. 

[gebeer]

11 hours ago, rastographics said:

The next thing I might try is to open my project completely from the WSL2 environment and see if that can give me the same great performance instead of mutagen.

This might be helpful: https://korepov.pro/infobase/vs-code/23 Haven't tried it myself but looks promising.

[rastographics]

13 hours ago, gebeer said:

This might be helpful: https://korepov.pro/infobase/vs-code/23 Haven't tried it myself but looks promising.

That's exactly what I was looking to do. That's a good tutorial for it. I'll report back with my findings hopefully soon.

[rastographics]

Bummer, I opened the project through Remote Explorer in vs code. I went to "WSL Targets" and the little "Open new folder" icon, and opened my project remotely in the WSL environment.

Unfortunately, it did not give the same 200ms response time as what I would call "native". (Using mutagen, or laragon on local file system, etc). It was *better* than non-mutagen ddev response from windows environment. About 1 second, compared to 2 seconds on windows. But still slow enough to aggravate me. :)

I really had expected a better result when working in the WSL2 filesystem directly. 

[bernhard]

12 minutes ago, rastographics said:

About 1 second, compared to 2 seconds on windows.

1 second is really too slow in my opinion. I can't remember exactly, but when I was on windows back then I'm quite sure the load times have been instant (around 100ms)...

Did you see this video? From what I can see it's blazing fast on Windows + WSL2! Even with Typo3 (https://youtu.be/ZMfHaUkhfc0?t=1881)

 

[rastographics]

Thanks for all of your input! The video @bernhard shared confirmed what I suspected I was missing...you can't just open VS code from within the WSL2 environment....you need to make sure your project files all live INSIDE the file system on WSL2. So that means do NOT leave them in /mnt/c/your/windows/file/path, but move them to /home/username/your/linux/file/path.

NOW it's the best of both worlds! :) Blazing Fast, with no mutagen and no delays after changing code.

The downside is your project files don't live on windows file system anymore. But I found you can still access easily from File Explorer by using \\wsl.localhost\Ubuntu or use the Linux shortcut on the navigation pane:

Do not open your project from the "Windows" location (open from within WSL). But many times I need to access this location through windows to copy/paste files of assets and other things I download or create on the windows side.

[bernhard]

Great to hear that @rastographics ? I think every second invested in getting DDEV to run properly is well worth it! I could not be happier with my dev setup and I hope you will be too ? 

38 minutes ago, rastographics said:

Blazing Fast, with no mutagen and no delays after changing code.

Just curious: What does that mean in ms per pageload in the tracy debug bar?

[rastographics]

33 minutes ago, bernhard said:

Just curious: What does that mean in ms per pageload in the tracy debug bar?

I'm guessing the total boot is what is considered pageload?

[bernhard]

I'm always looking at this number:

[rastographics]

Oh cool how did I miss that? 

It ranges from 35 to 50 ms on both backend and frontend pages. (Just started project so not a lot of complexity going on yet)

[bernhard]

I've recently bought a new Mac and had to setup ddev on my own the very first time ? Everything went smoothly, but I switched from docker desktop to colima as recommended in the docs and have one tip I want to share:

Colima is more lightweight than docker desktop but has one drawback, which - with my idea - is actually now also a benefit in my opinion ?

The problem is that there is no easy way to start colima automatically on startup. There are options but I found them a little complicated (maybe because I'm a mac noob). My solution is very simple:

I've just added "colima start" to my ddev alias that I use to start any ddev project anyhow. So there's no extra steps needed and if colima is already running, that I just get a message that it is already running. Nice. That also has the benefit that I start colima only when I need it and otherwise it will not need any resources.

Here are the aliases that I'm using:

# ddev aliases
alias ddc='ddev config --php-version "8.1" --webserver-type "apache-fpm"'
alias ddcm='ddev config --php-version "8.1" --database "mysql:8.0" --webserver-type "apache-fpm"'
alias dds='ddev ssh'
#alias dd='ddev start && ddev launch && ddev auth ssh -d ~/.ssh/ddev'
alias dd='colima start && ddev start && ddev launch && ddev auth ssh'
alias ddm='ddev launch -m' # launch mailhog
alias ddp='ddev poweroff'

 

[bernhard]

alias time again

I'm so used to using the list-long (double-L) command that I'm always using it within my ddev web containers as well.

It wouldn't be ddev if they had no solution for that ? Here's the docs: https://ddev.readthedocs.io/en/latest/users/extend/in-container-configuration/

Or just go to your host computers home directory, there you'll find the file ~/.ddev/homeadditions/bash_aliases.example --> rename that to .bash_aliases and you'll have those aliases in all your ddev webcontainers as well ?

Update: I'm using this alias now:

alias dds='ddev ssh && alias ll="ls -alh"'

 

[bernhard]

FYI RockMigrations has a nice helper for using xdebug on ddev: 

 

[bernhard]

Another reason for using an alias to create your ddev projects:

I just realised that the timezone in my project was not correct so $page->modified times where 2hours off. Simple to fix:

ddev config --timezone=Europe/Vienna

To not forget it for the next project here's my current alias:

alias ddc='ddev config --php-version "8.1" --database "mariadb:10.6" --webserver-type "apache-fpm" --timezone=Europe/Vienna'

 

[netcarver]

If you don't use phpmyadmin, simply relying on Adminer as part of Tracy Debugger on your sites, you can use the `--omit-containers=dba` flag as well to remove that container from your setup...

alias ddpw='ddev config --php-version=8.1 --database=mysql:8.0 --webserver-type=apache-fpm --omit-containers=dba --timezone=UTC'

You can also install adminer in it's own container if you prefer to run that beside your PW container...

alias ddmore='ddev get ddev/ddev-adminer && ddev restart && ddev describe'

 

[bernhard]

Nice, thx! Never needed it indeed ? Added to my alias ? 

[gmclelland]

In case anyone runs into the same issue...  After I upgraded Docker Desktop for Mac to the latest version, I started getting errors in DDEV on all of my DDEV projects.

@rfay from DDEV - pointed me to the fix at https://github.com/docker/for-mac/issues/6677 

Error response from daemon: Ports are not available: exposing port TCP 127.0.0.1:443 -> 0.0.0.0:0: failed to connect to /var/run/com.docker.vmnetd.sock: is vmnetd running?

The fix for me was to run these two commands:

1. /Applications/Docker.app/Contents/MacOS/install remove-vmnetd
2. sudo /Applications/Docker.app/Contents/MacOS/install vmnetd