PhpStorm Plugins für Testing, Docker, SQL, GraphQL und OpenAPI sinnvoll auswählen

1. Kriterien für sinnvolle Plugin-Auswahl

Die wichtigste Frage bei jedem PhpStorm-Plugin ist nicht "was kann es?" sondern "wie oft nutze ich diese Funktion, und ist der Aufwand zur Nutzung der nativen IDE-Funktion wirklich höher als der Performance-Overhead des Plugins?" Viele Plugins bieten Funktionen, die entweder bereits nativ in PhpStorm vorhanden sind, oder die man genauso gut in einem Terminal erledigen kann. Das Kriterium für ein sinnvolles Plugin: Es muss entweder Zeit sparen, Kontext-Wechsel vermeiden oder Fehler reduzieren – und dieser Nutzen muss die Kosten (Speicher, Start-Zeit, potenzielle Inkompatibilitäten) überwiegen.

Konkrete Bewertungskriterien: (1) Tägliche Nutzungsfrequenz – ein Plugin das einmal pro Woche genutzt wird, rechtfertigt selten den Overhead. (2) Kontext-Wechsel – ersetzt das Plugin einen Browser-Tab oder Terminal-Wechsel, oder dupliziert es eine bereits vorhandene IDE-Funktion? (3) Stabilitätsrisiko – schlecht gewartete Plugins mit wenigen Updates können bei PhpStorm-Major-Upgrades zu Abstürzen führen. (4) Performance-Impact – Plugins die bei jedem Tastendruck oder Dateispeichern Code ausführen, kosten mehr als solche die nur auf Abruf aktiv sind.

Ein nützlicher Test: Alle nicht-essentiellen Plugins für eine Woche deaktivieren und beobachten, was man vermisst. Nur die Plugins reaktivieren die tatsächlich fehlen. Das reduziert die Plugin-Liste oft auf ein Drittel der ursprünglichen Anzahl und verbessert die IDE-Performance spürbar.

2. Testing-Plugins: PHPUnit, Code Coverage und Pest

PhpStorm hat native PHPUnit-Unterstützung eingebaut – keine zusätzlichen Plugins nötig. Tests lassen sich direkt aus der IDE starten, eine grüne/rote Leiste zeigt das Ergebnis, und Doppelklick auf einen fehlgeschlagenen Test springt direkt zur Testmethode. Code Coverage wird über den Coverage-Modus der Run Configuration aktiviert und als visuelle Markierung im Editor angezeigt: grüne Zeilen wurden ausgeführt, rote nicht. Dieser Workflow funktioniert out-of-the-box ohne Plugin.

Für Pest (das neuere PHP-Test-Framework) gibt es ein PhpStorm-Plugin das syntaktisches Highlighting und spezifische Run Configurations hinzufügt. Da Pest intern auf PHPUnit aufbaut, funktioniert die grundlegende Test-Ausführung auch ohne Plugin – aber mit dem Pest-Plugin erkennt PhpStorm die Pest-spezifische Syntax (it(), describe(), expect()) und bietet passende Autovervollständigung. Für Projekte die Pest aktiv nutzen ist das Plugin sinnvoll.

// PHPUnit Run Configuration in PhpStorm — kein Plugin nötig
// Run → Edit Configurations → + → PHPUnit

// Konfiguration für Magento-Unit-Tests:
// Test scope: Defined in the configuration file
// Configuration file: src/dev/tests/unit/phpunit.xml.dist
// Interpreter: Docker Compose → phpfpm (Remote Interpreter)
// Environment: MAGENTO_UNIT_TEST=1

// PHPUnit mit Coverage starten:
// Run → Run 'Unit Tests' with Coverage
// → Öffnet Coverage-Ergebnisse im Coverage-Window
// → Grüne/rote Markierungen im Editor

// Pest-spezifische Tests (mit Pest Plugin):
test('Produkt hat korrekten Namen', function () {
    // PhpStorm mit Plugin: Syntaxhighlighting + Autocomplete für expect()
    expect($product->getName())->toBe('Test Produkt');
});

// describe/it-Blöcke werden als Testgruppen erkannt
describe('ProductRepository', function () {
    it('gibt null zurück wenn Produkt nicht existiert', function () {
        expect($repository->getById(999999))->toBeNull();
    });
});

Wichtig für den PhpStorm-Testing-Workflow: Die Run Configuration muss den Remote-Interpreter verwenden, nicht das lokale PHP. Nur so laufen Tests im selben Container wie der Webserver, mit denselben Umgebungsvariablen und derselben Datenbank-Verbindung. Ein häufiger Fehler: Tests laufen lokal mit dem System-PHP und schlagen im Container fehl, weil Erweiterungen oder Umgebungsvariablen fehlen.

3. Docker-Plugins: Services, Logs und Container-Integration

PhpStorm Ultimate hat native Docker-Unterstützung eingebaut: das Services-Window zeigt alle Docker-Compose-Services, ermöglicht Start/Stop, zeigt Container-Logs und ermöglicht das Öffnen einer Shell im Container. Für den grundlegenden Docker-Workflow ist kein zusätzliches Plugin nötig.

Das Kernfeature der nativen Docker-Integration in PhpStorm ist der Remote-Interpreter-Support: PhpStorm kann PHP direkt im Docker-Container ausführen und als Interpreter für Quality Tools, PHPUnit und externe Tools verwenden. Das ist die Grundlage für CI-Parität. Für spezifischere Docker-Workflows – wie visuelle Darstellung von Container-Netzwerken oder komplexere Compose-Verwaltung – ist das Docker-Plugin (falls nicht bereits in der Ultimate-Edition enthalten) eine sinnvolle Ergänzung.

4. SQL und Database Tools: was nativ vorhanden ist

PhpStorm Ultimate enthält das Database Tools and SQL-Feature nativ, ohne zusätzliche Plugins. Damit lassen sich Datenbankverbindungen verwalten, SQL-Queries direkt ausführen, EXPLAIN-Plans visualisieren und Tabellenstrukturen inspizieren. Für Magento-Entwicklung bedeutet das: direkt aus PhpStorm die MySQL-Datenbank im Docker-Container verbinden und Queries testen, ohne ein separates Tool wie TablePlus oder phpMyAdmin zu öffnen.

Die Konfiguration einer MySQL-Verbindung zum Docker-Container erfolgt über das Database-Tool-Window: Neuer Datasource-Eintrag, Host auf localhost, Port auf den gemappten MySQL-Port (meist 3306 oder 3307 bei Mark Shust), Datenbank und Credentials aus der .env-Datei. PhpStorm lädt automatisch die Schema-Informationen und bietet SQL-Autocompletion mit Tabellen- und Spaltennamen. Das spart die manuelle Suche nach Tabellennamen in der Magento-Dokumentation.

-- SQL direkt in PhpStorm Database Console
-- Mit nativer Database Tools Unterstützung — kein Plugin nötig

-- Magento Entity-Attribute-Value Abfrage
-- PhpStorm bietet Autocomplete für Tabellen- und Spaltennamen
SELECT
    e.entity_id,
    e.sku,
    ev.value AS name,
    ea.attribute_code
FROM catalog_product_entity e
    JOIN catalog_product_entity_varchar ev
        ON e.entity_id = ev.entity_id
    JOIN eav_attribute ea
        ON ev.attribute_id = ea.attribute_id
WHERE ea.attribute_code = 'name'
  AND ea.entity_type_id = 4
ORDER BY e.entity_id DESC
LIMIT 20;

-- EXPLAIN PLAN visualisieren:
-- Cursor in die Query, dann Database → Explain Plan
-- → PhpStorm zeigt Query-Plan als Baumstruktur
-- → Teuer-Schritte werden farblich markiert

-- Query-History: alle ausgeführten Queries sind im History-Tab
-- → Nützlich für Debugging ohne Protokoll zu führen

Nützlich aber oft unbekannt: PhpStorm kann SQL-Queries direkt in PHP-Strings erkennen, wenn der String als SQL markiert ist (Language Injection). Dann gilt SQL-Syntax-Highlighting und Autocompletion auch innerhalb von PHP-Code-Strings – zum Beispiel in Magento-Collection-Queries oder Raw-SQL-Aufrufen. Language Injection wird über einen Kommentar aktiviert: /** @lang MySQL */ vor dem String.

5. GraphQL-Plugins für Magento und APIs

Magento 2 hat eine vollständige GraphQL-API. Das PhpStorm-Plugin JS GraphQL (JetBrains) bietet Syntax-Highlighting für .graphql- und .gql-Dateien, Schema-Introspection (automatisches Laden des Schemas vom Server), Query-Validierung gegen das Schema und Autovervollständigung für Feldnamen, Argumente und Typen. Für Magento-Teams die GraphQL-Queries entwickeln oder testen ist dieses Plugin unverzichtbar.

Die Schema-Konfiguration erfolgt in einer .graphqlconfig-Datei im Projekt. Das Plugin lädt das Schema entweder von einem lokalen schema.graphql-File oder direkt via Introspection vom GraphQL-Endpoint. Mit dem Magento-Endpoint http://mironsoft.local/graphql werden alle Magento-spezifischen Types, Queries und Mutations sofort in der Autocompletion verfügbar. Typo in einem Feldnamen wird sofort markiert, bevor die Query überhaupt ausgeführt wird.

6. OpenAPI und REST-Client in PhpStorm

PhpStorm Ultimate enthält einen integrierten HTTP-Client, der .http-Dateien liest und HTTP-Requests direkt aus der IDE ausführt. Das ist für REST-API-Tests sehr praktisch: Requests in einer Datei definieren, ausführen und die Antwort direkt in der IDE sehen. Für Magento's REST API bedeutet das: Admin-Token holen, Produkte erstellen, Orders abfragen – alles aus PhpStorm ohne Browser oder Postman.

Für OpenAPI/Swagger-Spezifikationen bietet das Plugin OpenAPI Specifications (JetBrains) Syntax-Validierung, Autovervollständigung in openapi.yaml und swagger.json-Dateien und eine Preview-Ansicht. Für Teams die eigene APIs dokumentieren oder externe API-Spezifikationen im Projekt pflegen ist dieses Plugin sinnvoll. Für reine API-Konsumenten ohne eigene Spezifikations-Pflege ist der Mehrwert gering.

### Magento REST API — HTTP Client in PhpStorm
### Datei: .phpstorm.http/magento-api.http
### Ausführen: Klick auf grünes Play-Symbol neben der Request-Zeile

# Umgebungsvariablen in http-client.env.json oder http-client.private.env.json
# (private.env.json ist in .gitignore — für Tokens und Credentials)

# 1. Admin-Token holen
POST {{base_url}}/rest/V1/integration/admin/token
Content-Type: application/json

{
  "username": "{{admin_user}}",
  "password": "{{admin_password}}"
}

> {%
  client.global.set("admin_token", response.body.replaceAll('"', ''));
  client.test("Token erhalten", function() {
    client.assert(response.status === 200, "Status 200 erwartet");
  });
%}

###

# 2. Produkt erstellen
POST {{base_url}}/rest/V1/products
Content-Type: application/json
Authorization: Bearer {{admin_token}}

{
  "product": {
    "sku": "TEST-PHPSTORM-001",
    "name": "PhpStorm Test Produkt",
    "price": 29.99,
    "status": 1,
    "type_id": "simple",
    "attribute_set_id": 4
  }
}

Der HTTP-Client unterstützt Skripte nach der Response, Umgebungsvariablen aus http-client.env.json und konfigurierbare Environments (local, staging, production). http-client.private.env.json enthält sensitive Daten wie Tokens und Passwörter und sollte in .gitignore stehen. Das http-client.env.json mit Basis-URLs und nicht-sensitiven Variablen kann ins Repository committed werden.

7. Magento-spezifische Plugins

Das Magento PhpStorm-Plugin (offiziell von JetBrains unterstützt) ist das wichtigste Plugin für Magento-Entwickler. Es bietet: Navigation in di.xml-Preferences und Plugins, Autovervollständigung für Layout-XML-Handles und Block-Klassen, Erkennung von Magento-spezifischen PHPDoc-Annotations und Templates, und Links zwischen ViewModel-Klassen und ihren Phtml-Templates. Ohne dieses Plugin fehlt die IDE-Navigation für einen Großteil der Magento-spezifischen Architektur.

Das Plugin .env Files Support (JetBrains) ist für alle Projekte mit .env-Dateien sinnvoll. Es bietet Syntax-Highlighting, Validierung und Autovervollständigung für Umgebungsvariablen. Bei Magento mit env.php und separaten .env-Dateien für Docker ist das nützlich. Das Plugin PHP Annotations ergänzt PhpStorms natives PHPDoc-Verständnis um Framework-spezifische Annotations und ist für Magento besonders relevant wegen der umfangreichen Annotations in DI-Konfigurationen.

8. Plugins die man deaktivieren sollte

PhpStorm kommt mit einer Vielzahl vorinstallierter Plugins, die für allgemeine Anwendungsfälle gedacht sind aber in spezialisierten PHP-Projekten nicht benötigt werden. Folgende Plugins können für ein Magento-PHP-Backend-Projekt in der Regel deaktiviert werden ohne Funktionalitätsverlust: Spring Framework, Go-Unterstützung, Kubernetes, Python, Ruby, Scala. Diese sind für Nicht-PHP-Ökosysteme gedacht und tragen nur Overhead bei.

Auch folgende JavaScript-bezogene Plugins können deaktiviert werden wenn man ausschließlich an PHP-Backend-Code arbeitet und das JavaScript-Frontend separat entwickelt: Angular, React, Vue.js Plugin, Svelte. PhpStorm hat native JavaScript-Unterstützung, diese Framework-spezifischen Plugins sind nur nötig wenn man aktiv in diesen Frameworks entwickelt. Für ein Magento-Projekt mit Hyvä-Theme kann das Alpine.js-Plugin sinnvoll sein, weil es Alpine-Direktiven in Template-Dateien erkennt.

9. Plugin-Vergleich: Mehrwert vs. Kosten

Die folgende Tabelle bewertet die wichtigsten Plugins für PHP/Magento-Teams nach Mehrwert und Kosten. "Mehrwert" bezieht sich auf den täglichen Produktivitätsgewinn, "Kosten" auf Speicher, Start-Zeit und Wartungsaufwand.

Die Devise für Plugin-Management: weniger ist mehr. Ein sauber konfiguriertes PhpStorm mit zehn gezielt ausgewählten Plugins ist produktiver als eines mit dreißig Plugins von denen die Hälfte nie genutzt wird. Ein jährliches "Plugin-Audit" – alle Plugins durchgehen und Deinstallation nicht genutzter Plugins – ist eine sinnvolle Wartungsmaßnahme für jedes Entwicklungs-Workstation-Setup.

10. Zusammenfassung

Sinnvolle Plugin-Auswahl in PhpStorm folgt klaren Kriterien: tägliche Nutzungsfrequenz, Kontext-Wechsel-Vermeidung und Performance-Impact. Für PHP/Magento-Teams sind unverzichtbar: das Magento PhpStorm-Plugin für DI-Navigation und Layout-XML-Support, JS GraphQL bei aktiver GraphQL-Entwicklung, die nativ enthaltenen Database Tools für SQL und HTTP Client für REST-API-Tests. PHPUnit, Code Coverage und Docker-Integration sind nativ in PhpStorm Ultimate enthalten – kein zusätzliches Plugin nötig.

Plugins die deaktiviert werden sollten: alle Framework-spezifischen Plugins für Ökosysteme außerhalb PHP (Spring, Go, Kubernetes, Angular, Vue etc.). Der Zeitaufwand für die initiale Plugin-Bewertung und Deaktivierung nicht genutzter Plugins wird durch schnellere Start-Zeiten und bessere IDE-Performance täglich zurückgewonnen. Die Plugin-Entscheidung ist keine einmalige Angelegenheit – bei jedem Major-Update von PhpStorm lohnt eine erneute Überprüfung, da JetBrains regelmäßig Funktionen nativ einbaut die vorher Plugins brauchten.

11. FAQ: PhpStorm Plugins für Testing, Docker, SQL, GraphQL, OpenAPI