Ubuntu 20.04, WSL2, VSCode og Drupal 8 - Fastsættelse af Gotchas

Microsoft har endelig leveret en fantastisk løsning til udvikling af Linux-applikationer på Windows.  Windows Subsystem til Linux, WSL2, er ret let at installere og komme i gang, især hvis du allerede er fortrolig med Linux.  Selvom du ikke er der, er der mange meget gode artikler om at få en grundlæggende installation i gang.

Udvikling af Linux PHP-applikationer ved hjælp af VSCode på Windows 10 er omtrent så stabil og problemfri en oplevelse, man kan få. Stadig flere "gotchas", jeg stødte på, blev ikke beskrevet i nogen af ​​de artikler, jeg fandt om opsætning af LAMP på Ubuntu og WSL2.

Jeg havde begrænset erfaring med Linux og var meget afhængig af artikler skrevet af dem, der kom foran mig.  Mens de fik mig det meste af vejen der, stødte jeg på flere problemer med at få Drupal 8 til at køre uden fejl og fejlfinding ved at arbejde i VSCode.  Løsningerne blev fundet i kommentarerne i spørgsmål, der blev offentliggjort på internettet. Dette tog mange timers søgning, og jeg håber at redde folk ved at præsentere de løsninger, jeg fandt i denne ene artikel.

Mit miljø er Windows 10 20H2, Ubuntu 20.04, PHP 7.3, MariaDB 10.4.17, Drupal 8.9.13, Xdebug 3.02, Windows Terminal, VSCode med Remote - WSL og PHP Debug af Felix Becker-pakker.  Jeg kører WSL fra Powershell i Windows Terminal.

Før vi kommer i gang, er der et par anbefalinger, der kan spare dig tid.

Installation og brug af apt-fast i stedet for apt kan virkelig fremskynde installationer og opdateringer.  Hvor jeg bor, er Internettet lav båndbredde og langsom, og apt-fast er meget hurtigere end apt.

Du kan "sikkerhedskopiere og gendanne" din Linux-distribution ved hjælp af WSL Export and Import. Som med ethvert system tilrådes det altid at opretholde en aktuel sikkerhedskopi.

Mariadb installerer fint, men kan ikke genstarte eller få status

Mariadb-installationen gik fint.  Ingen fejl eller advarsler.  Da jeg forsøgte at kontrollere status, fik jeg en fejl angående systemet.

$> systemctl status mysql
Systemet er ikke startet med systemd som init-system (PID 1). Kan ikke fungere.

Årsagen til denne fejl er, at Microsoft ikke understøtter systemd i WSL.  Heldigvis oprettede Arkane Systems en pakke systemgenie for at aktivere systemd .  Jeg foreslår, at du læser deres webside grundigt, inden du prøver følgende instruktioner, som blev taget fra siden. Der er lidt forskellige instruktioner til andre distributioner end Ubuntu.

Først skal du installere .Net 5.0 runtime

$> sudo apt-hurtig opdatering
$> sudo sudo apt-hurtig installation -y apt-transport-https
$> sudo apt-hurtig opdatering
$> sudo apt-hurtig installation -y dotnet-sdk-5.0

Dernæst skal vi konfigurere wsl-transdebian Repository

$> sudo apt-hurtig installation apt-transport-https
$> wget -O / etc / apt / betroet.gpg.d / wsl-transdebian.gpg https: // arkane-systems.github.io / wsl-transdebian / apt / wsl-transdebian.gpg
$> chmod a + r / etc / apt / betroet.gpg.d / wsl-transdebian.gpg
$> kat << EOF > / etc / apt / sources.liste.d / wsl-transdebian.liste
$> deb https: // arkane-systems.github.io / wsl-transdebian / apt / bullseye main
$> deb-src https: // arkane-systems.github.io / wsl-transdebian / apt / bullseye main
$> apt-hurtig opdatering

Nu kan vi installere systemgenie-pakken.

sudo apt-hurtig installation -y systemd-genie

Afslut din Linux-shell, og luk derefter WSL fra Power shell

PS C: \ Brugere \ Usrnavn> wsl - nedlukning

Genstart WSL med en genie fra Powershell-prompten.

PS C: \ Brugere \ Usrnavn> wsl genie --s

Du vil se "Venter på systemd .. .!!!!!!!!!!!!!!!”.  Det tager 180 sekunder at indlæse helt.  Vent bare til det er færdigt.  Når det er gjort, skal dit nye skalvindue se sådan ud:

Venter på systemd .. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Tidsudløb ventede på, at systemd skulle gå i kørende tilstand.
Dette kan indikere en systemd konfigurationsfejl.
Forsøger at fortsætte.

Bekræft, at genie er installeret, og systemd fungerer:

systemctl status mariadb

Du skal få statusoutput for mariadb.  Bemærk, at systemctl status mysql også fungerer.

Arkane Systems anbefaler at lukke din WSL-geniesession med wsl-shutdown.  Dette frigør al hukommelse, der bruges af WSL i Windows.

Drupal installerer men ingen CSS bliver indlæst

Efter at have kørt den grundlæggende installation til Drupal 8, havde siderne ingen formatering.  Visning af sidekilde viste, at der ikke blev indlæst nogen CSS-filer. Det tog mig to dage at finde ud af denne, men novellen er, at Drupal antager, at apache2 bruger / tmp-biblioteket, men det er det ikke.  Som standard er apache2 konfigureret til at bruge et privat tmp-bibliotek.  Mærkeligt nok kald, sys_get_temp_dir () fra php return / tmp, men alligevel er det ikke, hvad apache2 bruger.  Når Drupal opretter sine optimerede css- og js-filer, prøver den først at skrive dem til / tmp-mappen og flytter dem derefter til destinationsmappen, typisk sites / default / files / css og / js. Men apache2 bruger ikke / tmp, så denne proces mislykkes, og ingen af ​​css- eller js-filerne. Fjernelse af markering af samlede CSS- og Javascript-filer vil omgå dette, men så indlæses alle de individuelle css- og js-filer, så dette er ikke en løsning.

Du kan bekræfte dette problem / tmp ikke er tilgængelig med følgende enkle php-fil. Det opretter en tmpfile og viser filnavnet.  Oprindeligt vil filnavnet være tomt, fordi opkaldet til tmpfile () returnerer NULL.  Jeg sætter følgende kode på prøve.php og kaldte det fra mit websted, localhost / mysite / test.php

ekko "\ n ";
ekko "\ n ";
ekko "\ n ";
ekko "\ n ";
ekko "\ n ";
ekko "

Hvis du ser sidekilden \ r \ n, finder du en ny linje i denne streng.";
 
ekko "

testning

";
$ tmpDir = sys_get_temp_dir ();
ekko "

TMP direcory = '$ tmpDir'

";
$ fil = tmpfile ();
$ sti = stream_get_meta_data ($ fil) ['uri'];
ekko "

Sti til tmp-fil = '$ sti'

";
 
ekko "\ n ";
ekko "\ n ";
?>
 
Dette resulterede i "Path of tmp file ="

Jeg fandt en løsning på dette i kommentarerne til Stackoverflow-spørgsmålet fra brugeren One In a Million Apps.  Denne løsning ændrer apache2-konfigurationen fra PrivateTmp = true til PrivateTmp = false. Bemærk, at ændring af apache2 til brug af et privat tmp-bibliotek blev udført af sikkerhedsmæssige årsager, og de fleste apps kan konfigureres til at bruge en anden tmp-mappe.  Jeg prøvede det med Drupal, men kunne ikke få det til at fungere. Dette er mit første forsøg på at køre Drupal på Linux, og jeg ville have ting til at "bare fungere" på min bærbare computer med lidt bekymring for sikkerhed.

Se først efter den fil, der indeholder PrivateTmp ved hjælp af dette fra / lib-biblioteket:

%> sudo find / -mount -type f -exec grep -e "PrivateTmp" '' ';' -Print

Dette gav mig en lang liste over kampe.  Se efter den, der indeholder filen apache2.service.  I mit tilfælde blev det fundet på / usr / lib / systemd / system / apache2.service.  kopier denne fil til / osv. vejviser. Rediger / etc / apache2.tjenester og skift PrivateTmp = true til PrivateTmp = false, gem og genstart apache2-tjenesten.

systemctl genstart apache2

Kør testen igen.php-side igen, og du skal få den navngivne tmp-fil vist, hvilket bekræfter adgang til / tmp-mappen.

Ryd alle Drupal-cacher, og genindlæs siderne.  De skal nu vises korrekt. Jeg ved ikke hvorfor, men funktionen Drupal Clear Cache fungerer ikke altid for mig.  Manuelt sletning af alle filer på websteder / standard / filer / css js, derefter bruger PhpMyAdmin til at tømme cachetabellerne altid.

Opsætning af VSCode-fejlfinding

Konfigurer Xdebug

Først skal du installere Remote - WSL og PHP Debug af Felix Becker-pakker til VSCode.

Jeg installerede derefter Xdebug

sudo apt-hurtig php7.3-xdebug

Denne installerede version 3.02 af Xdebug.

Jeg forsøgte at konfigurere det ved at følge de mange eksempler på internettet.  Intet fungerede.  Det viser sig, at de fleste eksempler er til Xdebug 2.x, og disse konfigurationsindstillinger fungerer ikke længere med 3.x

Endelig fik jeg det til at arbejde med følgende php.ini-indstillinger.

Jeg var nødt til at tilføje følgende til begge / etc / php / 7.3 / apache2 / php.ini og / etc / php / 7.3 / cli / php.ini på mit system.

Du kan finde placeringen af ​​din xdebug.så ved at flytte til / lib-katalogfilen og derefter køre

find-navn xdebug.så [xdebug]
zend_extension = ./ lib / php / 20180731 / xdebug.så
xdebug.start_with_request = trigger
xdebug.mode = fejlretning
xdebug.discover_client_host = 1
xdebug.log = / tmp / xdebug_remote.log
xdebug.klientport = 9003

Konfigurer VSCode

Fjernfejlfinding i VSCode bruger en lancering.json-fil gemt i roden til dit projektmappe i .vscode / lancering.json.

Du kan oprette lanceringen.json-fil gennem VSCode UI, men jeg finder det lettere at oprette den manuelt.  Gå til roden på dit websted, og opret en .vscode-bibliotek. Opret en lancering.json-fil og indlæse den i VSCode.

$> mkdir .vscode
$> cd .vscode
$> tryk på lancering.json
$> kode start.json

Læg følgende json i filen, og gem den.

// Brug IntelliSense til at lære om mulige attributter.
// Hold markøren for at se beskrivelser af eksisterende attributter.
// For mere information, besøg: https: // go.Microsoft.com / fwlink /?linkid = 830387
"version": "0.2.0 ",
"konfigurationer": [

"name": "Lyt efter XDebug",
"type": "php",
"anmodning": "start",
"port": 9003,
"stopOnEntry": sandt,
"log": sandt,
"pathMappings":

"/ var / www / html": "$ workspaceRoot"

,

"name": "Start aktuelt åbent script",
"type": "php",
"anmodning": "start",
"program": "$ file",
"cwd": "$ fileDirname",
"port": 9003

]

Bemærk under pathMappings, hvor jeg har “/ var / www / html”, skal du lægge den fulde sti til roden på dit websted.

Luk VSCode. I din WSL Linux-prompt gå tilbage til roden på dit websted og indlæse projektet i VSCode.  Forudsat at du stadig er i .vscode-bibliotek,

$> cd ..
$> kode .

Dette skal indlæse projektet i VSCode, og du skal se det fulde katalogtræ for dit projekt til venstre.  Åbn din startside, f.eks. Indeks.php, og tilføj et brudpunkt.  Tryk på F5 for at starte fejlretning.  Gå til en webbrowser og indlæs webstedet. Skift tilbage til VSCode, og du skal se det stoppet ved dit brudpunkt.

Koden kører ikke med zsh Shell

Som standard er WSL indstillet til at arbejde med Bash-skallen, og den ser stien til VSCode-eksekverbar i PATH.  Jeg skiftede til zsh, og VSCode kørte ikke længere.  Løsningen var at sætte et alias ind .zshrc

$> cd ~
$> kode .zshrc

Tilføj følgende alias, der peger på den fulde sti til koden, der køres, som vist af Ubuntu i WSL.  Udskift dit brugernavn med dit aktuelle Windows-brugernavn.

alias-kode = "/ mnt / c / Brugere / Dit brugernavn / AppData / Lokalt / Programmer / Microsoft \ VS \ Kode / bin / kode"

Du skal nu genindlæse zsh-konfigurationen med

$> kilde .zshrc

Koden skal nu indlæses fra zsh shell.

Det er det!!  Disse trin fik endelig Drupal og VSCode-fejlfinding til at fungere korrekt for mig.  Det tog mig to dage at finde ud af det hele. Jeg er en noob! Forhåbentlig fungerer dette for dig og sparer dig noget tid.

Bare en påmindelse om mit miljø.  Windows 10 20H2, Ubuntu 20.04, PHP 7.3, MariaDB 10.4.17, Drupal 8.9.13, Xdebug 3.02, Windows Terminal, VSCode med Remote - WSL og PHP Debug af Felix Becker-pakker.

Glad kodning!