Wissen / Laufzeit aktuell halten

PHP-Supportende: Den Versionswechsel rechtzeitig planen

Kurz gesagt: Beim Supportende einer PHP-Version endet deren vorgesehene Pflege durch das PHP-Projekt. Ein Wechsel betrifft jedoch mehr als die Versionsauswahl im Hostingmenü: Anwendung, Erweiterungen, Konfiguration und zeitgesteuerte Skripte müssen zusammenpassen. Ein geplanter Übergang mit überprüfbaren Kernfunktionen reduziert vermeidbare Überraschungen und schafft Klarheit über Zuständigkeit, Restprobleme und Betrieb.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 8 Minuten Lesezeit

01 / SUPPORTSTATUS

Eine funktionierende Website kann trotzdem eine auslaufende Grundlage haben.

Sichtbare Funktionsfähigkeit und gepflegte Laufzeit sind verschiedene Eigenschaften.

Im Hostingkonto erscheint eine Nachricht: Die verwendete PHP-Version wird bald nicht mehr unterstützt. Weil die Website weiterhin lädt, wirkt das zunächst wie eine rein technische Formalität. Tatsächlich betrifft die Meldung den Lebenszyklus einer Laufzeit, die beispielsweise ein Redaktionssystem oder eigene Hintergrundlogik ausführt. Die sichtbare Oberfläche verrät nicht zuverlässig, welchen Pflegezustand diese Grundlage besitzt.

Die offizielle PHP-Übersicht zu unterstützten Versionen unterscheidet aktive Pflege, anschließende Sicherheitsunterstützung und das Ende des vorgesehenen Supports. Der konkrete Status wird zum geplanten Umstellungstermin erneut geprüft. Eine heute aktuelle Versionstabelle ist kein dauerhaft gültiger Projektplan für die nächsten Jahre.

Supportende bedeutet nicht, dass jede Website an diesem Tag sofort ausfällt. Es bedeutet ebenso wenig, dass ein Weiterbetrieb ohne Betrachtung der Folgen unproblematisch wäre. Klären Sie, wer die Laufzeit bereitstellt, welche Anwendungen sie benötigen und welche Umstellungsmöglichkeiten bestehen. Auch eine zusätzliche Pflegezusage des Hosters sollte mit genauem Umfang und Laufzeit verstanden werden.

Eine statische Website benötigt nicht automatisch PHP für jede Seite. Vielleicht verwendet nur ein Kontaktendpunkt die Laufzeit. Bei einem Redaktionssystem können dagegen nahezu alle Aufrufe betroffen sein. Der erste nützliche Schritt ist deshalb eine Bestandsaufnahme des tatsächlichen Einsatzes. Der allgemeine Artikel zu Domain, DNS und Hosting ordnet die beteiligten Grundlagen ein.

02 / BESTANDSAUFNAHME

Die ausgewählte Domainversion ist möglicherweise nur ein Teil des Systems.

Webaufrufe, Hintergrundaufgaben und Werkzeuge müssen getrennt erfasst werden.

Notieren Sie, welche Anwendung PHP verwendet und über welchen Weg sie ausgeführt wird. Dazu können die öffentliche Website, ein Formular, ein geplanter Import oder ein Wartungswerkzeug gehören. Ein Eintrag im Hostingmenü kann nur die Webausführung steuern. Ein zeitgesteuertes Skript könnte weiterhin mit einer anders eingestellten Laufzeit gestartet werden.

Die PHP-Dokumentation zur Konfigurationsdatei beschreibt unterschiedliche Ausführungsumgebungen und die Suche nach Konfiguration. Für die Planung folgt daraus: Versionsnummer, verfügbare Erweiterungen und wirksame Einstellungen werden am tatsächlichen Ausführungsweg geprüft. Eine Prüfung an der falschen Stelle kann eine Abweichung übersehen.

Erfassen Sie benötigte Module und besondere Einstellungen, ohne Konfigurationsinhalte öffentlich auszugeben. Manche Anwendungen benötigen beispielsweise eine bestimmte Datenbankanbindung oder eine Verarbeitung für Dateien. Entscheidend ist der dokumentierte Bedarf Ihrer Anwendung. Eine vollständige technische Diagnose sollte in einem geschützten Arbeitskontext stattfinden und keine vertraulichen Umgebungsangaben auf einer frei erreichbaren Hilfsseite zurücklassen.

Ordnen Sie jedem Eintrag einen Ansprechpartner zu. Wer kennt den geplanten Import, wer betreut das Redaktionssystem und wer darf die Hostingkonfiguration ändern? Diese Zuständigkeiten sind häufig wichtiger als ein möglichst umfangreiches Inventar. Bleibt ein alter Hintergrundjob ungeklärt, darf er nicht stillschweigend als erledigt gelten, nur weil die Startseite nach der Umstellung funktioniert.

03 / KOMPATIBILITÄT

Die Zielversion muss zum gesamten Anwendungspaket passen.

Unterstützung einer Grundlage ist keine pauschale Freigabe jeder Erweiterung.

Die neueste auswählbare Version ist nicht ohne Prüfung automatisch das passende Ziel. Prüfen Sie zunächst die Angaben der eingesetzten Anwendung und ihrer benötigten Erweiterungen. Unterschiedliche Bestandteile können verschiedene Voraussetzungen haben. Eine ältere eigene Anpassung kann dabei genauso relevant sein wie ein zugekauftes Modul.

Die WordPress-Anforderungen unterscheiden aktuelle Empfehlungen von weiterhin möglichem Betrieb auf älteren Grundlagen. Dass eine Installation noch startet, ist daher keine Empfehlung, eine auslaufende Umgebung unbegrenzt beizubehalten. Entscheidend ist ein tragfähiger Zielzustand für das gesamte eingesetzte System.

Die offizielle PHP-Kompatibilitätsübersicht des WordPress-Projekts betrifft die dort beschriebenen WordPress-Versionen. Sie ersetzt keine Prüfung aller tatsächlich verwendeten Themes, Erweiterungen und individuellen Anpassungen. Lesen Sie außerdem die Bedeutung der jeweiligen Einstufung, statt aus einer Tabellenmarkierung eine umfassende Betriebszusage abzuleiten.

Bei einer eigenen Anwendung werden entsprechend deren Bibliotheken und technische Voraussetzungen betrachtet. Die PHP-Migrationsdokumentation für einen konkreten Versionsschritt zeigt, welche Arten von Änderungen auftreten können: neue Möglichkeiten, geändertes Verhalten und entfallende Funktionen. Für Ihren Wechsel wird die Dokumentation der tatsächlich betroffenen Schritte gelesen. Die beispielhaft verlinkte Anleitung legt keine bestimmte Zielversion für jedes Projekt fest.

04 / PRÜFWEGE

Die wichtigen Funktionen müssen vor dem Umschalten bekannt sein.

Ein kleiner überprüfbarer Katalog ist nützlicher als die Aussage, man werde alles ansehen.

Wählen Sie konkrete Kernfälle aus. Bei einer kleinen Unternehmenswebsite könnten das eine veröffentlichte Unterseite, eine Anfrage mit kontrollierter Zustellung und ein geschützter Pflegevorgang sein. Bei einer Anwendung kommen schreibende Abläufe, Dateien oder geplante Aufgaben hinzu. Die Auswahl richtet sich nach Risiko und Nutzung, nicht nach der Anzahl sichtbarer Menüpunkte.

Die Vorbereitung in einer Testumgebung ermöglicht, den Versionswechsel vor dem öffentlichen Umschalten zu prüfen. Für den PHP-Wechsel muss diese Umgebung die relevanten Laufzeitbedingungen ausreichend abbilden. Ein Test mit anderer Erweiterungsausstattung kann falsche Sicherheit vermitteln. Abweichungen werden deshalb ausdrücklich festgehalten.

Prüfen Sie Ergebnisse und Fehlerbeobachtung gemeinsam. Ein Formular kann seine Bestätigungsseite anzeigen, obwohl eine spätere Verarbeitung fehlschlägt. Ein Import kann nur in seltenen Datensituationen Probleme zeigen. Geeignete synthetische Testfälle und geschützte Protokolle helfen bei der Einordnung. Vertrauliche Fehlermeldungen gehören dabei nicht in die öffentliche Darstellung.

Vereinbaren Sie vor der Umstellung, was als ausreichend geprüft gilt und welche Punkte offenbleiben. Eine bekannte Einschränkung braucht eine verantwortliche Entscheidung. Sie sollte nicht hinter einer pauschalen Meldung „kompatibel“ verschwinden. Ebenso wird der öffentliche Zustand nach dem Wechsel gezielt kontrolliert, weil erst dort der tatsächliche Auslieferungsweg vollständig beteiligt ist.

Geplante Aufgaben werden nicht allein deshalb als geprüft markiert, weil ihr nächster regulärer Termin noch aussteht. Vereinbaren Sie einen kontrollierten Nachweis, der zu ihrer Ausführung passt. Ein monatlicher Bericht kann sonst lange nach der Umstellung erstmals auffallen. Ein solcher Test darf wiederum keine doppelten echten Nachrichten oder Datenübernahmen auslösen. Die zuständige Betreuung legt fest, wie der relevante Ablauf mit bekannten Testdaten überprüft und sein Ergebnis eindeutig zugeordnet wird.

05 / ARBEITSBLATT

Ein fiktiver Wartungsfall zeigt die häufig übersehene zweite Laufzeit.

Das folgende Raster ist eine eigene Arbeitshilfe für die Abstimmung mit der Betreuung.

Ein fiktives Beratungsunternehmen lässt seine Website auf eine gepflegte PHP-Version umstellen. Die Seiten und das Anfrageformular funktionieren. Ein nachts geplanter Datenabgleich verwendet jedoch weiterhin einen alten Aufruf. Erst bei dessen nächster Ausführung wird die Abweichung sichtbar. Der Fehler liegt hier nicht zwingend in der neuen Version, sondern im unvollständig erfassten Wechselumfang.

Fiktives Beispiel: Eine Umstellung, mehrere Ausführungswege
BestandteilVorab klärenNachweis nach dem Wechsel
Öffentliche WebsiteWirksame Weblaufzeit und benötigte ErweiterungenVereinbarte Seiten und dynamische Funktionen geprüft
RedaktionKompatibilität der PflegefunktionenGeschützter Bearbeitungsweg funktioniert
Geplanter AbgleichTatsächlicher Startaufruf und KonfigurationKontrollierter Lauf mit bekanntem Ergebnis
RückwegVerantwortung und verwendbare AusgangslageEntscheidung vor Beginn dokumentiert

Ergänzen Sie Zielstand, Termin und Ansprechpartner. So wird sichtbar, ob eine Versionsauswahl tatsächlich alle relevanten Bestandteile erfasst oder weitere Schritte nötig sind. Das Raster behauptet nicht, dass jede Website sämtliche genannten Komponenten besitzt.

06 / UMSTELLUNG

Den Rückweg planen, ohne eine alte Laufzeit zum Dauerzustand zu machen.

Ein kontrollierter Wechsel braucht eine Entscheidung bei unerwartetem Verhalten.

Vor dem öffentlichen Umschalten werden Sicherungsstand, Zugriffsmöglichkeiten und ein geeigneter Rückweg abgestimmt. Ein Rückwechsel der PHP-Auswahl allein kann unzureichend sein, wenn gleichzeitig Anwendung oder Daten geändert wurden. Deshalb müssen zusammengehörige Änderungen als gemeinsamer Übergang betrachtet werden. Die zuständige Betreuung erklärt, welche Schritte im konkreten System tatsächlich reversibel sind.

Falls ein Kernfall fehlschlägt, wird der vereinbarte Ablauf angewendet. Nicht jedes Problem rechtfertigt eine improvisierte Folge weiterer Änderungen. Zuerst werden Beobachtung, betroffener Weg und Entscheidung festgehalten. Ein vorübergehender Rückweg schafft dann Raum für die gezielte Klärung. Er ersetzt jedoch keinen Plan für eine langfristig unterstützte Umgebung.

Nach erfolgreichem Wechsel halten Sie den wirksamen Stand und verbleibende Aufgaben fest. Dazu gehört auch, wer den nächsten Supportwechsel beobachtet. Der Nutzen liegt nicht darin, Versionsnummern möglichst oft auszutauschen. Er liegt in einer pflegbaren Grundlage, deren Anforderungen und Abhängigkeiten bekannt bleiben.

07 / RUHRSTACK

Laufzeit, Anwendung und Betreuung zusammen betrachten.

Individuelle Planung berücksichtigt auch die kleinen Bestandteile außerhalb der sichtbaren Seiten.

Ruhrstack erfasst im Bereich Hosting und Betrieb vorhandene Systeme und stimmt die Umgebung auf die eingesetzte Technik ab. Bei eigenen Anwendungen oder Skripten werden auch Laufzeiten, geplante Ausführungen und Zugänge betrachtet. Diese konkrete Bestandsaufnahme hilft, einen PHP-Wechsel passend abzugrenzen.

Für eine erste Besprechung genügen die Website-Adresse, die Hostingmeldung und eine Beschreibung bekannter Hintergrundaufgaben. Senden Sie dabei keine Passwörter. Gemeinsam lässt sich klären, welche Bestandteile zuerst geprüft werden müssen und wer den Wechsel verantwortet. Aus einer allgemeinen Warnung entsteht so ein nachvollziehbarer Arbeitsumfang mit einem überprüfbaren Zielzustand.

08 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 22. Oktober 2026 geprüft. Die verlinkten Primärquellen wurden am 22. Oktober 2026 geprüft. Konkrete Supportstände und Kompatibilitätsangaben müssen für den jeweiligen Umstellungstermin erneut gelesen werden. Das Beratungsunternehmen und das Arbeitsblatt sind fiktive eigene Beispiele.

  1. PHP: Supported Versions: Lebenszyklus mit aktiver Pflege, Sicherheitsunterstützung und Supportende. Abgerufen am 22. Oktober 2026.
  2. PHP Manual: The configuration file: Konfigurationswege und Unterschiede der Ausführungsumgebung. Abgerufen am 22. Oktober 2026.
  3. PHP Manual: Migrating from PHP 8.3.x to PHP 8.4.x: Beispiel einer versionsbezogenen Anleitung zu relevanten Änderungen. Abgerufen am 22. Oktober 2026.
  4. WordPress: Requirements: Empfohlene technische Grundlagen und Abgrenzung älterer Umgebungen. Abgerufen am 22. Oktober 2026.
  5. WordPress Core: PHP Compatibility and WordPress Versions: Versionsbezogene Kompatibilität des WordPress-Kerns und zugehöriger Kontext. Abgerufen am 22. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Hat Ihr Hosting ein PHP-Supportende angekündigt?

Nennen Sie Ihre Website und die angekündigte Änderung. Wir besprechen Anwendung, Laufzeiten und die nächsten sinnvollen Prüfschritte.

PHP-Wechsel besprechen