It would be nice if this listed out my available options:

To help plugin and theme authors detect PHP version compatibility issues in their codebase, it would be helpful to add the PHPCompatibility sniffs.

PHP nightly on travis is version 7.2 but the TRAVIS_PHP_VERSION var is still set to 'nightly' so:

if [[ ${TRAVIS_PHP_VERSION:0:2} == "7." ]]; then
        composer global require "phpunit/phpunit=5.7.*"
      else
        composer global require "phpunit/phpunit=4.8.*"
fi

results in the installation of 4.8.*.

Bash is foreign to me but I assume it should be possible to throw a secondary condition in there to also check for "nightly"?

Switch to wp-cli/wp-cli:dev-master after wp-cli/wp-cli#4024 has been merged.

The current gitlab-ci.yml file use the tetraweb/php on top of which it apt-get some stuff and then manually download WordPress core.

But having a prebuilt image would make builds much cheaper/quicker to request an image alredy containing all the needed stuff (zip, mysql, WordPress, ...). chriszarate/wordpress as an example.
It could even make most of before_script and bin/install-wp-tests.sh superfluous.
If no existing image fit the need, one wordpress-test-image repository + Dockerfile could be provided by wp-cli, built and provided by hub.docker.io.

Following up #31 I intend to use behat on a fully initialized and boostrapable WordPress instance.
For this to work the current bootstrap scripts are too phpunit-centric:
[ ] they rely upon phpunit presence (being run by phpunit)
[ ] they rely upon hardcoded value for host/port/... (issue with wp-config initialization)
[ ] they rely upon not calling wp()

Could we discuss this topic here?

In install-wp-tests.sh the tags directory of the core test suite is used. For example, calling install-wp-tests.sh <name> <user> <pass> <host> 4.7 results in the tags/4.7 directory of the test suite being checked out.

Ref:

The disadvantage of this is that any fixes which get made to the test infrastructure in branch point releases don't get picked up by the test install script. For example, specifying a WordPress version of 4.7 checks out the test suite for 4.7, but doesn't include the recent changes in 4.7.1 - 4.7.5.

In my User Switching plugin I changed install-wp-tests.sh so it uses the branch instead of the tag when a two-digit WordPress version number is specified.

if [[ $WP_VERSION =~ [0-9]+\.[0-9]+ ]]; then
	WP_TESTS_TAG="branches/$WP_VERSION"
elif [[ $WP_VERSION =~ [0-9]+\.[0-9]+\.[0-9]+ ]]; then
	WP_TESTS_TAG="tags/$WP_VERSION"

This means the test suite includes changes which have been backported to the 4.7 branch. The notable fix that was backported recently was support for PHPUnit 6+ which caused breakage all over the place.

Does it make sense to change the install-wp-tests.sh template to use this pattern?

php wp --info output:

OS:	Linux 4.9.60-linuxkit-aufs #1 SMP Mon Nov 6 16:00:12 UTC 2017 x86_64
Shell:
PHP binary:	/usr/local/bin/php
PHP version:	7.0.14
php.ini used:
WP-CLI root dir:	phar://wp-cli.phar
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/var/www/html
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	1.5.0

php wp cli version output:

WP-CLI 1.5.0

php -v output:

PHP 7.0.14 (cli) (built: Jan 17 2017 19:30:34) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.14, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans

When trying to scaffold the plugin tests I always get the error

Error: Couldn't find install-wp-tests.sh

Command which is executed:

php wp --allow-root --debug --path=/var/www/html/wp scaffold plugin-tests some-plugin

Output:

Debug (bootstrap): No readable global config found (0.326s)
Debug (bootstrap): No project config found (0.328s)
Debug (bootstrap): argv: ./wp/wp --allow-root --debug --path=/var/www/html/wp scaffold plugin-tests some-plugin (0.329s)
Debug (bootstrap): ABSPATH defined: /var/www/html/wp/ (0.329s)
Debug (bootstrap): Begin WordPress load (0.335s)
Debug (bootstrap): wp-config.php path: /var/www/html/wp/wp-config.php (0.337s)
Debug (bootstrap): Loaded WordPress (3.716s)
Debug (bootstrap): Running command: scaffold plugin-tests (3.717s)
Error: Couldn't find install-wp-tests.sh

Did I miss something with the wp-cli installation?

wp scaffold post-type accepts --dashicon=<dashicon> as an argument.

If I enter --dashicon=dashicon-info as my command, it seems sensible to strip my entered 'dashicon-' such that the end result is 'dashicon-info', not 'dashicon-dashicon-info'.

For the last couple of days I've been trying to get tests to work in themes. I test with a new theme with just a index.php, a style.css and a functions.php file. I have this function in functions.php:

function test_theme() {
    return 'hi';
}

And my test:

function test_sample() {
    // Replace this with some actual testing code.
    $this->assertTrue( true );
    $this->assertEquals( 'hi', test_theme() );
}

When I run the test, PHPUnit gives an error:

There was 1 error:

1) SampleTest::test_sample
Error: Call to undefined function test_theme()

Is there something simple I'm overlooking? For any debug info about my setup/system, please see #22.

Files generated by wp scaffold command are not WordPress coding standard compliant!

For example cpt generated:

wp-cli/wp-cli#4589

Block scaffolding exists via #88 and I think the current default is a sensible default, but a lot of us will need modern tooling. @ahmadawais has already built what a ESNext + Webpack option would need here:

https://github.com/ahmadawais/Gutenberg-Boilerplate/tree/master/block/02-basic-esnext

I can imagine that as opinions develop in the community about how to build blocks, this is likely to be come a templating system for different block types and workflows. So I'd like to propose a --template option.

When this option is false, which would be its default, then the current behaviour would happen. I also propose that one template esnext-webpack be created, based on Ahmad's boilerplate, to act as a reference implementation and also because there is an immediate need for it.

I think to make this happen the following would need to be done:

• Add a template argument to command, and add a template loader.
• Convert files to mustache syntax and place in templates directory

We should look into setting Behat up so that it can generate code through the scaffolding command and then runs that generated code through linters/sniffers to make sure that the end result adheres to all standards and best practices.

From #109 (comment)

So, I just used wp scaffold plugin for the first time and I was very impressed 😃

I took a look at the addtextdomain task and gave it a try. The result though was pretty confusing - I already had textdomains defined in most of my i18n functions and what I saw in the diff was that the textdomain of my plugin was just tacked onto the end of the __() call for instance.

I went on a search through the cedaro/grunt-wp-i18n repository and found out that some time ago they added a configuration option that allows you to replace all textdomains with the one specified in the addtextdomain.options.textdomain config.

Is it just me or is it a bit pointless to have addtextdomain only append the textdomain instead of having it replace any existing textdomains? This technically means that unless you package your plugin separately and always keep your working copy without textdomains you can only run grunt i18n once, otherwise you'll end up with an ever growing list of textdomains.

So, I think it would make sense to adjust the auto-generated Gruntfile.js so that addtextdomain.target config is replaced with this:

update_all_domains: {
	options: {
		updateDomains: true
	},
	src: [ '*.php', '**/*.php', '!node_modules/**', '!php-tests/**', '!bin/**' ]
}

Adding a composer.json template would encourage developers to make their plugins available via Packagist, and also allow local install of dependencies.

Currently, WPCS + PHPCS is made available via a global composer install here for Travis.

I haven't yet found a template for the plugin's composer.json, but adding WPCS + PHPCS + PHPCompatibility + DealerDirect/phpcodesniffer-composer-installer to a composer.json would make PHPCS runnable from local, without Travis.

Hello there,

I have submitted a pull request on sample-plugin to add tests on multiple PHP versions on circleci
wp-cli/sample-plugin#8

It also sets the phpunit version to 5.7.* to fix the error:
PHP Fatal error: Class 'PHPUnit_Framework_TestCase' not found

For more info on this issue, see https://core.trac.wordpress.org/ticket/39822

Thanks,
Carlos

Gutenberg blocks can optionally have a corresponding dynamic template that gets rendered server side. An example of this is the rendering of the Latest Posts block that's included in Gutenberg: https://github.com/WordPress/gutenberg/blob/5b85f851c3b132d6122979aa121bd24f74e73131/blocks/library/latest-posts/index.php

The wp scaffold block command should include a template for dynamic block rendering and can be appended to the bottom of block-php.mustache.

Example:

/**
 * Renders the `foo/bar` block server side.
 *
 * @param array  $attributes The saved block attributes.
 * @param string $content    The saved block content.
 * @return string Returns the post content with foo/bar block output added.
 */
function render_block_foo_bar( array $attributes, $content ) {
	$output = sprintf(
		'<hr>%s',
		$content
	);

	return $output;
}

register_block_type( 'foo/bar', array(
	'render_callback' => 'render_block_foo_bar',
) );

Ref: wp-cli/core-command#17

If the above gets implemented, the install-wp-tests.sh template should be updated in order to introduce a WP_VERSION=beta flag to support the same functionality in the scaffolding of the unit test suite.

So first time user of the wp scaffold block and I got a little confused by the readme. I assumed it would just make a block for me where ever I ran it. It took me a minute to figure out that a block has to belong to a plugin or theme, which makes a lot of sense, not questioning that. Just saying the documentation confused me. PR incoming.

A colleague of mine has been struggling with the format for scheduling a WP-Cron event and correctly passing parameters to its callback function. A WP-CLI command to scaffold an event and its callback function with example parameters would be great.

I'm going to put together an example and open a PR.

As mentioned in wp-cli/wp-cli#2119 (comment), you can't test against other WP versions than the version in the $WP_CORE_DIR directory. As I see it there are two reasons this exists.

• To not re-download WordPress again and again when using the install-wp-tests.sh command.
• For back compatibility with the $WP_CORE_DIR directory.

The $WP_CORE_DIR is an environment variable you can set to use an existing WordPress install for the PHPUnit tests. For back compatibility it's not expected the install-wp-tests.sh command installs other WordPress versions in that directory.

On the other hand when setting a specific $WP_VERSION it is expected you test your plugin against that WP version.

Would it be an Idea to add a flag --force-update to the install-wp-tests.sh command that allows you to update WP regardless if the $WP_CORE_DIR directory already exists?

On an unrelated note we could also convert the skip-database-creation argument to a flag, to not create too many arguments.

After wp-cli/wp-cli#3985 lands, we should revert 919320c

The scaffolded theme unit test files do not successfully load the theme as the active theme. This is due to what appears to be a core bug in register_theme_directory(), but which can be fixed in the test bootstrap file.

When the theme test suite bootstrap file calls register_theme_directory(), an entry is added to the $wp_theme_directories global. When WordPress attempts to load the active theme, it ultimately calls get_theme_roots() which first checks for a cached value in the theme_roots transient. This transient gets populated before the muplugins_loaded hook fires, which means calling register_theme_directory() at this point has no effect because it does not flush the theme_roots transient.

This bug can be worked around by calling delete_site_transient( 'theme_roots' ) after calling register_theme_directory() in the test suite bootstrap file.

Patch coming up.

Core issue: https://core.trac.wordpress.org/ticket/43228

Hello,

Today I tried using scaffold to create a block for gutenberg, I was using the --theme option. What me and my colleague found out is that the wp cli still implements plugin_url instead of something for the theme, and we have the following fix for it;

In code of the block e.g. 'blocks/my-custom-block.php'
Instead of:
$dir = dirname( __FILE__ );
Use:
$dir = get_template_directory() . '/blocks';

And instead of:
plugins_url( $block_js, __FILE__ ),
Use:
get_template_directory_uri() . "/blocks/$block_js",

The only thing you have to do next is go to your functions.php in the theme and paste this:
require( get_template_directory() . '/blocks/my-custom-block.php' );

I hope this helps some people out!

pluralize() isn't working perfectly, please see discussion on #44.
Should we add doctrine/inflector to composer dependencies and improve implementation of the pluralize()?

Related: #42 #44 #45

A number of the tests in features/install-wp-tests.feature assume that you can run mysql commands as root with no password, which is unlikely to be true locally.

It'd be better I think to use the standard wp_cli_test/password1 user/passsword and have people do GRANT ALL PRIVILEGES ON wp_cli_test_scaffold.* TO "wp_cli_test"@"localhost" IDENTIFIED BY "password1"; to get them to work locally (where using wp_cli_test_scaffold as the db name instead of the current wordpress_behat_test). PR incoming.

When making integration tests one may need additional plugins.

Pasting here my install-wp-tests-plugins.sh

#!/usr/bin/env bash

if (( $# < 1 )); then
	echo "usage: $0 <plugin[:version]> [plugin[:version]]..."
	exit 1
fi

let force=0
WP_CORE_DIR=${WP_CORE_DIR-/tmp/wordpress/}

download() {
    if [ `which curl` ]; then
        curl -s "$1" > "$2";
    elif [ `which wget` ]; then
        wget -nv -O "$2" "$1"
    fi
}

set -ex

install_plugins() {

	if [ ! -d $WP_CORE_DIR ]; then
		return;
	fi
	for PLUGIN in "$@"; do
	    if [[ -d "$WP_CORE_DIR/wp-content/plugins/${PLUGIN%:*}" ]] && (( ! $force )); then
		continue;
	    fi
	    [[ $x =~ : ]] && VERSION="${PLUGIN##*:}"
	    FILENAME="${PLUGIN%:*}.${VERSION:-latest-stable}"
	    download "https://downloads.wordpress.org/plugin/$FILENAME.zip" "$WP_CORE_DIR/wp-content/plugins/$FILENAME.zip"
	    unzip -q "$WP_CORE_DIR/wp-content/plugins/$FILENAME.zip" -d "$WP_CORE_DIR/wp-content/plugins/"
	done
}

install_plugins "$@"

NB:

• I didn't implement --force
• There may exists better way to handle that feature (wp-cli itself, composer.json, ...)

Hello,
I got this error on every plugin i try to wrap with tests
I use: wp scaffold plugin-tests some-plugin

and I'm getting error when I'm trying to run sh script:

bin/install-wp-tests.sh: 26: bin/install-wp-tests.sh: Syntax error: "(" unexpected (expecting "then")

lines from 26 to 30 looks like this
if [[ $WP_VERSION =~ [0-9]+.[0-9]+(.[0-9]+)? ]]; then
WP_TESTS_TAG="tags/$WP_VERSION"
elif [[ $WP_VERSION == 'nightly' || $WP_VERSION == 'trunk' ]]; then
WP_TESTS_TAG="trunk"
else

I'm on ubuntu 16.

The following labels are missing from the output of wp scaffold post_type <slug>:

• archives
• attributes
• featured_image
• filter_items_list
• insert_into_item
• items_list
• items_list_navigation
• remove_featured_image
• set_featured_image
• uploaded_to_this_item
• use_featured_image
• view_items

As the work on the new WordPress editor progresses, we thought that it would be great to simplify Gutenberg on-boarding process for plugin developers. It is still being discussed how native Gutenberg extensibility would look like, but we are confident that the most common use case will be that developers will want to create new blocks. We discussed it a bit already and it seems like the best way to start is to create a scaffolding command which creates a block registered into the editor that needs to have only logic updated. It would be great to have it included in the core of wp-cli.

Initial implementation

On the technical side, the only thing that is necessary to create a plugin that registers a new block is to provide two files similar to what @pento shared here:

https://gist.github.com/pento/19b35d621709042fc899e394a9387a54

Please note that this code doesn't use build step (no Webpack, Babel, etc.). It's only PHP and JavaScript code that will work out of the box. JS uses ES5 syntax that can run on every browser including IE11. It's a conscious decision to provide a default starter kit that produces code be approachable for developers coming from all possible backgrounds.

Side note: This sample code is a more advanced use case which uses post meta, which we can omit in the initial implementation.

Further iterations

We want to support also developers that want to use more advanced JavaScript tooling and we are happy to discuss how to provide more advanced tooling that would be enabled on demand things like:

• build step (Webpack, Grunt, whatever)
• code transpilation to allow ES.next syntax
• linting
• testing
• etc.

It also raises the question if wp-cli would be able to install all dependencies listed in package.json and execute the build step behind the scenes.

Open questions

1. We can also trigger a wider discussion if we want to move that tooling to a separate npm package to make them easier to reuse. I have also shared a blog post where I explain more in-depth advantages of starter kits and reusable scripts in the context of WordPress and Gutenberg.

2. I already asked this question on Slack, but let me rephrase and ask again here. What do you think about the following flow for new developers:

   • wp scaffold plugin gutenberg (or something like that) using ssh to do it on the server the gutenberg plugin is being used on.
   • User goes to /wp-admin/plugin-editor.php page to edit the new plugin directly in the code editor bundled with WP and implements save and edit JavaScript methods for a newly bootstraped Gutenblock.

3. Would it be possible to wrap wp-cli command with the interface exposed in Gutenberg, and create a new plugin that registers a block behind the scenes by filling in a form that mirrors CLI options?

On https://developer.wordpress.org/cli/commands/scaffold/taxonomy/, the docs display < and > instead of the respective glyphs:

--theme and --plugin should probably have identical formatting with regards to whether the =<name> is included inside the square brackets.

In attempting to use tests from the theme-tests base that wp scaffold sets up, none of my theme's functions existed. Assuming I was doing something wrong, I created a minimal theme and ran wp scaffold theme-tests to generate the tests. In the theme's functions.php file, I'm simply outputting text to indicate that the theme is loaded. In Travis CI, you can see that when run as single site, the theme is never loaded. When run as multisite, the theme does get loaded.

Any objections to adding an XML declaration to the phpunit.xml.dist template (<?xml version="1.0?>)?

It obviously isn't required, but there is no downside that I am aware of.

The primary upside (at least for me) is ensuring an editor properly detects file type to apply syntax highlighting.

I'm getting these errors when I'm trying to scaffold tests with: wp scaffold plugin-tests name-of-plugin or wp scaffold theme-tests name-of-theme. Strangely enough it doesn't happen with all plugins/themes.

This is the output I get when I run wp plugin list:

+----------------+----------+-----------+---------+
| name           | status   | update    | version |
+----------------+----------+-----------+---------+
| akismet        | inactive | available | 3.2     |
| hello          | inactive | none      | 1.6     |
| new-plugin     | inactive | none      | 0.1.0   |
| timber-library | active   | none      | 1.2.4   |
| twitterfeed    | inactive | none      | 0.5     |
+----------------+----------+-----------+---------+

When I try to scaffold tests for akismet it works. When I do the same for hello by running wp scaffold plugin-tests hello it fails: Error: Invalid plugin slug specified. In the list above hello and twitterfeed fail, the other three work.

wp scaffold theme-tests name-of-theme also fails with Error: Invalid theme slug specified, but it's more consistent because I can't seem to get it to work for any of the themes I have installed.

What is your system?

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

uname -a

Linux russell 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Which version of PHP are you using?

which -a php

/usr/bin/php

php -v

PHP 7.0.15-0ubuntu0.16.04.4 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.15-0ubuntu0.16.04.4, Copyright (c) 1999-2017, by Zend Technologies

Which version of WordPress are you using?

$wp_version = '4.7.5';

Can you share the results of which wp ?

which -a wp

/usr/local/bin/wp

stat $(which wp)

  File: '/usr/local/bin/wp'
  Size: 6804077         Blocks: 13296      IO Block: 4096   regular file
Device: 814h/2068d      Inode: 6035154     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-06-06 19:24:44.356297046 +0200
Modify: 2017-06-06 19:24:23.548641754 +0200
Change: 2017-06-06 19:24:41.528343781 +0200
 Birth: -

Are you running any packages? If one is causing a problem, you can use --skip-packages to skip loading them

aaemnnosttv/wp-cli-dotenv-command 

Previously: #55

If the server's display_errors directive is set to Off and the user tries to run their unit tests without first running bash bin/install-wp-tests.sh ..., they'll be greeted with blank output.

The uncaught exception is good if you have access to the error logs, or think to look there, but an error message which is explicitly output (via echo) would be even better.

The scaffold generated when CircleCI is chosen is a CircleCI 1.0 config file. Can this be updated for CircleCI 2.0? I'm a Developer Evangelist over at CircleCI and I can assist if needed.

Thanks.

Running wp scaffold plugin-tests <plugin> results in the tests/includes directory completely missing completely from the plugin. This causes the test suite to silently exit due to missing required files.

I am not sure if this belongs here - it looks like the wp scaffold plugin-tests command still exists in the main WP-CLI repo and that this package isn't officially available using wp package install. I assume that all future development will be happening here?

In any case - I have just started to take advantage of the wp scaffold plugin-tests command (super convenient, thanks for that) and I noticed that the PHPCS command run by travis fails by default. The problem is that PHPCS is run against the tests dir and the SampleTest class with a filename of test-sample.php violates the naming conventions defined in the WordPress coding standards.

This isn't a huge deal since the sample test will likely be deleted or renamed right away, but I assume users will follow the same conventions as WP-CLI and therefore continue to run into this issue.

Would it be beneficial to make some changes here?

A couple of possibilities:

1. Add an exclude pattern in phpcs.ruleset.xml to exclude the tests directory entirely. This would be my preference and is what I am doing personally since my tests tend to stray from the WordPress standards in at least a few ways.
2. Add per-rule exclude patterns for the tests directory. WordPress.Files.FileName.InvalidClassFileName is the rule needed to address this issue. Some other good candidates (in my opinion) would be Squiz.Commenting.FileComment.Missing, Squiz.Commenting.ClassComment.Missing and Squiz.Commenting.FunctionComment.Missing.
3. Update the sample test to better meet the WordPress standards. This would probably mean renaming the SampleTest class to Sample_Test, moving test-sample.php to class-sample-test.php and changing the PHPUnit testsuite definition to drop the test- prefix and update the suffix to -test.php.
4. ?

The temporary folder that is currently being used in the install-wp-tests.sh template to download and manipulate files is hardcoded to the /tmp folder, which can cause all sorts of issues, even on compatible platforms.

The temporary paths should rely on $TMPDIR instead, as that can then point to /tmp, /var/tmp or whatever user-specific temporary folder is meant to be used. Also, it provides a way to override the folder as well.

Or am I missing something?

I am used to travis where you can define several WP versions for the tests.

I am new to docker but I have a fair knowlege about Linux and Ubuntu.

One way that could be done is by actually just cleaning the /tmp folder and installing the tests again with a different WP version. This way not a complete new docker bootup would be needed. Not sure if that is a good way.

Like this. Assuming the config that wp-cli currently adds. Untested

PHPunit:PHP5.3:MySQL:
  image: tetraweb/php:5.3
  services:
    - mysql:5.6
  script:
  - phpcs
  - phpunit
  - rm -rf /tmp/*
  - bash bin/install-wp-tests.sh wordpress_tests root mysql mysql nightly true
  - phpcs
  - phpunit

Any thoughts on adding support for Bitbucket Pipelines to [--ci=<provider>]?

• https://bitbucket.org/product/features/pipelines
• https://www.cuttlesoft.com/bitbucket-pipelines-first-impression/
• https://bitbucket.org/rw_grim/local-pipelines/overview

bitbucket-pipelines.yml

# This is a sample build configuration for PHP.
# Check our guides at https://confluence.atlassian.com/x/e8YWN for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: phpunit/phpunit:5.0.3
pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - composer install

Something I noticed while checking the history for #77...

The reason for the .xml.dist extension for the phpunit config (per da9167d, presumably holds for phpcs as well):

Naming the file phpunit.xml.dist instead of phpunit.xml is considered a best practice because it allows other developers working on a project to override the configuration without messing with extra command line parameters or dirtying their local version control state.

See http://www.testically.org/2010/08/24/best-practice-how-to-ship-phpunit-configuration/

First, that linked site no longer appears to be active - here is an archived copy: http://web.archive.org/web/20160317185523/http://www.testically.org:80/2010/08/24/best-practice-how-to-ship-phpunit-configuration/

Second (and the point of this issue), part of the recommendation from that post is to add phpunit.xml to .gitignore to keep git status clean/prevent it from being accidentally committed.

So would it be beneficial for the standard configs to be added to the plugin-gitignore.mustache template?

The output of wp scaffold post_type <slug> includes code for the post_updated_messages filter. The same is not true when generating a taxonomy. It should include code for the term_updated_messages filter.

The following labels are missing from the output of wp scaffold taxonomy <slug>:

• items_list
• items_list_navigation
• no_terms
• view_item

In addition, WordPress 4.9 will add:

• back_to_items
• most_used

Adding the p argument to phpcs.xml.dist allows progress to be shown when invoking phpcs, which gives confidence to the user that something is happening.

Change:

	<!-- Show sniff codes in all reports -->
	<arg value="s"/>

to:

	<!-- Show progress and sniff codes in all reports -->
	<arg value="ps"/>

As mentioned in https://github.com/wp-cli/scaffold-command/pull/96/files#r164610714 the JS i18n functions do not except the second argument for the text domain. https://github.com/WordPress/gutenberg/blob/master/i18n/index.js#L42

There does not seem to be a way to define the text domain at the moment. WordPress/gutenberg#4147

This is a placeholder issue to discuss composable plugins via pull below.

wp-cli/sample-plugin#9

A command to scaffold the PHP code for a WP-CLI command would be great.

I currently start writing a command by copy-pasting an existing one, but this can get out of date with the latest changes to things such as documentation formatting.

Any thoughts on allowing Composer to decide on PHPUnit version instead of manually inspecting TRAVIS_PHP_VERSION?

Instead of this:

You could do something like this:

composer global require "phpunit/phpunit=4.8.*|5.7.*"

Which would give us PHPUnit 5.7 instead of 4.8 when running PHP 5.6.

From https://travis-ci.org/wp-cli/automated-tests/jobs/267261114

Introduced in #37 but it was only revealed now because I tagged a release.