Deployer ist ein Open-Source-Deployment-Tool für PHP-Projekte – speziell entwickelt, um Anwendungen wie Laravel, Symfony, Magento, WordPress oder auch generische PHP-Apps automatisiert, wiederholbar und sicher auf Server zu bringen.
Es ist ein CLI-Tool, geschrieben in PHP.
Du definierst dein Deployment in einer deploy.php
-Datei mit klaren Aufgaben (Tasks).
Es setzt auf das Prinzip Zero Downtime Deployment, z. B. durch Symlinks.
Unterstützt mehrstufige Umgebungen (z. B. staging, production).
Du installierst Deployer über Composer:
composer require deployer/deployer --dev
Du generierst ein Template:
vendor/bin/dep init
Du konfigurierst deploy.php
, z. B. für Laravel:
host('mein-server.com')
->set('deploy_path', '/var/www/meinprojekt')
->set('branch', 'main');
task('deploy', [
'deploy:prepare',
'deploy:vendors',
'artisan:migrate',
'deploy:publish',
]);
Du startest das Deployment:
vendor/bin/dep deploy production
Deployer:
Verbindet sich via SSH mit dem Zielserver
Klont das Git-Repository in ein neues Release-Verzeichnis
Installiert Composer-Abhängigkeiten
Führt Tasks aus (z. B. php artisan migrate
)
Verlinkt das neue Release mit dem Live-Verzeichnis (current
)
Löscht alte Releases nach Bedarf
Vorteil | Beschreibung |
---|---|
🚀 Schnell & Skriptbar | Alles per CLI steuerbar |
🔁 Rollback-Funktion | Bei Fehlern einfach zum letzten funktionierenden Release zurück |
⚙️ Flexibel erweiterbar | Eigene Tasks, Hooks und Bedingungen |
🧩 Viele Presets | Für Laravel, Symfony, WordPress etc. |
🔐 Sicher durch SSH | Keine FTP-Abhängigkeit |
Datenbank-Trigger (kurz: Trigger) sind spezielle automatische Aktionen in einer Datenbank, die ausgelöst werden, wenn bestimmte Ereignisse auf einer Tabelle oder Sicht (View) passieren.
Ein Trigger ist ein vordefinierter Code, der bei INSERT, UPDATE oder DELETE auf einer Tabelle automatisch ausgeführt wird – ohne dass der Benutzer ihn direkt aufruft.
Stell dir vor, du hast eine Tabelle Bestellungen
, und du willst, dass immer, wenn eine Bestellung gelöscht wird, diese Info in einer Tabelle Log
gespeichert wird.
Dann schreibst du einen DELETE-Trigger für die Tabelle Bestellungen
, der automatisch beim Löschen etwas in Log
schreibt.
Typ | Beschreibung |
---|---|
BEFORE | Wird vor der Aktion ausgeführt |
AFTER | Wird nach der Aktion ausgeführt |
INSTEAD OF | (bei Views) ersetzt die Aktion komplett |
CREATE TRIGGER log_delete
AFTER DELETE ON Bestellungen
FOR EACH ROW
BEGIN
INSERT INTO Log (aktion, zeitpunkt)
VALUES ('Bestellung gelöscht', NOW());
END;
Validierung von Daten
Automatisches Logging
Business-Logik abbilden
Referentielle Integrität erweitern
Schwer zu debuggen
Können unbemerkt viele Aktionen auslösen
Beeinflussen Performance, wenn komplex
GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.
Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:
🛠️ Code bei jedem Push oder Pull Request builden
🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)
📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)
🔄 Cronjobs oder geplante Tasks laufen lassen
GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:
Die Datei heißt z. B. .github/workflows/ci.yml
Sie ist im YAML-Format
Du definierst Events (z. B. push
, pull_request
) und Jobs (z. B. build
, test
)
Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '20'
- run: npm install
- run: npm test
Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:
Vorgefertigte Actions (z. B. actions/checkout
, setup-node
, upload-artifact
)
Eigene Actions (z. B. Shell-Skripte oder Docker-Container)
Du kannst Actions im GitHub Marketplace finden und nutzen.
Spart manuelle Arbeit
Verbessert Codequalität (durch automatisierte Tests)
Macht Deployments reproduzierbar
Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)
Storyblok ist ein benutzerfreundliches, headless Content-Management-System (CMS), das Entwicklern und Marketing-Teams hilft, Inhalte schnell und effizient zu erstellen, zu verwalten und zu veröffentlichen. Es bietet eine visuelle Bearbeitungsoberfläche, die es ermöglicht, Inhalte in Echtzeit zu gestalten, und ist flexibel mit verschiedenen Frameworks und Plattformen kompatibel. Durch seine API-first-Architektur können Inhalte auf jeder digitalen Plattform ausgespielt werden, was es ideal für moderne Web- und App-Entwicklung macht.
Ein Prepared Statement (auch vorbereitetes Statement genannt) ist eine Technik in der Programmierung, insbesondere bei der Arbeit mit Datenbanken, um SQL-Abfragen sicherer und effizienter auszuführen.
Ein Prepared Statement besteht aus zwei Schritten:
Vorbereitung der SQL-Abfrage mit Platzhaltern
Beispiel in SQL:
SELECT * FROM users WHERE username = ? AND password = ?
(In manchen Sprachen nutzt man auch :username
oder andere Platzhalter)
Bindung der Parameter und Ausführung
Die echten Werte werden später „gebunden“, z. B.:
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
✅ Sicherer vor SQL-Injection:
Benutzereingaben werden nicht direkt in die SQL eingebaut, sondern separat behandelt.
✅ Schneller bei Wiederholungen:
Die SQL-Abfrage wird vom Datenbankserver einmal geparst und kann mehrfach effizient ausgeführt werden (z. B. bei Schleifen).
$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" für string
$email = "beispiel@example.com";
$stmt->execute();
$result = $stmt->get_result();
Ein Prepared Statement trennt SQL-Logik von Benutzereingaben und schützt so vor Sicherheitslücken wie SQL-Injection. Es ist eine Best Practice beim Umgang mit Datenbanken.
Ein Outer Join ist ein Begriff aus der Datenbankabfrage (meist in SQL) und bezeichnet eine spezielle Art, zwei Tabellen miteinander zu verknüpfen – auch dann, wenn keine passenden Datensätze in einer der Tabellen vorhanden sind.
LEFT OUTER JOIN (oder einfach: LEFT JOIN):
→ Gibt alle Datensätze aus der linken Tabelle zurück, auch wenn es keine passenden Datensätze in der rechten Tabelle gibt.
→ Nicht passende Werte aus der rechten Tabelle werden mit NULL
aufgefüllt.
RIGHT OUTER JOIN (oder: RIGHT JOIN):
→ Gibt alle Datensätze aus der rechten Tabelle zurück, auch wenn es keine passenden in der linken gibt.
→ Nicht passende Werte aus der linken Tabelle werden mit NULL
ergänzt.
FULL OUTER JOIN:
→ Gibt alle Datensätze aus beiden Tabellen zurück.
→ Wo keine Übereinstimmung vorliegt, wird mit NULL
ergänzt.
Angenommen, du hast zwei Tabellen:
Kunden
Kundennr | Name |
1 | Anna |
2 | Bernd |
3 | Clara |
Bestellungen
Bestellnr | Kundennr | Produkt |
101 | 2 | Buch |
102 | 4 | Lampe |
Kundennr | Name | Bestellnr | Produkt |
---|---|---|---|
1 | Anna | NULL | NULL |
2 | Bernd | 101 | Buch |
3 | Clara | NULL | NULL |
Transaction Control Language (TCL) ist ein Teil der SQL-Sprache, der verwendet wird, um die Kontrolle über Transaktionen in einer Datenbank zu ermöglichen. Eine Transaktion ist eine logische Einheit von Arbeit, die eine oder mehrere SQL-Anweisungen umfasst – oft Insert-, Update- oder Delete-Befehle –, die zusammen ausgeführt werden sollen.
TCL stellt Befehle bereit, um sicherzustellen, dass Transaktionen korrekt abgeschlossen oder im Fehlerfall rückgängig gemacht werden.
Befehl | Beschreibung |
---|---|
COMMIT |
Speichert alle Änderungen der aktuellen Transaktion dauerhaft in der Datenbank. |
ROLLBACK |
Macht alle Änderungen seit dem letzten COMMIT rückgängig. |
SAVEPOINT |
Legt einen Zwischenstand in einer Transaktion fest, zu dem man später zurückkehren kann. |
ROLLBACK TO SAVEPOINT |
Macht alle Änderungen seit einem bestimmten Savepoint rückgängig. |
SET TRANSACTION |
Legt Eigenschaften für eine Transaktion fest (z. B. Isolationsgrad). |
BEGIN;
UPDATE konto SET saldo = saldo - 100 WHERE konto_id = 1;
UPDATE konto SET saldo = saldo + 100 WHERE konto_id = 2;
COMMIT;
→ Beide Updates werden gemeinsam abgeschlossen. Wenn ein Fehler auftritt, könnte man ROLLBACK
ausführen, um beide Änderungen zu verwerfen.
TCL-Befehle wirken nur bei Datenbank-Systemen, die Transaktionen unterstützen (z. B. PostgreSQL, Oracle, MySQL mit InnoDB).
Die Data Manipulation Language (DML) ist ein Teilbereich der SQL (Structured Query Language), der für das Bearbeiten von Daten in einer Datenbank verwendet wird. Mit DML können Benutzer Daten einfügen, abfragen, ändern und löschen – also genau das, was man im Alltag mit Daten in einer Datenbank machen möchte.
Befehl | Zweck |
---|---|
SELECT |
Daten aus einer Tabelle abfragen |
INSERT |
Neue Daten einfügen |
UPDATE |
Bestehende Daten ändern |
DELETE |
Daten löschen |
Beispiel:
-- Einfügen
INSERT INTO kunden (name, stadt) VALUES ('Müller', 'Berlin');
-- Abfragen
SELECT * FROM kunden WHERE stadt = 'Berlin';
-- Aktualisieren
UPDATE kunden SET stadt = 'Hamburg' WHERE name = 'Müller';
-- Löschen
DELETE FROM kunden WHERE name = 'Müller';
DML arbeitet mit den Daten innerhalb der Tabellen, nicht mit der Struktur der Tabellen selbst (dafür gibt es die Data Definition Language, DDL).
DML-Befehle können oft rückgängig gemacht werden (z. B. durch ROLLBACK
), sofern Transaktionen unterstützt werden.
Kurz gesagt: DML ist das Werkzeug, mit dem du Daten in einer Datenbank lebendig hältst – also ständig anpasst, liest und veränderst.
Ein Entity Manager ist ein zentraler Bestandteil von ORM-Frameworks (Object-Relational Mapping), vor allem im Zusammenhang mit Java (JPA – Java Persistence API), aber auch in anderen Sprachen wie PHP (Doctrine ORM).
Hier ist eine verständliche Erklärung:
Ein Entity Manager ist eine Komponente, die sich um die Verwaltung von Datenbank-Entities (also Objekten/Datensätzen) kümmert. Er bildet die Schnittstelle zwischen der objektorientierten Welt des Codes und der relationalen Welt der Datenbank.
Persistieren (Speichern):
Finden/Laden:
Holt ein Objekt anhand seiner ID oder anderer Kriterien.
Beispiel: $entityManager->find(User::class, 1);
Aktualisieren:
Änderungen an einem Objekt werden verfolgt und in die Datenbank geschrieben (z. B. beim flush()
).
Entfernen/Löschen:
Löscht ein Objekt aus der Datenbank.
Beispiel: $entityManager->remove($user);
Transaktionen verwalten:
Beginnt, commitet oder rollt Transaktionen zurück.
Query-Handling:
Führt eigene Abfragen aus, oft mit DQL (Doctrine Query Language) oder JPQL.
Der Entity Manager verwaltet den „Zustand“ von Objekten:
managed (verfolgt Änderungen),
detached (nicht mehr verwaltet),
removed (zum Löschen markiert),
new (noch nicht gespeichert).
$user = new User();
$user->setName('Max Mustermann');
$entityManager->persist($user); // Zum Speichern vormerken
$entityManager->flush(); // Tatsächlich in DB schreiben
Der Entity Manager ist der zentrale Ansprechpartner, wenn es darum geht, mit Datenbankobjekten zu arbeiten – lesen, schreiben, ändern, löschen. Er abstrahiert die SQL-Ebene und macht die Datenbankarbeit objektorientiert steuerbar.
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.
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.
Verbindungsaufbau zu Datenbanken über Konfigurationsarrays.
Unterstützung für Verbindungs-Pooling, Transaktionen usw.
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');
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.
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.