DDEV

Du hast ein prähistorisch Projekt mit PHP 7.3 und es wird hirnrissigerweise MongoDB in einer ebenso alten Version benutzt? Und das Ganze soll nicht geupdated werden aber unter DDEV laufen?

Nichts einfacher als das:

❯ cat .ddev/config.yaml
[...]
webimage_extra_packages: [php7.3-mongodb]
[...]

---

Und nun möchtest Du einen MongoDB Dump einspielen, den Du zuvor mit mongodump erstellt hast? Fast genauso einfach. Im web Container gibt es natürlich keine mongodb-tools. Aber im mongo Container gibt es die natürlich. Also ein kleiner Umweg:

Das Verzeichnis mit dem Dump (bspw. ~/Sites/data) in den Mongo Container mounten:

❯ cat .ddev/docker-compose.mountdata.yaml
services:
  mongo:
    volumes:
    - type: "bind"
      source: "~/Sites/data"
      target: "/data"

/data ist der Pfad des gemounteten Verzeichnis im Container.

---

DDEV neu starten und mit SSH auf dem Mongo Container einloggen:

❯ ddev restart 
❯ ddev ssh --service=mongo

---

Die DB im Container importieren.

# cd data
# ls -l
drwxr-xr-x 1 root    root          320 Mar 28 15:26 dump
# mongorestore -u db -p db  --db db --authenticationDatabase admin -d db dump 

---

DSN in der .env etwa so:

❯ cat .env.local
[..]
MONGODB_URL=mongodb://db:db@mongo:27017
MONGODB_DB=db
[..]

Manchmal ist es praktisch oder auch unabdingbar, dass ein DDEV Projekt kurzeitig öffentlich erreichbar ist. Beispielsweise beim Testen von einigen Zahlungsanbietern, Webhooks oder einfach nur um das Projekt jemandem zu zeigen und zugänglich zu machen.

ddev share mit ngrok ist erfreulich einfach und schnell. Man benötigt einen kostenfreien Account bei ngrok und muss natürlich ngrok installieren. Unter macOs am einfachsten per homebrew:

brew install ngrok
ngrok config add-authtoken {dein token}

Und dann im laufenden DDEV Projekt:

ddev share --ngrok-args "--domain {deine subdomain}.ngrok-free.app"

Das ist alles.

Mach Dir Deine eigenen Gedanken, welche Art von Daten Du durch ngrok fließen lassen möchtest.

Manchmal habe ich das Gefühl, dass ich erst seit Gestern Computer benutze. Oder wie kann man so sehr auf der Leitung stehen.

Xdebug hat prinzipiell immer funktionert. Allerdings wurden nur Breakpoints in der public/index.php eines Projekts beachtet. Alle anderen wurden ignoriert. Und die Lösung liegt so sehr auf der Hand, wenn man nur fünf Minuten drüber nachdenkt. Das Mapping der lokalen Verzeichnisse auf jene im Container hat ganz einfach gefehlt.

Und das schlimmste: Bei jeder Debug Session, wird dick eine Meldung angezeigt, dass es im Projekt keine gemappten Verzeichnise gibt. Die Meldung (dick in rot) habe ich konsequent und erfolgreich ignoriert. Bis zuletzt als ich endlich mal drauf geklickt habe und ein Mapping auf oberste Ebene hinzugefügt habe.

Und zu allem Überfluß steht es auch noch groß und breit in der Dokumentation:

4 PhpStorm will ask you what mapping to use, so it can figure out how to map the path inside the container to the path on your workstation. The first time you do this with a project, PhpStorm will pop up a “server” dialog box to set the mapping. The default will work, but it’s best to click the checkbox to map the whole project directory to /var/www/html.

Naja, mein Mutagen Problemchen ist allerdings noch nicht gelöst. Da muss ich mal noch weiter schauen.

Bin ich eigentlich der Einzige, der von DDEV manchmal unglaublich genervt ist. Immer wieder stolpere ich über die beiden folgenden Probleme. Völlig egal, ob ich Colima oder OrbStack benutze.

• Irgendwann hört der Mutagen-Spaß auf zu synchronisieren oder die Synchronisation ist so langsam, dass effektiv keine Arbeit möglich ist. Obwohl in Anbetracht der ignorierten Verzeichnisse in der .ddev/mutagen/mutagen.yml nur eine Hand voll Dateien übrig bleiben, die überhaupt gesynct werden müssten.
• Xdebug beachtet grundsätzlich nur Breakpoints in der index.php eine Projekts. Alle anderen Breakpoints werden ignoriert.

Es ist zwar nervig den vollständigen Stack in den passenden Versionen lokal zu installieren. Aber arbeiten konnte ich damit immer sehr gut. Ich denke, ich will dahin zurück…