Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Route-Parameter und Constraints

Route-Parameter und Constraints

~13 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026

Um ein EINZELNES Projekt anzuzeigen, brauchen wir dynamische Teile in der URL – Route-Parameter. Dieses Kapitel behandelt sie systematisch, inklusive der Reihenfolge-Falle aus Kapitel 7.

Einfache Route-Parameter

src/Controller/ProjectController.php
#[Route('/projects/{id}', name: 'project_show', methods: ['GET'])]
public function show(int $id): Response
{
    return new Response(sprintf('Projekt-Details für ID %d', $id));
}

{id} im Pfad UND int $id als Parameter der Methode – Symfony gleicht den Namen des Platzhalters mit dem Namen des Methoden-Parameters ab und übergibt den Wert automatisch. Der PHP-Typ (int) wird dabei automatisch aus dem String-Wert der URL konvertiert.

Requirements: Route-Parameter einschränken

Ohne Einschränkung würde {id} JEDEN String matchen – auch /projects/abc, was zu einem Fehler führt, sobald PHP versucht, 'abc' zu int zu konvertieren. Mit requirements lässt sich das VOR dem Erreichen des Controllers einschränken:

#[Route('/projects/{id}', name: 'project_show', requirements: ['id' => '\d+'], methods: ['GET'])]
public function show(int $id): Response
{
    // ...
}

'\d+' ist ein regulärer Ausdruck: nur eine oder mehrere Ziffern. /projects/abc matcht diese Route jetzt NICHT mehr – Symfony sucht stattdessen nach einer ANDEREN passenden Route, oder liefert 404, falls keine existiert.

Die Reihenfolge-Falle aus Kapitel 7, jetzt gelöst

// RICHTIGE Reihenfolge: die spezifischere Route zuerst
#[Route('/projects/new', name: 'project_new', methods: ['GET', 'POST'])]
public function new(): Response { /* ... */ }

#[Route('/projects/{id}', name: 'project_show', requirements: ['id' => '\d+'], methods: ['GET'])]
public function show(int $id): Response { /* ... */ }

Mit requirements: ['id' => '\d+'] wäre die Reihenfolge hier TATSÄCHLICH egal geworden, da /projects/new gar nicht erst zum Zahlen-Muster passt – ein zusätzlicher Sicherheitsnetz-Effekt der Requirements, unabhängig von der Deklarationsreihenfolge.

Optionale Parameter mit Default-Werten

#[Route('/projects/{id}/tasks/{status}', name: 'project_tasks', requirements: ['id' => '\d+'])]
public function tasks(int $id, string $status = 'alle'): Response
{
    return new Response(sprintf('Aufgaben von Projekt %d, Status: %s', $id, $status));
}

Ein Default-Wert im Methoden-Parameter (string $status = 'alle') macht diesen Teil der URL implizit optional – /projects/1/tasks/ UND /projects/1/tasks/offen matchen beide dieselbe Route.

Mehrere HTTP-Methoden auf derselben Route

Für Formulare (Block 3) wird eine Route oft für ZWEI Zwecke gebraucht: das Formular ANZEIGEN (GET) und es NACH dem Absenden VERARBEITEN (POST) – beide auf DERSELBEN Route:

#[Route('/projects/new', name: 'project_new', methods: ['GET', 'POST'])]
public function new(Request $request): Response
{
    if ($request->isMethod('POST')) {
        // Formular verarbeiten (Kapitel 15)
    }

    // Formular anzeigen (Kapitel 15)
    return new Response('Neues Projekt anlegen');
}

Tipp: debug:router aus Kapitel 7 zeigt bei mehreren HTTP-Methoden pro Route diese kommagetrennt an – ein guter Weg, um zu prüfen, ob eine Route WIRKLICH für beide Methoden registriert wurde.