WordPress root directory with Docker
Just getting started with local dev environment. I have Docker up and running and I've configured PHPStorm to recognize it and I get a connection successful. But when I try to start a new plugin project, it wants a WordPress root directory. If I'm understanding correctly, the WP files are on a virtual volume that the Docker machine can access.
Theoretically, I want to only expose my plugin directory to my local machine - for speed reasons - correct?
Therefore, I don't have a WordPress Installation path with the wp-admin and wp-content directories available to PHPStorm.
Do I need to edit my docker-compose.yml to make the entire WordPress installation accessible locally or is there a way to tell PHPStorm to look in the virtual machine?
Please sign in to leave a comment.
Hello,
PhpStorm uses local WordPress installation to provide code assistance and completion for your project so we advise to have a local copy of WordPress for that. It can be outside of the project so you wouldn't sync it with your web server especially if WordPress is already there.
I managed to make the WordPress core visible to the IDE by defining a local volume in `docker-compose.yml` like this:
and configuring `./wp_data` as WordPress root in my PhpStorm settings.
This only worked one time. After applying the settings, the warnings about unknown built-in functions went away. But when opening the same project in PhpStorm later, the warnings are back, and no way to turn them off again.
Also, SonarLint warns about coding practices that are necessary to pass WordPress plugin code reviews, like prefixing function names with a prefix followed by a single underscore character. I had to disable the SonarLint S100 rule.
Expected behaviour: when we specify the WordPress core, SonarLint must not warn about "unknown" built-in functions anymore, even after restarting the IDE.
I found this tutorial to install a local WordPress code sniffer in PhpStorm: https://www.jetbrains.com/help/idea/using-php-code-sniffer.html#installing-configuring-code-sniffer
By the warnings, do you mean SolarLint results or built-in inspections too?
SolarLint is a third-party plugin, so we don't really know how it works. When it comes to built-in inspections, as long as the definitions are available in the project in some way, they should not complain about missing functions.
We can look at it closer if you submit a support ticket (Help | Contact Support).
Hi Eugene, thanks for your reply!
> By the warnings, do you mean SolarLint results or built-in inspections too?
From a user (developer) perspective, it is often hard to tell the origin of an inspection / warning, same problem with eslint / stylelint vs. built-in IDEA inspections. Also, it would be helpful, if "other actions" included an option to suppress the warning for the current line only, or a default syntax like /** inspections-disable-next-line $rule */ that should be respected by any kind of internal and external linters.
> We can look at it closer if you submit a support ticket (Help | Contact Support).
where can I open a ticket? Here, or in YouTrack? I can also add the repository URL and software versions.
Suppress for statementis supposed to do that. Doesn't it work this way for you?If you click Help | Contact Support in the IDE, it will redirect you to a form that will already have environment data pre-populated.
I am afraid it does not work all of the time, probably depending on which kind of linter or subsystem caused the warning.
For example, when I inspect a deprecation in a Symfony project, causing a warning "Annotations are deprecated", I have to go via "show context actions" -> "Inspection [Annotation] Annotations are deprecated options" to get a choice to
- disable inspection
- suppress for file
- suppress for PhpDoc
- suppress for file,
but no "suppress for this line" option.
Concerning the S100 case, I seemed to have disabled the S100 rule inspection altogether, so no chance to see the original options again.
I am currently blocked by a problem making the PHP CodeSniffer work with WordPress Coding Standards when both PHP 8 and PHP 7.4 are installed on the same system (see GitHub issue for the follow-up). Once I can continue to use WordPress code inspections again, I will follow-up on this problem again, and open a contact form based ticket issue if necessary.
Thank you for your support so far!