P
imvdmolen.nl
Blog

Waarom ik Laravel Herd's custom PHP configuraties instel voor verschillende projecttypes

Toen ik vorig jaar drie verschillende Laravel-projecten tegelijkertijd draaide op mijn lokale machine, merkte ik dat ze elk hun eigen PHP-instellingen nodig hadden. Het ene project verwerkte grote CSV-bestanden en had meer geheugen nodig, het andere maakte gebruik van specifieke extensies voor image processing, en het derde draaide op een oudere PHP-versie vanwege legacy-afhankelijkheden. Laravel Herd heeft dit probleem voor mij opgelost door project-specifieke PHP-configuraties mogelijk te maken. In plaats van constant mijn globale php.ini te moeten aanpassen, kan ik nu per project de juiste instellingen activeren met een paar klikken.

Project-specifieke geheugen en tijdlimieten configureren

Elk project dat ik ontwikkel heeft andere resource-vereisten. Voor een e-commerce platform waar ik regelmatig productcatalogi moet importeren, heb ik een aparte PHP-configuratie aangemaakt met verhoogde memory limits en execution times. Het standaard geheugengebruik van 128MB is vaak te weinig als je duizenden producten moet verwerken, vooral wanneer je afbeeldingen moet resizen of complexe validaties moet uitvoeren.

Door in Laravel Herd een nieuwe PHP-configuratie aan te maken voor dit specifieke project, kan ik de memory_limit naar 512MB zetten en max_execution_time naar 300 seconden. Dit doe ik door in de Herd-interface naar de PHP-instellingen te navigeren en een nieuwe configuratie te creëren die ik "E-commerce Import" noem. De configuratie bevat aangepaste waardes voor alle resources die dit project nodig heeft.

// In mijn import command kan ik nu grote datasets verwerken zonder timeouts
<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

class ImportProductsCommand extends Command
{
    protected $signature = 'import:products {file}';
    
    public function handle()
    {
        $file = $this->argument('file');
        $products = collect(array_map('str_getcsv', file($file)));
        
        $products->chunk(100)->each(function ($chunk) {
            foreach ($chunk as $productData) {
                // Complexe validatie en image processing
                $this->processProduct($productData);
            }
        });
    }
    
    private function processProduct($data)
    {
        // Image resizing en database operations
        // Dankzij verhoogde memory limits geen problemen
    }
}

Het mooie van deze aanpak is dat ik tussen projecten kan switchen zonder dat ik handmatig configuratiebestanden hoef aan te passen. Als ik van het e-commerce project naar een lightweight API switch, kan ik direct een andere PHP-configuratie selecteren die geoptimaliseerd is voor snelle responses en lager geheugenverbruik.

Extensies per project inschakelen

Verschillende projecten hebben verschillende PHP-extensies nodig, en het constant in- en uitschakelen van extensies in een globale configuratie is omslachtig en foutgevoelig. Voor een project waarbij ik veel moet werken met afbeeldingen schakel ik GD en ImageMagick in, terwijl voor een API-project Redis en cURL belangrijker zijn. Laravel Herd laat me per configuratie exact specificeren welke extensies actief moeten zijn.

Vorige maand werkte ik aan een applicatie die QR-codes moest genereren en PDF's moest manipuleren. Voor dit project heb ik een configuratie gemaakt waarin ik specifiek de GD-extensie, de PDF-extensies en enkele andere grafische libraries heb ingeschakeld. Door deze extensies alleen voor dit project te activeren, houd ik mijn andere ontwikkelomgevingen lean en snel.

// Dit werkt alleen omdat ik de juiste extensies heb ingeschakeld voor dit project
<?php

namespace App\Services;

use Endroid\QrCode\QrCode;
use setasign\Fpdi\Fpdi;

class DocumentService
{
    public function generateQrCodePdf($data, $templatePath)
    {
        // QR-code genereren met GD-extensie
        $qrCode = new QrCode($data);
        $qrCode->setSize(200);
        $qrImage = $qrCode->writeString();
        
        // PDF manipuleren met FPDI
        $pdf = new Fpdi();
        $pdf->AddPage();
        $pdf->setSourceFile($templatePath);
        $template = $pdf->importPage(1);
        $pdf->useTemplate($template);
        
        return $pdf->Output('S');
    }
}

Door per project te bepalen welke extensies ik nodig heb, vermijd ik ook potentiële conflicten tussen verschillende PHP-modules. Sommige extensies kunnen elkaar in de weg zitten of onverwachte side-effects hebben wanneer ze tegelijkertijd actief zijn. Met project-specifieke configuraties kan ik deze problemen voorkomen.

PHP-versies per client vereisten instellen

Een van de meest frustrerende aspecten van het werken aan meerdere projecten tegelijk is dat ze vaak verschillende PHP-versionen vereisen. Legacy-projecten draaien soms nog op PHP 7.4, nieuwe projecten starten met PHP 8.2, en sommige clients hebben specifieke versie-vereisten vanwege hun hosting-omgeving. Laravel Herd maakt het mogelijk om per site een andere PHP-versie te draaien zonder dat ik constant moet switchen of aparte ontwikkelomgevingen moet opzetten.

Voor een client die zijn applicatie moet draaien op een server met PHP 8.0 vanwege interne beperkingen, heb ik een aparte Herd-configuratie gemaakt die exact PHP 8.0 draait met de juiste extensies en instellingen. Dit voorkomt dat ik tijdens ontwikkeling tegen syntax of functionaliteit aanloop die wel werkt op mijn standaard PHP 8.2-omgeving maar faalt op de productieserver.

// Code die anders werkt op verschillende PHP-versies
<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class ApiController extends Controller
{
    public function process(Request $request)
    {
        // Match expressions werken alleen in PHP 8.0+
        $result = match($request->input('type')) {
            'user' => $this->processUser($request),
            'order' => $this->processOrder($request),
            default => $this->processDefault($request)
        };
        
        // Named arguments zijn anders in verschillende PHP versies
        return response()->json(
            data: $result,
            status: 200
        );
    }
}

Naast versieverschillen zorgen verschillende PHP-configuraties er ook voor dat ik kan testen hoe mijn applicatie zich gedraagt onder verschillende omstandigheden. Door een configuratie te maken die striktere error reporting heeft, kan ik potentiële problemen eerder ontdekken. Een andere configuratie met lagere resource limits helpt me om bottlenecks te identificeren die pas opvallen onder productieomstandigheden.

Development workflow optimaliseren met configuratieprofielen

Het echt krachtige van Laravel Herd's configuratiemogelijkheden wordt duidelijk wanneer je ze integreert in je dagelijkse workflow. Ik heb verschillende profielen gemaakt die ik kan activeren afhankelijk van wat ik aan het doen ben: een "Debug" profiel met verbose logging en xDebug, een "Performance" profiel met OPcache optimalisaties, en een "Testing" profiel dat lijkt op de productieomgeving.

Het Debug-profiel schakel ik in wanneer ik complexe bugs moet oplossen of nieuwe functionaliteit ontwikkel. Dit profiel heeft xDebug ingeschakeld, verhoogde error reporting, en specifieke ini-instellingen die het debuggen vergemakkelijken. Het Performance-profiel daarentegen heeft alle debug-opties uitgeschakeld en OPcache geoptimaliseerd voor snelheid, zodat ik kan testen hoe snel mijn code werkelijk draait.

# Mijn .env voor verschillende profielen
# Debug profiel
XDEBUG_MODE=develop,debug,coverage
LOG_LEVEL=debug
APP_DEBUG=true

# Performance profiel  
XDEBUG_MODE=off
LOG_LEVEL=warning
APP_DEBUG=false

Door deze profielen te combineren met Herd's mogelijkheid om snel tussen sites te switchen, kan ik in een paar seconden van debugging naar performance testing schakelen. Dit bespaart me enorm veel tijd vergeleken met het handmatig aanpassen van configuratiebestanden of het herstarten van services.

Het resultaat is dat mijn lokale ontwikkelomgeving nu flexibel genoeg is om alle verschillende projecten te ondersteunen zonder dat ik compromissen hoef te sluiten. Elk project krijgt precies de PHP-omgeving die het nodig heeft, en ik kan me focussen op het bouwen van goede code in plaats van het worstelen met configuraties.