Als je de ontwikkelingssnelheid wilt verdubbelen tijdens het gebruik van Xdebug, dan leer je 't hier.

Xdebug

Huidige problematiek

Lokaal ontwikkelen wij in een Docker omgeving. Standaard maken we gebruik van custom geoptimaliseerde NGINX, PHP & MySQL containers. Dit wordt meestal nog uitgebreid met specifieke containers afhankelijk van het project.

Het gebruik van Xdebug is zeer handig bij de ontwikkeling. Al onze lokale PHP containers hebben deze module dan ook standaard aan staan.
Het grote nadeel is dat dit zeer resource-heavy is en de laadtijd van je pagina dus ook redelijk vertraagt, zelfs als je de debugger niet hebt ingeschakeld in PHPStorm, wat toch het merendeel van de tijd is.

Betere benadering

In een ideaal scenario laden we de Xdebug module enkel wanneer we deze nodig hebben, en dus niet voor alle andere requests naar de applicatie.

Een oplossing hiervoor bestaat erin om 2 PHP containers te gebruiken. 1 mét en 1 zonder de Xdebug module ingeschakeld. Zo kunnen we gebruik maken van de 'snellere' php container als we Xdebug niet nodig hebben en schakelen we over op de PHP Xdebug container als we effectief willen debuggen.

Door gebruik te maken van een cookie kunnen we via NGINX aangeven welke PHP container we wensen te gebruiken.

Gebruik 2 PHP containers

We maken naast onze standaard PHP container met naam php een nieuwe container aan met de naam php-dev. Beide containers laden verschillende Docker images in, namelijk:

  • php container maakt gebruik van een PHP Docker image zonder Xdebug
  • php-dev container gebruikt een PHP Docker image mét de Xdebug module ingeschakeld

Voorbeeld

services:
  php:
    image: some.docker.hub/php:7.3-fpm
  php-dev:
    image: some.docker.hub/php:7.3-fpm-dev

Configureer NGINX

De magic vindt plaats in NGINX. In onze configuratie luisteren we naar het al dan niet geplaatst zijn van een cookie.
Indien dit het geval is, dan kunnen we onze php-dev container aanspreken, zoniet sturen we de request naar onze default php container zonder Xdebug.

Volgende snippet plaats je bovenaan in je nginx configuratiefile. Dit zet een $domainService variabele met als standaardwaarde php, dit is meteen ook de hostname van onze PHP container. Van zodra een cookie met waarde XDEBUG_ wordt aangetroffen, zal $domainService de waarde php-dev krijgen, de hostname van onze Xdebug PHP container.

map $http_cookie $domainService {
  default php;
  "~*XDEBUG_" php-dev;
}

In onze vorige configuraties gaven we een standaard adres mee voor onze FastCGI server, namelijk php (de hostname van onze container).

fastcgi_pass php:9000;

In de nieuwe situatie veranderen we dit door onze $domainService variabele.

fastcgi_pass $domainService:9000;

 

Apache blijft niet in de kou staan

Mocht je om een bepaalde reden een applicatie hebben die gebruik maakt van Apache (requirements, Shibboleth, ...) is deze oplossing ook een mogelijkheid.

Binnen je <VirtualHost> tag voeg je het volgende toe

<FilesMatch \.php$>
    # Redirect to php-dev container with Xdebug loaded
    <If "%{HTTP_COOKIE} =~ /XDEBUG_/">
        SetHandler proxy:fcgi://php-dev:9000
    </If>
    <Else>
        SetHandler proxy:fcgi://php:9000
    </Else>
</FilesMatch>

 

Xdebug helper browser plugin

Installeer browser plugin

Eerst installeer je de Xdebug helper plugin in Chrome en/of Firefox.

Via de instellingen van de plugin voeg je een custom ide key toe, in ons geval "XDEBUG_".

Belangrijke noot

Als je wisselt in je browser tussen debuggen en niet-debuggen zal je nu ook steeds een andere sessie krijgen, aangezien er een andere container wordt aangesproken.

Indien je dus iets moet debuggen achter authentication, dien je eerst de xdebug helper in te schakelen in de browser. Nu heb je een nieuwe sessie waarin je je kan aanmelden.

Conclusie

Door gebruik te maken van deze implementatie laden onze pagina's meer dan dubbel zo snel in als we niet aan het debuggen zijn, wat voor een aanzienlijke tijdswinst zorgt. We hebben zo het beste van beide werelden, Xdebug als het nodig is en snelle responsetijden tijdens ontwikkeling.

Nood aan PHP experts? Wij zijn de PHP experts van België. 

Auteur: Wouter Aerts
Senior PHP developer
Wouter Aerts

More insights

Cross-platform applicaties met React Native

Nog nooit was het ontwikkelen van native mobiele applicaties zo toegankelijk als vandaag. Bij Codana doen we dit door gebruik te maken het React Native, een open-source framework dat werd ontwikkeld door Meta.

Auteur: Jinse Camps
Architect | Analyst
Jinse Camps
dev

Laracon EU 2024

Een fantastisch leerrijke ervaring om met een hoop Laravel gepassioneerde mensen te inspireren! Iets wat niet gemist kan worden en heel veel voeling geeft met de community. Wat een top evenement! Wie zien we volgende edities? 😮

Auteur: Noah Gillard
PHP / Laravel Developer
Noah Gillard AI generated Face
laracon codana persoon

Een efficiënt datamanagementsysteem voor toerisme

Een TDMS of Tourist Data Management System, is simpelweg een platform dat data uit verschillende bronnen ophaalt, intern al dan niet automatisch verwerkt en deze gegevens terug aanbiedt aan externe platformen.

Auteur: Tom Van den Eynden
Web Architect | Coordinator
Tom Van den Eynden
laptop

Systemen voor gegevensbeheer in toerisme

In dit artikel verkennen we wat een TDMS is, waarom het essentieel is voor de toerisme-industrie, en hoe technologieën zoals Laravel en ElasticSearch het verschil kunnen maken. 

Auteur: Tom Van den Eynden
Web Architect | Coordinator
Tom Van den Eynden
tdms

Beveiliging van Laravel 101

In deze blogpost gaan we dieper in op een aantal veelvoorkomende Laravel beveiligingsfouten.

Auteur: Robbe Reygel
PHP developer
laravel

Test Driven Development - toepassing op een project

TDD, of voluit Test Driven Development, is een aanpak van ontwikkeling waarbij we vertrekken van het schrijven van tests. 

Auteur: Sarah Jehin
PHP developer
Sarah Jehin
development