Choosing PhpStorm Plugins for Testing, Docker, SQL, GraphQL and OpenAPI Wisely

1. Criteria for a Sensible Plugin Selection

The most important question for any PhpStorm plugin is not "what can it do?" but "how often do I actually use this feature, and is the effort of using the native IDE function really higher than the performance overhead of the plugin?" Many plugins offer functionality that either already exists natively in PhpStorm, or that can just as easily be handled in a terminal. The criterion for a worthwhile plugin: it must either save time, avoid context switches, or reduce errors, and that benefit must outweigh the cost (memory, startup time, potential incompatibilities).

Concrete evaluation criteria: (1) Daily usage frequency, a plugin used once a week rarely justifies the overhead. (2) Context switching, does the plugin replace a browser tab or terminal switch, or does it duplicate a feature the IDE already has? (3) Stability risk, poorly maintained plugins with few updates can cause crashes during PhpStorm major upgrades. (4) Performance impact, plugins that run code on every keystroke or file save cost more than ones that are only active on demand.

A useful test: disable all non-essential plugins for a week and observe what you miss. Only re-enable the plugins that are genuinely missed. This often reduces the plugin list to a third of its original size and noticeably improves IDE performance.

2. Testing Plugins: PHPUnit, Code Coverage and Pest

PhpStorm has native PHPUnit support built in, no additional plugins needed. Tests can be started directly from the IDE, a green/red bar shows the result, and double-clicking a failed test jumps straight to the test method. Code coverage is activated via the coverage mode of the run configuration and shown as a visual marker in the editor: green lines were executed, red ones were not. This workflow works out of the box without a plugin.

For Pest (the newer PHP testing framework) there is a PhpStorm plugin that adds syntax highlighting and specific run configurations. Since Pest is internally built on top of PHPUnit, basic test execution works even without the plugin, but with the Pest plugin PhpStorm recognizes Pest-specific syntax (it(), describe(), expect()) and offers matching autocompletion. For projects that actively use Pest, the plugin is worthwhile.

// PHPUnit run configuration in PhpStorm, no plugin needed
// Run → Edit Configurations → + → PHPUnit

// Configuration for 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

// Start PHPUnit with coverage:
// Run → Run 'Unit Tests' with Coverage
// → Opens coverage results in the Coverage window
// → Green/red markers in the editor

// Pest-specific tests (with the Pest plugin):
test('Product has the correct name', function () {
    // PhpStorm with plugin: syntax highlighting + autocomplete for expect()
    expect($product->getName())->toBe('Test Product');
});

// describe/it blocks are recognized as test groups
describe('ProductRepository', function () {
    it('returns null when the product does not exist', function () {
        expect($repository->getById(999999))->toBeNull();
    });
});

Important for the PhpStorm testing workflow: the run configuration must use the remote interpreter, not the local PHP. Only then do tests run in the same container as the web server, with the same environment variables and the same database connection. A common mistake: tests run locally with the system PHP and fail in the container because extensions or environment variables are missing.

3. Docker Plugins: Services, Logs and Container Integration

PhpStorm Ultimate has native Docker support built in: the Services window shows all Docker Compose services, allows starting/stopping, shows container logs, and lets you open a shell inside the container. For the basic Docker workflow no additional plugin is needed.

The core feature of native Docker integration in PhpStorm is remote interpreter support: PhpStorm can run PHP directly inside the Docker container and use it as the interpreter for quality tools, PHPUnit, and external tools. That is the foundation for CI parity. For more specific Docker workflows, such as visualizing container networks or more complex Compose management, the Docker plugin (if not already included in the Ultimate edition) is a worthwhile addition.

4. SQL and Database Tools: What Comes Built In

PhpStorm Ultimate includes the Database Tools and SQL feature natively, with no additional plugins. It lets you manage database connections, run SQL queries directly, visualize EXPLAIN plans, and inspect table structures. For Magento development this means: connect to the MySQL database inside the Docker container directly from PhpStorm and test queries, without opening a separate tool like TablePlus or phpMyAdmin.

Configuring a MySQL connection to the Docker container is done through the Database Tool window: new data source entry, host set to localhost, port set to the mapped MySQL port (usually 3306 or 3307 with Mark Shust), database and credentials taken from the .env file. PhpStorm automatically loads the schema information and offers SQL autocompletion with table and column names. This saves manually searching for table names in the Magento documentation.

-- SQL directly in the PhpStorm Database Console
-- With native Database Tools support, no plugin needed

-- Magento entity-attribute-value query
-- PhpStorm offers autocomplete for table and column names
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;

-- Visualizing the EXPLAIN plan:
-- Place cursor in the query, then Database → Explain Plan
-- → PhpStorm shows the query plan as a tree structure
-- → Expensive steps are highlighted in color

-- Query history: all executed queries are in the History tab
-- → Useful for debugging without keeping a separate log

Useful but often unknown: PhpStorm can recognize SQL queries directly inside PHP strings if the string is marked as SQL (language injection). SQL syntax highlighting and autocompletion then also apply inside PHP code strings, for example in Magento collection queries or raw SQL calls. Language injection is activated via a comment: /** @lang MySQL */ before the string.

5. GraphQL Plugins for Magento and APIs

Magento 2 has a full GraphQL API. The PhpStorm plugin JS GraphQL (JetBrains) provides syntax highlighting for .graphql and .gql files, schema introspection (automatically loading the schema from the server), query validation against the schema, and autocompletion for field names, arguments, and types. For Magento teams developing or testing GraphQL queries, this plugin is indispensable.

Schema configuration happens in a .graphqlconfig file in the project. The plugin loads the schema either from a local schema.graphql file or directly via introspection from the GraphQL endpoint. With the Magento endpoint http://mironsoft.local/graphql, all Magento-specific types, queries, and mutations become instantly available in autocompletion. A typo in a field name is flagged immediately, before the query is even executed.

6. OpenAPI and REST Client in PhpStorm

PhpStorm Ultimate includes a built-in HTTP client that reads .http files and executes HTTP requests directly from the IDE. This is very handy for REST API testing: define requests in a file, run them, and see the response right inside the IDE. For Magento's REST API this means: fetch an admin token, create products, query orders, all from PhpStorm without a browser or Postman.

For OpenAPI/Swagger specifications, the OpenAPI Specifications plugin (JetBrains) offers syntax validation, autocompletion in openapi.yaml and swagger.json files, and a preview view. For teams that document their own APIs or maintain external API specifications in the project, this plugin is worthwhile. For pure API consumers who do not maintain specifications themselves, the added value is small.

### Magento REST API, HTTP Client in PhpStorm
### File: .phpstorm.http/magento-api.http
### Run: click the green play icon next to the request line

# Environment variables in http-client.env.json or http-client.private.env.json
# (private.env.json is in .gitignore, used for tokens and credentials)

# 1. Fetch admin token
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 received", function() {
    client.assert(response.status === 200, "Expected status 200");
  });
%}

###

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

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

The HTTP client supports scripts after the response, environment variables from http-client.env.json, and configurable environments (local, staging, production). http-client.private.env.json holds sensitive data such as tokens and passwords and should be listed in .gitignore. The http-client.env.json file with base URLs and non-sensitive variables can be committed to the repository.

7. Magento-Specific Plugins

The Magento PhpStorm plugin (officially supported by JetBrains) is the most important plugin for Magento developers. It provides: navigation in di.xml preferences and plugins, autocompletion for layout XML handles and block classes, recognition of Magento-specific PHPDoc annotations and templates, and links between ViewModel classes and their phtml templates. Without this plugin, IDE navigation is missing for a large part of the Magento-specific architecture.

The .env Files Support plugin (JetBrains) is worthwhile for any project with .env files. It provides syntax highlighting, validation, and autocompletion for environment variables. With Magento's env.php and separate .env files for Docker, this is useful. The PHP Annotations plugin extends PhpStorm's native PHPDoc understanding with framework-specific annotations and is especially relevant for Magento because of the extensive annotations used in DI configurations.

8. Plugins You Should Disable

PhpStorm ships with a large number of preinstalled plugins meant for general use cases that are not needed in specialized PHP projects. The following plugins can usually be disabled for a Magento PHP backend project without any loss of functionality: Spring Framework, Go support, Kubernetes, Python, Ruby, Scala. These are meant for non-PHP ecosystems and only add overhead.

The following JavaScript-related plugins can also be disabled if you work exclusively on PHP backend code and develop the JavaScript frontend separately: Angular, React, Vue.js Plugin, Svelte. PhpStorm has native JavaScript support, and these framework-specific plugins are only needed when you actively develop in those frameworks. For a Magento project with a Hyva theme, the Alpine.js plugin can be worthwhile because it recognizes Alpine directives in template files.

9. Plugin Comparison: Value vs. Cost

The table below rates the most important plugins for PHP/Magento teams by value and cost. "Value" refers to the day-to-day productivity gain, "cost" refers to memory, startup time, and maintenance effort.

The rule for plugin management: less is more. A cleanly configured PhpStorm with ten deliberately chosen plugins is more productive than one with thirty plugins where half are never used. An annual "plugin audit", going through all plugins and uninstalling the ones not used, is a sensible maintenance step for any development workstation setup.

10. Summary

A sensible plugin selection in PhpStorm follows clear criteria: daily usage frequency, avoiding context switches, and performance impact. For PHP/Magento teams the essentials are: the Magento PhpStorm plugin for DI navigation and layout XML support, JS GraphQL when actively developing GraphQL, the natively included Database Tools for SQL, and the HTTP Client for REST API testing. PHPUnit, code coverage, and Docker integration are natively included in PhpStorm Ultimate, no additional plugin needed.

Plugins that should be disabled: all framework-specific plugins for ecosystems outside PHP (Spring, Go, Kubernetes, Angular, Vue, and so on). The time spent on the initial plugin evaluation and disabling unused plugins pays for itself daily through faster startup times and better IDE performance. The plugin decision is not a one-time affair, every PhpStorm major update is worth revisiting, since JetBrains regularly builds in natively what used to require plugins.

11. FAQ: PhpStorm Plugins for Testing, Docker, SQL, GraphQL, OpenAPI