Ein frisch eingerichtetes PHPStorm ohne Checkliste kostet Stunden: falsche Interpreter, zu viel indexierte Vendor-Masse, kein Xdebug, keine Run Configurations. Diese Checkliste deckt alle kritischen Einstellungen ab – in der Reihenfolge, die für Docker-Magento-Projekte am meisten bringt.
PhpStorm-Refactorings sind mächtig, aber nicht unfehlbar. Rename funktioniert hervorragend in statisch typisierten Kontexten, scheitert aber bei Magento-Magic-Methods. Extract Method produziert sauberen Code, kann aber bei Closures und Generators überraschen. Ein ehrlicher Blick darauf, was sicher ist und was gründliches manuelles Nachprüfen erfordert.
Wer Quality Gates erst in der CI-Pipeline erfährt, verliert Minuten oder Stunden auf Feedback-Schleifen, die lokal in Sekunden lösbar gewesen wären. PHPStan, PHPUnit, PHPCS und Rector lassen sich in PhpStorm so integrieren, dass Fehler schon beim Speichern sichtbar werden – ohne die Kommandozeile zu verlassen.
Magento 2 bringt eine eigene Testinfrastruktur mit, die sich erheblich von einem Standard-PHPUnit-Projekt unterscheidet. Wer Integrationstests direkt aus PHPStorm starten, Coverage-Berichte in der IDE sehen und einzelne Testmethoden mit einem Klick debuggen will, braucht spezifische Konfigurationen – die dieser Artikel vollständig abdeckt.
Jedes Plugin erhöht den Speicherbedarf, verlängert den Start und kann die IDE verlangsamen. Die Frage ist nicht welche Plugins existieren, sondern welche für den eigenen Workflow wirklich einen Mehrwert bringen – und welche man ohne Verlust deaktivieren kann.
PHP-Teams schreiben täglich dieselben Boilerplate-Muster: ViewModels mit Constructor Property Promotion, Service-Interfaces mit Repository-Konventionen, PHPDoc-Blöcke für Magento-Klassen. Live Templates und Postfix Templates in PhpStorm reduzieren diese repetitiven Schreibaufgaben auf wenige Tastendrücke – und können als Team-Bibliothek geteilt werden.
Remote-Entwicklung in PhpStorm ist mehr als SFTP-Upload und Hoffen. Mit dem richtigen SSH-Setup, einem konfigurierten Remote-Interpreter, Port-Forwarding für Xdebug und dem JetBrains-Remote-Development-Modus kann man auf entfernten Servern mit derselben IDE-Erfahrung arbeiten wie lokal.
Ein Docker-Compose-Projekt mit PHP-Container, MySQL, Redis und Nginx ist schnell gestartet – aber PHPStorm vollständig zu integrieren, sodass Interpreter, Debugger, Datenbank-Datasource und Composer aus der IDE heraus funktionieren, erfordert gezielte Konfiguration an mehreren Stellen.
Der Plugin-Marktplatz von PHPStorm enthält Dutzende Plugins, die Magento-Entwicklung versprechen zu vereinfachen. In der Praxis bringen viele davon kaum Mehrwert, verlangsamen die IDE spürbar oder sind für Hyvä-Projekte schlicht irrelevant. Dieser Artikel trennt die echten Produktivitäts-Booster von den Ressourcenfressern.
PHPStorm kennt drei Interpreter-Typen: lokal, Docker/Docker Compose und SSH. Die Wahl hat direkte Auswirkungen auf Autocomplete-Qualität, Xdebug-Zuverlässigkeit und den Overhead beim Starten von Run Configurations. Dieser Artikel erklärt die Unterschiede und zeigt, wann welches Setup wirklich besser ist.