Welches Framework nutzt WordPress?

Wer von Laravel oder Symfony kommt, stellt die Frage schnell: Welches PHP-Framework steckt eigentlich unter WordPress? Die knappe Antwort lautet: keines im klassischen Sinn. WordPress ist selbst der Unterbau – ein eigener Core, direkt auf PHP gebaut, ohne dazwischenliegendes Framework wie Laravel, Symfony oder CodeIgniter. Wer trotzdem von einem „WordPress-Framework“ spricht, meint meist eines von zwei völlig unterschiedlichen Dingen: entweder den technischen Stack aus PHP, Datenbank und Hook-System, oder ein Theme-Framework wie Genesis, das auf diesem Core aufsetzt. Die folgenden Abschnitte trennen beides sauber und zeigen, wie die Architektur im Detail funktioniert.

Die kurze Antwort: WordPress ist sein eigenes Framework

WordPress wurde 2003 gestartet und ist über die Jahre organisch gewachsen. Es setzt nicht auf ein externes MVC-Framework auf, sondern bringt seine eigenen Konventionen, APIs und Abläufe mit. In der Praxis heißt das: Sie schreiben kein Controller.php und keine routes/web.php wie in Laravel. Stattdessen arbeiten Sie mit den WordPress-eigenen Werkzeugen – der Template-Hierarchie, dem Hook-System und Funktionen wie WP_Query.

Diese Eigenständigkeit hat einen historischen Grund: Als WordPress entstand, gab es die heute üblichen PHP-Frameworks noch gar nicht oder sie waren unausgereift. Rückwärtskompatibilität ist seither ein zentrales Versprechen des Projekts, weshalb ein nachträglicher Umbau auf ein Fremd-Framework nie stattgefunden hat.

Der Technologie-Stack von WordPress

Auch ohne klassisches Framework steht WordPress auf einem klar definierten Stack. Diese vier Schichten sollten Sie kennen:

PHP – der serverseitige Kern

PHP ist die Sprache, in der praktisch der gesamte WordPress-Core geschrieben ist. Jeder Seitenaufruf startet in der index.php im Stammverzeichnis, lädt wp-load.php und baut daraus die fertige HTML-Seite. PHP verarbeitet Anfragen, holt Inhalte aus der Datenbank und rendert das aktive Theme. Der technische Mindestwert liegt aus historischen Gründen niedrig, WordPress.org empfiehlt aber ausdrücklich eine deutlich aktuellere Version für Sicherheit und Performance.

MySQL oder MariaDB – die Datenbank

Beiträge, Seiten, Benutzer, Kommentare und Einstellungen liegen in einer relationalen Datenbank. WordPress unterstützt MySQL und die kompatible Alternative MariaDB. Die Kerntabellen erkennen Sie am Präfix wp_ – etwa wp_posts für Inhalte, wp_options für Konfigurationswerte und wp_users für Konten. Wichtig zu wissen: WordPress nutzt kein ORM wie Eloquent. Datenbankzugriffe laufen über das globale Objekt $wpdb sowie über spezialisierte Klassen wie WP_Query.

JavaScript – vom Frontend bis zum Block-Editor

JavaScript hat in WordPress in den letzten Jahren stark an Bedeutung gewonnen. Drei Bereiche sind relevant:

• jQuery ist historisch im Core gebündelt und treibt viele ältere Themes und Plugins an. Das Projekt reduziert die Abhängigkeit davon schrittweise.
• React ist die Grundlage des Block-Editors („Gutenberg“). Wer eigene Blöcke baut, arbeitet mit React-Komponenten und den @wordpress/-Paketen.
• Die Interactivity API wurde mit WordPress 6.5 (April 2024) als stabiles Feature eingeführt und bietet einen einheitlichen Weg, Interaktivität im Frontend umzusetzen, ohne dass jedes Plugin ein eigenes JS-Framework mitbringen muss.

HTML und CSS

Die Ausgabe im Browser ist am Ende klassisches HTML und CSS. Themes bestimmen die Struktur und das Aussehen; seit den Block-Themes lässt sich das Design zusätzlich über eine theme.json zentral steuern.

Die Architektur: Hooks statt MVC

Der entscheidende Unterschied zu Laravel oder Symfony liegt nicht in der Sprache, sondern im Aufbau. WordPress folgt keinem strikten Model-View-Controller-Muster, sondern einer ereignisgesteuerten Plugin-Architektur. Das Herzstück ist das Hook-System aus Actions und Filtern.

Vereinfacht gesagt: Der Core ruft an hunderten Stellen definierte Punkte auf, an die sich Ihr Code „einklinken“ kann.

// Action: eigenen Code an einem bestimmten Punkt ausführen
add_action( 'wp_enqueue_scripts', 'meine_styles_laden' );

function meine_styles_laden() {
    wp_enqueue_style( 'mein-stil', get_stylesheet_uri() );
}

// Filter: einen Wert verändern, bevor WordPress ihn weiterverwendet
add_filter( 'the_title', 'titel_grossschreiben' );

function titel_grossschreiben( $titel ) {
    return strtoupper( $titel );
}

Actions führen zusätzlichen Code aus, Filter verändern bestehende Werte. Dieses Prinzip erklärt, warum sich WordPress so tief anpassen lässt, ohne dass Sie Core-Dateien bearbeiten müssen – ein Eingriff, der ohnehin verboten ist, weil das nächste Update ihn überschreibt.

Der zweite Pfeiler ist die Template-Hierarchie. Welche Datei ein Theme zur Anzeige nutzt, entscheidet WordPress nach festen Regeln: Für einen einzelnen Beitrag wird single.php gesucht, für eine Seite page.php, für ein Archiv archive.php, als letzter Rückfall immer index.php. Die zentrale functions.php registriert dabei Funktionen, Menüs und Theme-Unterstützung.

Nutzt WordPress Laravel oder Symfony?

Nein – der Core selbst nicht. Es gibt aber zwei Berührungspunkte, die für Verwirrung sorgen:

• WP-CLI, das Kommandozeilen-Werkzeug für WordPress, ist unter Verwendung von Symfony-Komponenten (unter anderem der Console-Komponente) gebaut. Das betrifft aber nur das Tool, nicht WordPress selbst.
• Sage von Roots bringt über das Paket Acorn Laravels Templating-Engine Blade sowie weitere Laravel-Bausteine (Container, Facades) in ein WordPress-Theme. Wer damit arbeitet, kombiniert bewusst zwei Welten – Standard ist das nicht, und der WordPress-Core selbst bleibt davon unberührt.

Für normale Websites gilt: Sie brauchen weder Laravel noch Symfony, um mit WordPress zu arbeiten.

Theme- und Plugin-Frameworks: was oft gemeint ist

Häufig zielt die Frage nach dem „Framework“ gar nicht auf den technischen Unterbau, sondern auf ein Theme-Framework – also ein Grundgerüst, auf dem man Designs schneller aufbaut. Verbreitete Vertreter sind:

• Underscores (_s) – ein minimales Starter-Theme aus dem WordPress-Umfeld, gedacht als Ausgangspunkt für eigene Entwicklungen.
• Genesis – ein etabliertes kommerzielles Framework mit Fokus auf Performance und Sicherheit.
• Divi – kombiniert Theme und visuellen Page-Builder; mehr dazu, wie sich Divi über mehrere Projekte einsetzen lässt, lesen Sie unter Divi auf mehreren Websites verwenden.
• Page-Builder wie Elementor, die eher eine Design-Ebene als ein Code-Framework sind. Deren Grenzen beschreibt der Beitrag zu den Nachteilen von Elementor.

Diese Frameworks sind kein Ersatz für den WordPress-Core, sondern sitzen als Theme oder Plugin darauf auf.

Systemvoraussetzungen kurz zusammengefasst

Damit dieser Stack läuft, braucht Ihr Hosting einige Grundlagen. Als Richtwerte gelten:

• PHP in einer aktuellen, vom Hersteller noch gepflegten Version (siehe oben).
• MySQL oder MariaDB in einer unterstützten Version.
• HTTPS-Unterstützung für ein gültiges SSL-Zertifikat.

Ob ein Paket diese Anforderungen erfüllt, klärt sich meist schon bei der Wahl des Anbieters – worauf es dabei ankommt, erklärt der Beitrag Was heißt intelligentes Hosting?.

FAQ

Ist WordPress in PHP geschrieben? Ja. Der gesamte Core besteht überwiegend aus PHP, ergänzt um MySQL/MariaDB für die Datenhaltung sowie JavaScript, HTML und CSS für die Ausgabe und den Block-Editor.

Warum nutzt WordPress kein Laravel oder Symfony? WordPress ist deutlich älter als diese Frameworks und legt größten Wert auf Rückwärtskompatibilität. Ein nachträglicher Wechsel würde Millionen bestehender Themes und Plugins brechen. Stattdessen pflegt das Projekt seine eigene, hook-basierte Architektur.

Was ist der Unterschied zwischen dem WordPress-Core und einem Theme-Framework? Der Core ist der technische Unterbau (PHP, Datenbank, Hooks, APIs). Ein Theme-Framework wie Genesis oder Divi ist eine darauf aufsetzende Design-Grundlage, die den Bau von Layouts beschleunigt – es ersetzt den Core nicht, sondern erweitert ihn.