PHP-Entwickler in München

Ich bin Mariusz Szatkowski, ein einzelner PHP-Entwickler aus Gdynia in Polen, und arbeite seit 2006 mit PHP und WordPress. Wer in München nach PHP-Programmierung sucht, bekommt von mir keine Agentur mit Projektleitung, sondern jemanden, der den Code selbst schreibt. Ich arbeite remote und schriftlich.

Diese Seite hat einen Anlass: PHP 8.2 läuft am 31. Dezember 2026 aus. Sie finden hier einen Plan für den Wechsel, die Pflegefristen von Laravel und Symfony, den Composer-Audit als laufende Kontrolle, was das Bayerische Landesamt für Datenschutzaufsicht von Ihren Systemen erwartet und wie ein PHP-Projekt mit mir abläuft.

#Wie sich die Lage der Münchner Betriebe auf PHP-Projekte auswirkt

Die IHK für München und Oberbayern hat im September 2026 ihre Mitglieder befragt, für die Region München im Zeitraum vom 14. bis 25. September. Nach dem Konjunkturbericht Herbst 2026 liegt der Konjunkturindex bei 108 Punkten und damit unter dem Langzeitdurchschnitt von 118. Mehr als zwei Drittel der Unternehmen, genau 68 Prozent, sind unzufrieden mit den wirtschaftspolitischen Rahmenbedingungen, ein Rekordwert seit Beginn der Erhebung. 23 Prozent wollen ihre Investitionen ausweiten, 20 Prozent zurückschrauben.

Daraus lese ich für PHP-Projekte: Neue große Vorhaben werden vorsichtiger angegangen, die vorhandene Software muss aber weiterlaufen. Ein Versions-Upgrade mit festem, schriftlich vereinbartem Umfang passt in so eine Lage besser als ein offenes Neubauprojekt. Es verhindert, dass eine Anwendung ab Januar 2027 auf einer Version ohne Sicherheitskorrekturen läuft.

Foto: Rufus46, CC BY-SA 3.0, Wikimedia Commons.

Am 27. Januar 2027 lädt die IHK gemeinsam mit dem Bayerischen Staatsministerium des Innern und dem Staatsministerium der Justiz zum Cybersecurity Day in die Max-Joseph-Straße 2 ein, von 10 bis 16 Uhr, mit kostenloser Anmeldung. Wer dort Fragen zur eigenen Anwendung mitnimmt, kann sie mir danach schriftlich schicken.

#PHP 8.2 endet am 31. Dezember 2026: ein Upgrade-Plan

Die Daten stammen aus der Übersicht auf php.net. Heute, am 11. November 2026, sind es noch 50 Tage bis zum Ende der Sicherheitsunterstützung für 8.2.

PHP 8.1 und älter stehen nicht mehr in der Tabelle und erhalten keine Korrekturen mehr. Ich empfehle als Ziel in den meisten Fällen PHP 8.4. Es ist nicht das neueste, aber es hält Sicherheitskorrekturen bis Ende 2028 bereit, und die meisten Pakete haben es inzwischen im Test.

So gehe ich bei einem Wechsel vor:

1. Bestandsaufnahme. Ich lese composer.json und composer.lock, die Liste der PHP-Erweiterungen auf dem Server und die Konfiguration von PHP-FPM. Ergebnis ist eine Tabelle: Paket, heutige Version, Mindestversion von PHP für die nächste Paketversion.
2. Sicherheitsstand. composer audit läuft gegen die Sperrdatei. Findet es etwas, steht das als eigener Punkt in der Liste.
3. Warnungen sichtbar machen. Auf der Testumgebung läuft die Anwendung mit error_reporting = E_ALL und einem Log, das Deprecations sammelt. Die Tests laufen gegen die Zielversion.
4. Statische Analyse. PHPStan prüft den eigenen Code gegen die Zielversion. Das findet Stellen, die kein Test berührt.
5. Umbau in kleinen Commits. Jede Änderung ist ein eigener Commit im Pull Request. So lässt sich einzeln zurücknehmen, was nicht passt.
6. Umstellung. Erst Testumgebung, dann Produktion, mit einem vorher besprochenen Rückweg.

Was das PHP-Handbuch in den Migrationsleitfäden als veraltet führt, trifft erfahrungsgemäß ältere Codebasen zuerst:

• Ab PHP 8.2: Das Anlegen dynamischer Eigenschaften ist veraltet, außer die Klasse nutzt #[\AllowDynamicProperties]. Das Handbuch nennt als bevorzugten Weg, die Eigenschaft zu deklarieren. Auch die Interpolation mit "${var}" ist veraltet (Migration 8.2).
• Ab PHP 8.4: Ein Parameter mit Typ und null als Standardwert, etwa T1 $a = null, gilt als implizit nullable und ist veraltet. Richtig ist ?T1 $a = null. Veraltet ist außerdem trigger_error() mit E_USER_ERROR (Migration 8.4).
• Ab PHP 8.5: Die Cast-Namen (boolean), (integer), (double) und (binary) sind veraltet, ebenso der Backtick-Operator als Alias für shell_exec() und ein Semikolon statt Doppelpunkt hinter case (Migration 8.5).

Rector kann viele dieser Muster automatisch umschreiben. Ich prüfe jedes Ergebnis von Hand, bevor es in den Pull Request kommt.

#Laravel und Symfony: welche Version noch gepflegt wird

Die Laravel-Dokumentation nennt für alle Versionen 18 Monate Fehlerkorrekturen und zwei Jahre Sicherheitskorrekturen (Support Policy). Für Symfony gibt die Seite zu den Releases die Daten je Zweig.

Zwei Folgerungen für Münchner Anwendungen:

Laravel 11 hat keine Sicherheitskorrekturen mehr. Wer noch auf 11 läuft, hat seit dem 12. März 2026 keinen Schutz, unabhängig von der PHP-Version. Hier ist das Framework-Upgrade dringlicher als der PHP-Wechsel.

Symfony 8.1 ist eine Zwischenversion. Nach symfony.com erscheinen kleinere Versionen im Mai und November, und 8.1 wird nur bis Ende Januar 2027 gepflegt. Symfony 8.2 soll im November 2026 erscheinen. Wer langfristig planen will, bleibt auf der LTS-Linie 7.4, die mit PHP 8.2 läuft und drei Jahre Fehler- und Sicherheitskorrekturen bekommt. Der Weg von 6.4 auf 7.4 geht über die Deprecation-Hinweise von 6.4, nicht über einen Sprung ohne Zwischenstand.

#Composer-Audit als Dauerkontrolle

Ein Versionswechsel ist ein Ereignis, Sicherheit ist ein Zustand. Deshalb gehört composer audit in die Pipeline und nicht in ein einmaliges Projekt. Nach der Composer-Dokumentation prüft der Befehl die installierten Pakete gegen die Sicherheitsmeldungen der Packagist-API und erkennt auch aufgegebene Pakete und solche, die als Schadsoftware markiert sind. Er liefert Exit-Code 0 ohne Befund und 1 bei Funden. Mit --locked prüft er die Sperrdatei statt des Ordners vendor, mit --no-dev lässt er Entwicklungspakete aus.

In der Konfigurationsdokumentation steht außerdem, dass Composer Paketversionen mit bekannten Sicherheitsmeldungen standardmäßig nicht mehr bei update, require und remove zulässt, solange die Meldung nicht ausdrücklich ignoriert wird.

Eine Zeile in der CI reicht als Anfang:

composer audit --locked --no-dev

Schlägt sie fehl, bricht der Build ab. Ich trage Ausnahmen mit Begründung in die composer.json ein, damit später nachvollziehbar ist, warum eine Meldung ignoriert wurde.

#Was das BayLDA von Ihrer Software erwartet

Für private Unternehmen, Freiberufler und Vereine in Bayern ist das Bayerische Landesamt für Datenschutzaufsicht die Aufsichtsbehörde. Es erreichen es täglich Meldungen bayerischer Firmen über Cybervorfälle, schreibt die Behörde auf ihrer Seite zur Cyberfestung. Sie reichen von kompromittierten E-Mail-Konten bis zu Verschlüsselung und Erpressung.

Die dazugehörige Checkliste führt zehn Punkte nach Art. 32 DSGVO. Punkt 9 heißt Software-Updates durchführen und verlangt unter anderem:

• einen Patch-Management-Plan, der Identifikation, Priorisierung, Tests und Einspielen umfasst,
• eine vollständige Übersicht der eingesetzten Software mit Versionsständen und Patch-Levels,
• eine dedizierte Testumgebung, auf der Patches vor der Produktion laufen,
• eine Priorisierung nach Schwere der Lücke, etwa über den CVSS-Score.

Das deckt sich mit dem Plan oben. Die Bestandsaufnahme aus composer.lock ist genau diese Übersicht, und die Testumgebung ist ohnehin mein Standard. Ich stelle Ihnen die Tabelle als Datei bereit, die Sie Ihrer Datenschutzdokumentation beilegen können. Ob sie für Ihre Pflichten genügt, beurteilt Ihre Datenschutzberatung.

Drei Einzelheiten aus den BayLDA-Seiten, die für Software wichtig sind:

• Datenpanne. Der Online-Service richtet sich an Verantwortliche und ist auf die 72-Stunden-Frist nach Art. 33 DSGVO ausgelegt. Wer das Risiko noch nicht abschließend bewertet hat, kann eine vorläufige Meldung abgeben und später per Folgemeldung ergänzen. Nach dem Absenden erhält der Meldende eine Kennung, die als erster Nachweis des Meldezeitpunkts dient. Ihre Anwendung sollte Protokolle liefern, aus denen sich Umfang und Zeitpunkt eines Vorfalls ablesen lassen.
• Datenschutzbeauftragte. Nach Art. 37 Abs. 7 DSGVO sind sie der Aufsichtsbehörde zu melden, wofür das BayLDA ein Portal betreibt. Zur Pflicht, überhaupt eine Person zu benennen, sagt § 38 BDSG: in der Regel ab 20 Personen, die ständig mit automatisierter Verarbeitung personenbezogener Daten beschäftigt sind.
• Befugnisse. Das BayLDA darf Auskünfte verlangen, Unterlagen einsehen und nach Art. 58 DSGVO Anordnungen erlassen. Eine Anwendung, deren Versionsstand niemand belegen kann, ist dabei ein Nachteil.

#Cyber Resilience Act: wann er Software-Anbieter betrifft

Wer Software als Produkt an andere liefert, sollte den Cyber Resilience Act kennen. Die IHK München fasst auf ihrer CRA-Seite die Termine zusammen: Seit dem 11. September 2026 gilt die Meldepflicht für Schwachstellen und Sicherheitsvorfälle über die zentrale Plattform der ENISA, und ab dem 11. Dezember 2027 müssen neue Produkte alle Anforderungen erfüllen. Für die deutsche Umsetzung liegt laut IHK seit dem 1. Mai 2026 ein Regierungsentwurf vor.

Ob eine interne Fachanwendung oder ein Online-Dienst unter den CRA fällt, entscheidet nicht diese Seite, sondern Ihre Rechtsberatung. Technisch hilft in jedem Fall dasselbe: eine saubere Liste aller Abhängigkeiten, ein Prozess für Sicherheitsmeldungen und Updates, die belegbar eingespielt werden. Die IHK verweist unter anderem auf das Projekt CRA-COMPASS der TU München und des Fraunhofer AISEC.

#E-Rechnung: Archivierung und Berichtigung in Ihrer Anwendung

Ob Ihre Anwendung XRechnung oder ZUGFeRD ausgeben kann, ist die erste Frage. Die zweite wird oft vergessen: Was passiert danach mit dem Dokument?

• Aufbewahrung. § 14b Abs. 1 UStG (gesetze-im-internet.de) verlangt acht Jahre für ein Doppel jeder ausgestellten und jede erhaltene Rechnung. Die Frist beginnt mit dem Schluss des Kalenderjahres der Ausstellung. Nach den FAQ des Bundesfinanzministeriums ist bei einer E-Rechnung zumindest der strukturierte Teil unversehrt in der ursprünglichen Form aufzubewahren. Ein bloßes PDF-Abbild ersetzt ihn nicht.
• Berichtigung. Das BMF schreibt, technisch sei noch nicht festgelegt, mit welchem Rechnungstyp ersetzende oder kumulierende Berichtigungen und kaufmännische Gutschriften darzustellen sind. Entscheidend sei, dass sich aus Ursprungsrechnung und Berichtigungen der tatsächliche Inhalt klar ergibt. Eine Korrektur in einer Folge-Rechnung ist zulässig, wenn sie sich eindeutig auf die ursprüngliche bezieht.
• Folgen bei Verstößen. Nach Auffassung der Finanzverwaltung ist es keine Ordnungswidrigkeit nach § 26a UStG, wenn eine Rechnung entgegen der Pflicht nicht als E-Rechnung ausgestellt wird. Der Empfänger hat aber einen zivilrechtlichen Anspruch auf eine E-Rechnung.

Für Ihre Datenbank heißt das: Rechnungen werden unveränderlich gespeichert, Korrekturen sind eigene Belege mit Verweis, und der Export für die Steuerberatung liest das strukturierte Original und nicht eine Neuberechnung. Steuerliche Fragen klären Sie mit Ihrer Steuerberatung, die technische Umsetzung übernehme ich.

#Was ich für Münchner Unternehmen baue

• Versions-Upgrades von PHP und Framework nach dem Plan oben, mit schriftlicher Aufwandsliste vorab.
• Laravel-Anwendungen: Fachanwendungen, Kundenportale, Verwaltungsoberflächen, Warteschlangen für Hintergrundaufgaben.
• Symfony-Systeme mit vielen Schnittstellen und langer Laufzeit, auf der LTS-Linie.
• Anbindungen an Buchhaltung, Warenwirtschaft, Versand und Zahlungsdienste, mit Wiederholung bei Ausfall und nachvollziehbarem Protokoll.
• Altcode: schrittweise Umstellung, Modul für Modul, mit Tests um das bisherige Verhalten.
• Prüfung vorhandener Anwendungen mit einem schriftlichen Befund zu Version, Abhängigkeiten und Auffälligkeiten.

WordPress und WooCommerce behandle ich auf eigenen Seiten, etwa WordPress-Entwickler München. Hier geht es um PHP-Anwendungen ohne WordPress. Gehört zu Ihrer Anwendung ein Frontend in React, passt Next.js-Entwickler München. Für laufende Updates nach dem Livegang gibt es Wartung und Support in München.

#Ablauf: vom ersten Schreiben bis zur Übergabe

1. Anfrage. Sie beschreiben kurz Ziel, Termin und Stand. Hilfreich sind die Ausgaben von php -v und composer show.
2. Rückfragen. Meine technischen Fragen stelle ich schriftlich. Code lese ich, soweit Sie ihn freigeben.
3. Umfang und Annahmen. Ich halte schriftlich fest, was zum Auftrag gehört, was nicht und wovon ich ausgehe. Später Auftauchendes schätze ich getrennt.
4. Umsetzung auf Staging. Sie sehen den Stand auf einer Testumgebung. Jede Änderung hat einen Commit im Pull Request Ihres Repositories.
5. Abnahme. Sie prüfen gegen die vereinbarten Kriterien, Mängel behebe ich vor dem Livegang.
6. Übergabe. README, Deployment-Hinweise und eine Liste der Konfigurationswerte, Zugangsdaten bleiben draußen. Auf Wunsch folgt eine laufende Betreuung.

Layouts, Mockups und Grafik kommen von Ihnen. Haben Sie keine Vorlage, schicke ich Ihnen eine Tabelle, in der Sie je Ansicht markieren, welche Elemente wohin gehören.

#Was ich für den Start brauche

#Checkliste: Ihre PHP-Anwendung vor dem Jahreswechsel

• Steht fest, auf welcher PHP-Version die Produktion läuft, und ist sie 8.3 oder neuer?
• Läuft composer audit --locked ohne Befund, oder gibt es begründete Ausnahmen?
• Steht Laravel auf 12 oder 13, Symfony auf 6.4, 7.4 oder neuer?
• Gibt es eine Testumgebung, die der Produktion in PHP-Version und Erweiterungen entspricht?
• Liegt eine Übersicht aller Pakete mit Versionsstand vor, wie sie das BayLDA in Punkt 9 der Cyberfestung beschreibt?
• Werden Rechnungen im strukturierten Format unveränderlich acht Jahre gespeichert?
• Hat jemand eine Datenpanne einmal bis zum Meldeformular durchgespielt?

#Häufige Fragen

#Bis wann bekommt PHP 8.2 noch Sicherheitskorrekturen?

Nach php.net bis zum 31. Dezember 2026. PHP 8.3 wird bis zum 31. Dezember 2027 gepflegt, PHP 8.4 bis zum 31. Dezember 2028 und PHP 8.5 bis zum 31. Dezember 2029. Ab dem 1. Januar 2027 schließt für 8.2 niemand mehr neu bekannt gewordene Lücken.

#Reicht ein Update auf PHP 8.3, oder sollte ich direkt auf 8.4 oder 8.5 gehen?

Für die meisten Anwendungen ist 8.4 der vernünftige Zielpunkt, weil php.net dafür Sicherheitskorrekturen bis Ende 2028 zusagt. 8.3 verschafft Ihnen nur ein Jahr. Welche Version tatsächlich geht, hängt von Ihren Paketen ab, und das lese ich zuerst aus der composer.lock.

#Was ist der Unterschied zwischen composer audit und einem Update?

Der Befehl composer audit prüft die installierten Pakete gegen bekannte Sicherheitsmeldungen und liefert den Exit-Code 1, wenn er etwas findet. Er ändert nichts. Das Update selbst ist ein getrennter Schritt, den ich auf der Testumgebung durchführe und mit Ihren Tests absichere.

#Wohin melde ich eine Datenpanne als Münchner Unternehmen?

Für nicht-öffentliche Stellen in Bayern ist das Bayerische Landesamt für Datenschutzaufsicht zuständig. Es bietet ein Online-Formular für Meldungen nach Art. 33 DSGVO. Ist das Risiko noch nicht bewertet, ist laut BayLDA auch eine vorläufige Meldung mit späterer Folgemeldung möglich.

#Muss meine Anwendung E-Rechnungen archivieren?

Ja, der Unternehmer muss nach § 14b UStG ein Doppel jeder ausgestellten und jede erhaltene Rechnung acht Jahre aufbewahren. Bei einer E-Rechnung ist nach den FAQ des Bundesfinanzministeriums zumindest der strukturierte Teil unversehrt in seiner ursprünglichen Form aufzubewahren.

#Treffen wir uns in München, oder telefonieren wir vorab?

Nein. Anfrage, Rückfragen, Umfang, Zugänge und Abnahme laufen schriftlich. Ich arbeite von Gdynia aus und komme nicht nach München.

#Schreiben Sie mir

Schicken Sie mir über das Kontaktformular die Adresse Ihrer Anwendung oder Ihres Repositories, das Ziel, Ihren Termin und den heutigen Stand: PHP-Version, Framework, Tests ja oder nein. Ich antworte mit einer Liste offener Fragen und danach mit einer schriftlichen Einschätzung. Diese erste Einschätzung kostet nichts, ein Auftrag folgt daraus nicht von selbst. Alle PHP-Leistungen ohne Städtebezug stehen auf der Seite PHP-Entwickler.