Repository navigation
wp-env: Add better default PHPunit settings, fix Xdebug, and update docs - #50490
Conversation
|
Size Change: +69 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
|
|
||
| ## Using `composer`, `phpunit`, and `wp-cli` tools. | ||
|
|
||
| For ease of use, Composer, PHPUnit, and wp-cli are available for in the environment. To run these executables, use `wp-env run <env> <tool> <command>`. For example, `wp-env run cli composer install`, or `wp-env run tests-cli phpunit`. You can also access various shells like `wp-env run cli bash` or `wp-env run cli wp shell`. |
There was a problem hiding this comment.
I worry that including wp-cli here makes it ambiguous. It feels like this is saying you should use wp-env run cli wp-cli <command>.
There was a problem hiding this comment.
That's a good point. I was trying to provide a search result if someone is looking to use wp-cli. And to actually use it, you have to do run cli wp... how do you think we should phrase it?
There was a problem hiding this comment.
Actually, I think this is fine. If you look at https://wp-cli.org, the official documentation has you using wp as the command. Anyone looking to use wp-cli will have that as the expectation I bet.
ObliviousHarmony
left a comment
There was a problem hiding this comment.
Thanks @noahtallen, this tests really well. I tried it out both with the web server and CLI, and in both cases, the debugger worked perfectly. I really like how easy it was to set this up. Once I had the VS Code plugin installed it worked completely out of the box.
|
Flaky tests detected in 1cac185. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4931877789
|
| const { loadConfig } = require( './config' ); | ||
| const buildDockerComposeConfig = require( './build-docker-compose-config' ); | ||
|
|
||
| const { ValidationError } = require( './config' ); |
There was a problem hiding this comment.
This can be combined with the above require() (shouldn't the linter have caught this?)
| // support PHP 7 when the environment uses that version. By default, use the | ||
| // latest version. | ||
| if ( majorVer === 7 ) { | ||
| xdebugVersion = 'xdebug-3.1.6'; |
There was a problem hiding this comment.
What do you think about using the support version table from Xdebug's website? We can pair each PHP minor release with a compatible version of Xdebug and then fall back to plain xdebug to grab the latest.
There was a problem hiding this comment.
Something like:
// Map the PHP version to a compatible Xdebug version.
const versionMap = {
'7.2': 'xdebug-3.1.6',
'7.3': 'xdebug-3.1.6',
'7.4': 'xdebug-3.1.6',
'8.0': 'xdebug-3.2.1',
};
const xdebugVersion = versionMap[ `${ majorVer }.${ minorVer }` ] ?? 'xdebug';
There was a problem hiding this comment.
I think it might be useful in the future, but I don't know if it provides any value right now -- we either use current (3.2), or previous (3.1). Outside of that, we'd be on 2.x, which would require config changes that would be hard to maintain
ObliviousHarmony
left a comment
There was a problem hiding this comment.
Looks good, sorry for the back and forth @noahtallen!
|
np, glad we got it in a good spot! |
|
The documentation says to run : But it fails because the container user does not write permission: Full output: |
|
What does |
|
It might also be the case that the environment hasn't been updated since the permission changes! One caveat that just occurred to me is that, technically, changes to |
True... I guess the assumption was that those files won't change unless the config changes! |
What?
.htaccessmapping and increasing default upload size to 1GB.Before:
After:
How?
Adjusts the dockerfiles we generate! This also changes Xdebug such that it's not installed in the CLI environments.
Testing Instructions
PHP settings
.htaccessfile (following the documentation), and verify those upload sizes override the default valuesXdebug
npx wp-env start --xdebuggutenberg.phpTesting Instructions for Keyboard
Screenshots or screencast