bg_image
header

PHP Data Objects - PDO

PDO steht für PHP Data Objects und ist eine Datenbank-Abstraktionsschicht in PHP. Es handelt sich um eine objektorientierte Schnittstelle, mit der du auf verschiedene Datenbanken zugreifen kannst – z. B. MySQL, PostgreSQL, SQLiteohne den Datenbankspezifischen Code stark ändern zu müssen.

Hauptmerkmale von PDO:

Einheitliche API:
Egal ob MySQL, SQLite oder PostgreSQL – du benutzt denselben Code-Stil.

Prepared Statements:
Sicherer Schutz vor SQL-Injektionen durch gebundene Parameter:

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);

Transaktionen:
PDO unterstützt Transaktionen (wichtig z. B. bei Bankbuchungen).

Fehlerbehandlung per Exception:

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Flexibler Datenbankwechsel:
Möchtest du von MySQL auf PostgreSQL wechseln? Meist nur der DSN-String und Treiber müssen geändert werden.

$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$user = 'root';
$pass = '';

try {
    $pdo = new PDO($dsn, $user, $pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Verbindung erfolgreich!";
} catch (PDOException $e) {
    echo "Verbindung fehlgeschlagen: " . $e->getMessage();
}

Fazit:

PDO ist der empfohlene Weg, um in modernen PHP-Anwendungen mit Datenbanken zu arbeiten – besonders wegen der Sicherheit und Flexibilität.


Doctrine Database Abstraction Layer - DBAL

Doctrine DBAL (Database Abstraction Layer) ist eine PHP-Bibliothek, die eine Abstraktionsschicht für den Datenbankzugriff bietet. Sie ist ein Teil von Doctrine, einem weit verbreiteten ORM-Projekt (Object-Relational Mapping), aber kann unabhängig vom ORM verwendet werden.

Ziel und Nutzen von Doctrine DBAL:

Doctrine DBAL bietet eine einheitliche API, um mit verschiedenen Datenbanken (wie MySQL, PostgreSQL, SQLite usw.) zu kommunizieren, ohne direkt SQL für die jeweilige Datenbank schreiben zu müssen.


Hauptfunktionen von Doctrine DBAL:

  • Verbindungsverwaltung:
    • Verbindungsaufbau zu Datenbanken über Konfigurationsarrays.

    • Unterstützung für Verbindungs-Pooling, Transaktionen usw.

  • SQL-Query-Builder:
    • Dynamisches Erstellen von SQL-Abfragen über eine objektorientierte API:

$qb = $conn->createQueryBuilder();
$qb->select('u.id', 'u.name')
   ->from('users', 'u')
   ->where('u.age > :age')
   ->setParameter('age', 18);
$stmt = $qb->executeQuery();
  • Datenbankunabhängigkeit:

    • Die gleichen Funktionen und Abfragen funktionieren mit verschiedenen DBMS, z. B. MySQL, PostgreSQL, SQLite.

  • Schema-Management:

    • Werkzeuge zum Erstellen, Ändern und Vergleichen von Datenbankschemata.

    • Nützlich für Migrationen.

  • Datentyp-Konvertierung:

    • Konvertiert Daten zwischen PHP und dem nativen Datenbankformat.

use Doctrine\DBAL\DriverManager;

$conn = DriverManager::getConnection([
    'dbname' => 'test',
    'user' => 'root',
    'password' => '',
    'host' => 'localhost',
    'driver' => 'pdo_mysql',
]);

$result = $conn->fetchAllAssociative('SELECT * FROM users');

Wann DBAL statt ORM?

Du verwendest DBAL ohne ORM, wenn:

  • Du mehr Kontrolle über SQL willst.

  • Dein Projekt keine komplexe Objekt-Mapping-Logik braucht.

  • Du bereits vorhandene SQL-Strukturen nutzen musst.


Fazit:

Doctrine DBAL ist ein mächtiges Werkzeug für sauberen, portablen und sicheren Datenbankzugriff in PHP, ohne sich auf ein vollständiges ORM einlassen zu müssen. Es liegt genau zwischen direktem PDO-Zugriff und einem vollwertigen ORM wie Doctrine ORM.

 


Whoops

Die PHP-Bibliothek Whoops ist ein leistungsstarkes und benutzerfreundliches Fehlermanagement-Tool für PHP-Anwendungen. Sie sorgt dafür, dass Fehler in einer ansprechenden und übersichtlichen Weise dargestellt werden, was die Fehlersuche und -behebung erleichtert.

Hauptfunktionen von Whoops

Schöne, interaktive Fehlerseiten
Detaillierte Stack-Traces mit Code-Vorschau
Einfache Integration in bestehende PHP-Projekte
Unterstützung für verschiedene Frameworks (Laravel, Symfony, Slim, etc.)
Anpassbar durch eigene Handler und Logger


Installation

Whoops kann mit Composer installiert werden:

composer require filp/whoops

Grundlegende Nutzung

Hier ist ein einfaches Beispiel, wie du Whoops in deinem PHP-Projekt aktivieren kannst:

require 'vendor/autoload.php';

use Whoops\Run;
use Whoops\Handler\PrettyPageHandler;

$whoops = new Run();
$whoops->pushHandler(new PrettyPageHandler());
$whoops->register();

// Erzeugt einen Fehler (z. B. eine nicht definierte Variable aufrufen)
echo $undefinedVariable;

Falls ein Fehler auftritt, zeigt Whoops eine übersichtliche Debug-Seite an.


Anpassung und Erweiterung

Du kannst Whoops auch erweitern, z. B. indem du eine eigene Fehlerbehandlung hinzufügst:

use Whoops\Handler\CallbackHandler;

$whoops->pushHandler(new CallbackHandler(function ($exception, $inspector, $run) {
    error_log($exception->getMessage());
}));

Diese Variante loggt Fehler in eine Datei, anstatt sie direkt anzuzeigen.


Einsatzgebiete

Whoops wird oft in Entwicklungsumgebungen verwendet, um schnell auf Fehler zu reagieren. In Produktionsumgebungen sollte es jedoch deaktiviert oder durch eine benutzerdefinierte Fehlerseite ersetzt werden.


Twig

Twig ist ein leistungsfähiges und flexibles Templating-System für PHP, das häufig in Symfony, aber auch in anderen PHP-Projekten verwendet wird. Es ermöglicht eine klare Trennung von Logik und Präsentation und bietet viele nützliche Features für die Frontend-Entwicklung.


Wichtige Merkmale von Twig

1. Einfache Syntax mit Platzhaltern ({{ }})

Twig verwendet doppelte geschweifte Klammern für die Ausgabe von Variablen:

<p>Hallo, {{ name }}!</p>

→ Wenn name = "Max" ist, wird ausgegeben:
"Hallo, Max!"


2. Steuerstrukturen ({% %})

Twig unterstützt if-else, Schleifen und andere Kontrollstrukturen:

If-Else

{% if user.isAdmin %}
    <p>Willkommen, Admin!</p>
{% else %}
    <p>Willkommen, Nutzer!</p>
{% endif %}

Schleifen (for)

<ul>
{% for user in users %}
    <li>{{ user.name }}</li>
{% endfor %}
</ul>

3. Template-Vererbung

Twig unterstützt das Konzept von "Base-Layouts", ähnlich wie Blade in Laravel.

Eltern-Template (base.html.twig)

<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}Meine Seite{% endblock %}</title>
</head>
<body>
    <header>{% block header %}Standard-Header{% endblock %}</header>
    <main>{% block content %}{% endblock %}</main>
</body>
</html>

Kind-Template (page.html.twig)

{% extends 'base.html.twig' %}

{% block title %}Startseite{% endblock %}

{% block content %}
    <p>Willkommen auf meiner Seite!</p>
{% endblock %}

→ Die Blöcke überschreiben die Standardinhalte des Basis-Templates.


4. Inkludieren von Templates

Man kann wiederverwendbare Teile wie Header oder Footer einbinden:

{% include 'partials/navbar.html.twig' %}

5. Filter & Funktionen

Twig enthält viele Filter, um Inhalte zu formatieren:

Filter Beispiel Ausgabe
upper `{{ "text" upper }}`
lower `{{ "TEXT" lower }}`
length `{{ "Hallo" length }}`
date `{{ "now" date("d.m.Y") }}`

6. Sicherheit & Escaping

Twig escapet HTML automatisch, um XSS-Angriffe zu verhindern:

{{ "<script>alert('XSS');</script>" }}

→ Gibt nur &lt;script&gt;alert('XSS');&lt;/script&gt; aus.

Möchtest du HTML ungefiltert ausgeben, nutze |raw:

{{ "<strong>Fett</strong>"|raw }}

7. Erweiterbarkeit

  • Twig unterstützt eigene Filter & Funktionen.
  • Man kann PHP-Objekte und Arrays direkt in Twig verwenden.

PSR-12

PSR-12 ist ein Standard der PHP-Fig (PHP Framework Interoperability Group), der Coding-Style-Guidelines für PHP definiert. Es baut auf PSR-1 (Basic Coding Standard) und PSR-2 (Coding Style Guide) auf und erweitert diese, um modernere Anforderungen und Best Practices zu berücksichtigen.

Ziel von PSR-12

PSR-12 zielt darauf ab, einen einheitlichen und lesbaren Code-Stil für PHP-Projekte zu schaffen. Dies erleichtert die Zusammenarbeit zwischen Entwicklern und sorgt für Konsistenz in der Codebasis.


Wichtige Richtlinien von PSR-12

1. Einrückung

  • 4 Leerzeichen werden für die Einrückung verwendet (keine Tabs).

2. Zeilenlänge

  • Die maximale Zeilenlänge sollte 120 Zeichen nicht überschreiten.
  • Code darf für bessere Lesbarkeit auf mehrere Zeilen umgebrochen werden.

3. Namespace und Use-Anweisungen

  • Nach der namespace-Deklaration muss eine Leerzeile stehen.
  • use-Anweisungen werden nach der namespace-Deklaration gruppiert.
  • Importierte Klassen, Funktionen und Konstanten sollten alphabetisch sortiert werden und keine Leerzeilen enthalten.
namespace App\Controller;

use App\Service\MyService;
use Psr\Log\LoggerInterface;

4. Klassen

  • Der Öffnungsblock { einer Klasse oder Methode steht in der nächsten Zeile.
  • Sichtbarkeiten (public, protected, private) sind bei allen Methoden und Eigenschaften zwingend erforderlich.
class MyClass
{
    private string $property;

    public function myMethod(): void
    {
        // code
    }
}

5. Methoden und Funktionen

  • Jeder Parameter einer Methode/Funktion muss auf einer neuen Zeile stehen, wenn sie umgebrochen wird.
  • Rückgabetypen sollten explizit angegeben werden.
public function myFunction(
    int $param1,
    string $param2
): string {
    return 'example';
}

6. Control Structures (if, while, for, etc.)

  • Der Öffnungsblock { muss in derselben Zeile wie die Kontrollstruktur stehen.
  • Zwischen der Kontrollstruktur und der Bedingung steht ein Leerzeichen.
if ($condition) {
    // code
} elseif ($otherCondition) {
    // code
} else {
    // code
}

7. Arrays

  • Arrays sollten im kurzen Syntax-Stil ([]) geschrieben werden.
  • Bei mehrzeiligen Arrays sollte jedes Element in einer neuen Zeile stehen.
$array = [
    'first' => 'value1',
    'second' => 'value2',
];

8. Typdeklarationen

  • Typen für Parameter, Rückgabewerte und Eigenschaften sind zwingend erforderlich (sofern möglich).
  • Nullbare Typen werden mit ? vor dem Typ deklariert.
public function getValue(?int $id): ?string
{
    return $id !== null ? (string) $id : null;
}

9. Dateien

  • PHP-Dateien müssen mit einem <?php-Tag beginnen und dürfen kein schließendes ?>-Tag enthalten.
  • Zwischen der Deklaration von Codeelementen (z. B. Klassen oder Funktionen) sollten Leerzeilen eingefügt werden.

Unterschiede zu PSR-2

PSR-12 erweitert PSR-2 um:

  • Unterstützung moderner PHP-Features (z. B. nullable types, declare(strict_types=1), traits, type hinting).
  • Mehr Klarheit bei der Zeilenlänge, bei umgebrochenen Methodenparametern und bei Arrays.
  • Explizitere Regeln zur Typdeklaration.

Vorteile von PSR-12

  • Vereinfachung von Code-Reviews.
  • Bessere Lesbarkeit und Wartbarkeit von Code.
  • Erhöhte Interoperabilität zwischen verschiedenen PHP-Projekten.
  • Einheitlichkeit bei der Verwendung moderner PHP-Features.

Zusammenfassung

PSR-12 ist der Standard für modernen und konsistenten PHP-Code. Es bringt Klarheit und Struktur in PHP-Projekte, besonders bei Teams, die gemeinsam an einer Codebasis arbeiten. Mit Tools wie PHP_CodeSniffer oder PHP-CS-Fixer kannst du PSR-12 problemlos einhalten.


PSR-11

PSR-11 ist eine PHP-Standard-Empfehlung (PHP Standard Recommendation), die sich mit der Container-Interface-Definition beschäftigt. Sie beschreibt ein einheitliches Interface für Dependency Injection Container, das in PHP-Projekten verwendet werden kann. Dependency Injection Container sind Werkzeuge, die Klassen und ihre Abhängigkeiten verwalten und auflösen.

Ziel von PSR-11

PSR-11 wurde eingeführt, um sicherzustellen, dass verschiedene Frameworks, Bibliotheken und Tools interoperabel mit Dependency Injection Containern arbeiten können. Durch die Einhaltung dieses Standards wird es möglich, verschiedene Container in einem Projekt zu verwenden, ohne den Code ändern zu müssen.

Kernkomponenten des PSR-11

PSR-11 definiert zwei Interfaces:

  1. ContainerInterface

    • Das zentrale Interface, das Methoden bereitstellt, um Abhängigkeiten aus dem Container zu holen.
namespace Psr\Container;

interface ContainerInterface {
    public function get(string $id);
    public function has(string $id): bool;
}
    • get(string $id): Gibt die Instanz (oder den Service) zurück, die im Container unter einer bestimmten ID registriert ist.
    • has(string $id): Prüft, ob der Container eine Instanz mit der angegebenen ID enthält.
  • 2. NotFoundExceptionInterface

    • Wird ausgelöst, wenn ein Service nicht im Container gefunden wird.
namespace Psr\Container;

interface NotFoundExceptionInterface extends ContainerExceptionInterface {
}

3. ContainerExceptionInterface

    • Wird für generelle Fehler im Container verwendet.

Vorteile von PSR-11

  • Interoperabilität: Verschiedene Frameworks und Bibliotheken können denselben Container nutzen.
  • Standardisierung: Einheitliche API für Containerzugriffe.
  • Erweiterbarkeit: Entwickler können eigene Container erstellen, die den PSR-11-Spezifikationen entsprechen.

Typischer Anwendungsfall

PSR-11 wird häufig in Frameworks wie Symfony, Laravel, oder Zend Framework (jetzt Laminas) verwendet, die Dependency Injection Container bereitstellen. Auch Tools wie PHP-DI oder Pimple unterstützen PSR-11.

Beispiel

Ein einfaches Beispiel für den Einsatz von PSR-11:

use Psr\Container\ContainerInterface;

class MyService {
    public function __construct(private string $message) {}
    public function greet(): string {
        return $this->message;
    }
}

$container = new SomePSR11CompliantContainer();
$container->set('greeting_service', function() {
    return new MyService('Hello, PSR-11!');
});

if ($container->has('greeting_service')) {
    $service = $container->get('greeting_service');
    echo $service->greet(); // Ausgabe: Hello, PSR-11!
}

Fazit

PSR-11 ist eine wichtige Schnittstelle für modernes PHP-Entwickeln, da sie Abhängigkeiten und deren Auflösung standardisiert. Dies führt zu flexibleren und besser wartbaren Anwendungen.

 

 

 


PSR-7

PSR-7 ist eine PHP Standard Recommendation (PSR), die sich auf HTTP-Nachrichten in PHP bezieht. Sie wurde von der PHP-FIG (Framework Interoperability Group) entwickelt und definiert Schnittstellen für das Arbeiten mit HTTP-Nachrichten, wie sie von Webservern und -Clients verwendet werden.

Hauptmerkmale von PSR-7:

  1. Request und Response:
    PSR-7 standardisiert, wie HTTP-Requests und -Responses in PHP dargestellt werden. Es stellt Schnittstellen für:

    • RequestInterface: Repräsentiert HTTP-Anfragen.
    • ResponseInterface: Repräsentiert HTTP-Antworten.
  2. Unveränderlichkeit (Immutability):
    Alle Objekte sind unveränderlich. Das bedeutet, dass Änderungen an einem HTTP-Objekt ein neues Objekt erzeugen, anstatt das bestehende zu modifizieren. Dies verbessert die Vorhersagbarkeit und erleichtert Debugging.

  3. Streams:
    PSR-7 verwendet Stream-Objekte, um HTTP-Nachrichtenkörper zu handhaben. Die StreamInterface definiert Methoden für die Arbeit mit Streams (z. B. read(), write(), seek()).

  4. ServerRequest:
    Die Schnittstelle ServerRequestInterface erweitert RequestInterface, um zusätzliche Daten wie Cookies, Server-Parameter und hochgeladene Dateien zu behandeln.

  5. Kompatibilität mit Middleware:
    PSR-7 ist der Grundstein für Middleware-Architekturen in PHP. Es erleichtert die Entwicklung von Middleware-Komponenten, die HTTP-Anfragen verarbeiten und Antworten manipulieren.

Verwendung:

PSR-7 ist in modernen PHP-Frameworks und -Libraries weit verbreitet, darunter:

Ziel:

Das Ziel von PSR-7 ist es, die Interoperabilität zwischen verschiedenen PHP-Bibliotheken und -Frameworks zu verbessern, indem ein gemeinsamer Standard für HTTP-Nachrichten definiert wird.

 


PSR-6

PSR-6 ist ein Standard des PHP-FIG (PHP Framework Interoperability Group), der eine gemeinsame Schnittstelle für das Caching in PHP-Anwendungen definiert. Diese Spezifikation, die als „Caching Interface“ bekannt ist, zielt darauf ab, Interoperabilität zwischen verschiedenen Caching-Bibliotheken zu fördern, indem sie eine standardisierte API bereitstellt.

Wichtige Bestandteile von PSR-6 sind:

  1. Cache Pool Interface (CacheItemPoolInterface): Stellt eine Sammlung von Cache-Elementen dar. Es ist verantwortlich für das Verwalten, Abrufen, Speichern und Löschen von Cache-Daten.

  2. Cache Item Interface (CacheItemInterface): Repräsentiert einzelne Cache-Elemente innerhalb des Pools. Jedes Cache-Element enthält einen eindeutigen Schlüssel und einen gespeicherten Wert und kann so konfiguriert werden, dass es nach einer bestimmten Zeit abläuft.

  3. Standardisierte Methoden: PSR-6 definiert Methoden wie getItem(), hasItem(), save() und deleteItem() im Cache-Pool sowie get(), set() und expiresAt() im Cache-Element-Interface, um Cache-Operationen zu standardisieren und Konsistenz sicherzustellen.

Durch die Definition dieser Schnittstellen ermöglicht PSR-6 Entwicklern das einfache Austauschen von Caching-Bibliotheken oder das Integrieren verschiedener Caching-Lösungen, ohne die Kernlogik der Anwendung ändern zu müssen.

 


PSR-4

PSR-4 ist eine PHP-Standard-Empfehlung für das Autoloading von Klassen basierend auf Namespaces und Dateipfaden. Dieser Standard wurde von der PHP-FIG (PHP Framework Interop Group) entwickelt und beschreibt, wie vollständig qualifizierte Klassennamen zu den entsprechenden Dateipfaden gemappt werden. Dadurch kann PHP Klassen automatisch finden und laden, ohne dass manuelle require- oder include-Anweisungen nötig sind.

Hauptprinzipien von PSR-4:

  1. Namespace-Zuordnung: PSR-4 verlangt, dass der Namespace und Klassenname mit der Verzeichnisstruktur und dem Dateinamen übereinstimmen. Jeder Namespace-Präfix wird mit einem Basisverzeichnis verknüpft, und innerhalb dieses Verzeichnisses entspricht die Verzeichnisstruktur dem Namespace.

  2. Basisverzeichnis: Für jeden Namespace-Präfix wird ein Basisverzeichnis definiert, und die Klassen werden in Unterverzeichnissen des Basisverzeichnisses entsprechend ihrer Namespace-Struktur abgelegt. Zum Beispiel:

    • Wenn der Namespace App\Controllers ist, sollte die Datei in einem Verzeichnis wie /path/to/project/src/Controllers liegen.
  3. Dateibenennung: Der Klassenname muss genau mit dem Dateinamen übereinstimmen und mit .php enden.

  4. Kompatibilität mit Autoloadern: Die Implementierung von PSR-4 gewährleistet Kompatibilität mit modernen Autoloadern wie dem von Composer, wodurch PHP Klassen automatisch ohne manuelle Einbindung findet.

Beispiel für die Nutzung von PSR-4:

Angenommen, Sie haben die Klasse App\Controllers\UserController, so sollte die Verzeichnisstruktur wie folgt aussehen:

/path/to/project/src/Controllers/UserController.php

In der composer.json von Composer wird diese Zuordnung wie folgt angegeben:

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

Dies weist Composer an, die Klassen im App-Namespace aus dem src/-Verzeichnis zu laden. Wenn Sie composer dump-autoload ausführen, wird Composer das Autoloading gemäß dem PSR-4-Standard konfigurieren.

Vorteile von PSR-4:

  • Konsistenz: Erzwingt eine klare und organisierte Dateistruktur.
  • Benutzerfreundlichkeit: Erleichtert das Autoloading in großen Projekten.
  • Kompatibilität: Funktioniert gut mit Frameworks und Bibliotheken, die dem PSR-4-Standard folgen.

PSR-4 hat den älteren PSR-0-Standard abgelöst und ist nun der bevorzugte Autoloading-Standard für moderne PHP-Projekte.

 

 


Monolog

Monolog ist eine weit verbreitete Logging-Bibliothek für PHP, die das PSR-3-Standardinterface für Logs implementiert und so kompatibel mit PSR-3-konformen Frameworks und Anwendungen ist. Monolog bietet eine einfache und flexible Möglichkeit, Logs in verschiedenen Zielsystemen zu speichern und zu verwalten. Entwickler können damit Fehler, Warnungen oder allgemeine Informationen in PHP-Anwendungen protokollieren und so das Debugging und die Wartung ihrer Anwendungen verbessern.

Hauptfunktionen und Konzepte von Monolog:

  1. Logger Instanz: Monolog erstellt einen Logger über die Logger-Klasse. Die Logger-Instanz unterstützt verschiedene Log-Level (z. B. debug, info, warning, error), die in PHP-Programmen genutzt werden können, um verschiedene Schweregrade von Log-Nachrichten zu erfassen.

  2. Handler: Ein Herzstück von Monolog ist das Konzept der Handler. Handler steuern, wohin und wie die Log-Einträge gespeichert werden. Monolog unterstützt zahlreiche Handler, darunter:

    • StreamHandler: Schreibt Logs in Dateien oder Streams.
    • RotatingFileHandler: Erzeugt täglich rotierende Log-Dateien.
    • FirePHPHandler und ChromePHPHandler: Ermöglichen das Loggen direkt in den Browser (über spezielle Browser-Erweiterungen).
    • SlackHandler, MailHandler u. a.: Zum Versand von Logs an spezifische Kanäle wie Slack oder per E-Mail.
  3. Formatter: Handler können mit Formatters kombiniert werden, um den Inhalt der Logs anzupassen. Monolog bietet verschiedene Formatierer, die z. B. die Logs im JSON-Format ausgeben können oder einfach nur die grundlegende Textausgabe formatieren.

  4. Processor: Neben Handlern und Formattern erlaubt Monolog auch den Einsatz von Prozessoren, die zusätzliche Daten an die Log-Einträge anhängen, z. B. Kontextinformationen wie User-Daten oder die aktuelle IP-Adresse.

Beispiel zur Verwendung von Monolog:

Hier ein einfaches Beispiel zur Initialisierung und Nutzung eines Monolog-Loggers:

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$logger = new Logger('name');
$logger->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::WARNING));

// Log-Meldung erstellen
$logger->warning('Dies ist eine Warnung');
$logger->error('Dies ist ein Fehler');

Vorteile von Monolog:

  • Modularität: Dank der Handler ist Monolog sehr flexibel und anpassbar, um Logs an verschiedene Orte zu senden.
  • PSR-3-Kompatibilität: Monolog erfüllt den PSR-3-Standard, was die Integration in andere PHP-Projekte vereinfacht.
  • Erweiterbarkeit: Handler, Formatter und Prozessoren können individuell konfiguriert oder durch benutzerdefinierte Klassen erweitert werden, um spezifische Anforderungen zu erfüllen.

Verbreitung

Monolog ist eine der am häufigsten eingesetzten Logging-Bibliotheken in PHP, vor allem in Kombination mit Symfony, Laravel und anderen PHP-Frameworks.