WP-CLI v2.0.0 リリースノート


This is a big one! 67 awesome contributors have collaborated over 364 pull requests to bring you WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ v2!

Before going over the detailed change log, let’s discuss a few key areas of this update in more detail. There’s also a “Breaking changes” further down in the document.

“Framework” & “Bundle” are now two separate packages

This is the main change we planned to include with version 2 of WP-CLI. From v2 onwards, the “framework” is a separate package from the “bundle” that is used to build the Phar file you can download. The framework is now contained within the wp-cli/wp-cli package, while the bundling has moved on to the wp-cli/wp-cli-bundle.

Agreed, this does not sound like such a big deal, but in terms of development experience and maintenance effort, it is a tremendous improvement, making almost every future change faster and simpler.

What does that mean for users working with the Phar version of WP-CLI ?

Nothing much, really. Apart from some of the debugging information containing different paths, you won’t see much of a difference. One of the goals was to not disrupt current usage more than necessary. If you only ever download the WP-CLI Phar and use that to control your sites, you should not need to care about this change.

What does this mean for site owners using WP-CLI through Composer ?

They will rejoice! The framework itself has gotten rid of most of its problematic dependencies. If you compare the dependencies of v1.5.1 with those of v2.0.0, you’ll see that the list is drastically shorter. Also, the most problematic set of the dependencies, the hard requirement on an old version of Symfony, is gone. The only Symfony component we still have (yet) is symfony/finder, as there’s no upper version limit for that one.

Most of the more problematic dependencies actually came from the WP-CLI package manager (wp-cli/package-command). That command is not only optional now, there’s also no valid reason to use it at all when pulling WP-CLI in via Composer directly.

This also means that you will not see WP-CLI automatically pull in all bundled commands automatically. Let’s say, you need the wp-cli/db-command for some maintenance tasks for your site. With v1.5.1, this would have pulled in the entire WP-CLI bundle as a dependency. With v2.0.0, it will only pull in the lean framework as a dependency, nothing more. You’ll end up with a WP-CLI active on your site that contains the commands clihelp (as the two “built-ins”) and db.

As a nice side-benefit, this makes WP-CLI run much faster in such scenarios, as it only loads what is effectively needed for the site. The difference might not seem like much, but depending on how you use in in your scripts, it can make a big difference.

What does this mean for developers working on third-party WP-CLI commands?

Splitting everything up has provided a few additional perks for developers (see also the next section about the testing improvements). Everything is leaner, and the dependency resolutions are less problematic, as we got rid of that one nasty circular dependency (command requires framework => framework equals bundle => bundle requires command).

However, dependency declarations need to be more explicit now. If you require wp-cli/wp-cli, this will only provide the pure framework. You cannot implicitly rely on any of the bundled commands in that case, you’ll have to explicitly require any additional command you might need.

Testing framework is now a separate package

One of the things that bothered me a lot while maintaining WP-CLI was the fact that the testing infrastructure was “scaffolded” into the individual command packages (just as it is into the third-party commands). This basically means that we copy-pasted the code in there, and if the code needs to change (because of a bug being fixed or an improvement being made), we have to create changes in every single package to overwrite the copy-pasted version of the testing code with an updated one.

Now we have the testing infrastructure abstracted away into a separate package: wp-cli/wp-cli-tests. For this first iteration, it includes out-of-the-box support for PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php linting, PHP Code SnifferPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. checks (including the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards.
and the PHP Compatibility Checks), PHPUnit unit tests and Behat functional tests. They are set up in such a way that they detect whether they should run, based on config files or test files presence.

A simple composer test will run all of the tests in order. But you can also run them individually, through composer lint|phpcs|phpunit|behat. Adding further configuration flags can be done as well, but you need to remember to prepend them with a double-dash ( --) first, otherwise the arguments will be interpreted by Composer itself.

For the most important tests, the functional Behat tests, you can also define some constants to adapt the environment in which to test. For example, testing against a specific version of WordPress can be done by providing the WP_VERSION constant: WP_VERSION=4.2 composer behat. This constant also understands latest and trunk correctly.

In general, the tests are set up in such a way that you’ll face less differences between what you get locally and what you’ll get inside of the Travis CI checks.

And given that the tests can now be worked on in one central location, we’re already thinking about what our next steps are to further improve them, like letting you easily re-run only the failed scenarios from last run or automatically retrying failures on Travis to make sure it was not a random intermittent timeout or similar.

New command: i18n make-pot

@swissspidy has spent countless hours working on a new command that has now finally made it into the official WP-CLI bundle. We now introduce you to the i18n command family and its first usable subcommand, i18n make-pot.

What started out as an exploration at first is now a robust tool that is already being used in production systems and is even planned to replace the default translation tool bundled with WordPress Core. It supports both PHP and JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser.
https://www.javascript.com
, can manipulate and put into shape multiple files and even detected bugs in the original CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tooling.

This can now easily be including in whatever automated tooling you use for your site/pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./theme development, and should make your translation work much smoother. Here’s a quick rundown of the main features:

  • Automatically detects plugins and themes and extracts file headers.
  • Allows extraction of only a specific text domain.
  • Supports JavaScript string extraction, even for JSX and ESNext.
  • Allows merging the resulting POT file with an existing one, e.g. one created by Babel.
  • Powerful rules to include/exclude specific directories (minified JS files, vendor, .git folder, etc.).
  • Supports extracting strings from WordPress core the same way it’s done today with 4 different projects. See https://github.com/wp-cli/i18n-command/pull/69 for examples.
  • Can warn about strings with wrong placeholders, as well as misleading or missing translator comments. This could be very useful for core but also plugin/developers to improve polyglots UXUX UX is an acronym for User Experience – the way the user uses the UI. Think ‘what they are doing’ and less about how they do it..

A big shoutout to @swissspidy for the fabulous work he did on that command!

Minor Framework enhancements

New WordPress action: 'cli_init'

We introduced a new action 'cli_init' that will be triggered by WP-CLI during the 'plugins_loaded' action. This can be used as a conditional trigger for loading WP_CLI specific code, in case you don’t want to use the constants we already provide, for whatever reason.

This being a WordPress action, it adds a bit more flexibility to the process of loading a WP-CLI command, like for example one plugin being able to unhook the commands of another plugin.

New command: config edit

Easily open your wp-config.php in your favorite editor (configured through the EDITOR environment variable). Once you save within that editor, the wp-config.php will be correctly updated.

Note: This works through SSHSSH Secure SHell – a protocol for securely connecting to a remote system in addition to or in place of a password./vagrant/docker tunnels as well, but keep in mind that it will use the EDITOR of the remote system, which should be something like vim (=> “how to exit the vim editor” 😉).

# Launch system editor to edit wp-config.php file
$ wp config edit

# Edit wp-config.php file in a specific editor
$ EDITOR=vim wp config edit

New command: config shuffle-salts

This refreshes the salts stored in your wp-config.php file, which are cryptographic values used for authentication and other security-related functionality. Regulary refreshing these salts could be considered “security hygiene” for a site.

The command will generate the salts locally if your PHP server environment is cryptographically secure enough to do so, and falls back to the remote wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoint if not.

# Get new salts for your wp-config.php file
$ wp config shuffle-salts
Success: Shuffled the salt keys.

New command: db columns

Get a tabular view of the table schema for a given table. It shows you how the individual columns of the table have been defined, which default values they use and what extra functionality might be attached to them.

$ wp db columns wp_posts
+-----------------------+---------------------+------+-----+---------------------+----------------+
|         Field         |        Type         | Null | Key |       Default       |     Extra      |
+-----------------------+---------------------+------+-----+---------------------+----------------+
| ID                    | bigint(20) unsigned | NO   | PRI |                     | auto_increment |
| post_author           | bigint(20) unsigned | NO   | MUL | 0                   |                |
| post_date             | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| post_date_gmt         | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| post_content          | longtext            | NO   |     |                     |                |
| post_title            | text                | NO   |     |                     |                |
| post_excerpt          | text                | NO   |     |                     |                |
| post_status           | varchar(20)         | NO   |     | publish             |                |
| comment_status        | varchar(20)         | NO   |     | open                |                |
| ping_status           | varchar(20)         | NO   |     | open                |                |
| post_password         | varchar(255)        | NO   |     |                     |                |
| post_name             | varchar(200)        | NO   | MUL |                     |                |
| to_ping               | text                | NO   |     |                     |                |
| pinged                | text                | NO   |     |                     |                |
| post_modified         | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| post_modified_gmt     | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| post_content_filtered | longtext            | NO   |     |                     |                |
| post_parent           | bigint(20) unsigned | NO   | MUL | 0                   |                |
| guid                  | varchar(255)        | NO   |     |                     |                |
| menu_order            | int(11)             | NO   |     | 0                   |                |
| post_type             | varchar(20)         | NO   | MUL | post                |                |
| post_mime_type        | varchar(100)        | NO   |     |                     |                |
| comment_count         | bigint(20)          | NO   |     | 0                   |                |
+-----------------------+---------------------+------+-----+---------------------+----------------+

New command: db clean

We already had db reset, but that dropped the entire database… which is not a nice thing to do if there’s more than a default WordPress site in there 😱!

The new db clean will only drop the tables that are actually part of the current WordPress installation and leave the rest of the database instance intact.

# Delete all tables that match the current site prefix.
$ wp db clean --yes
Success: Tables dropped.

New command: site meta

We’ve added CRUD methods adddeletegetlistpatch, pluck and update for the “site metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.” entities.

Oh, and while you are wondering… Yes, you are right, WordPress does not have “site meta” entities. But we didn’t lose our minds: WordPress will introduce “site meta”, together with a wp_site_meta table, with its 5.0 version. We just like to be prepared, that’s all… 😜

# Set site meta
$ wp site meta set 123 bio "Mary is a WordPress developer."
Success: Updated custom field 'bio'.

# Get site meta
$ wp site meta get 123 bio
Mary is a WordPress developer.

# Update site meta
$ wp site meta update 123 bio "Mary is an awesome WordPress developer."
Success: Updated custom field 'bio'.

# Delete site meta
$ wp site meta delete 123 bio
Success: Deleted custom field.

New command: user check-password

You can now let WordPress tell you whether a given password is valid for a specific user. This is NOT an endorsement to build your authentication layer with Bash scripts! But who knows what exotic automation needs the DevOps folks will come up with…

The command will let you know through a shell exit code whether the password was valid or not, so you can use it directly in if conditionals.

# Check whether given credentials are valid; exit status 0 if valid, otherwise 1
$ wp user check-password admin adminpass
$ echo $?
1

# Bash script for checking whether given credentials are valid or not
if ! $(wp user check-password $USER $PASSWORD); then
    notify-send "Invalid Credentials";
fi

New commands: language plugin and language theme

They both come with the following subcommands: install, update, uninstall, list and is-installed (which was added to core language as well).

You can now fully control all of the language files of your installation individually.

# Install the Dutch theme language pack.
$ wp language plugin install hello-dolly nl_NL
Success: Language installed.

# Uninstall the Dutch theme language pack.
$ wp language plugin uninstall hello-dolly nl_NL
Success: Language uninstalled.

# List installed theme language packages.
$ wp language plugin list --status=installed
+----------+--------------+-------------+-----------+-----------+---------------------+
| language | english_name | native_name | status | update | updated |
+----------+--------------+-------------+-----------+-----------+---------------------+
| nl_NL | Dutch | Nederlands | installed | available | 2016-05-13 08:12:50 |
+----------+--------------+-------------+-----------+-----------+---------------------+

Changes to existing command

  • db size now knows about ISO size units as well
  • option list got a new --unserialize flag
  • post generate can now deal with --post_date_gmt
  • user update now allows you to --skip-email
  • eval-file can read from STDIN
  • Both plugin uninstall and plugin delete can now act on --all plugins at once
  • cap list can now --show-grant
  • cap add , seeing what its list sibling had done, grew a new --grant flag
  • role list can now print a single --field=<field>
  • scaffold _s learned the new --woocommerce trick
  • search-replace lets you set a --regex-limit

Automated README.md updates

If you have ever contributed to WP-CLI and made a change to a command signature or documentation, you probably had me tell you that you needed to regenerate the README.md as well using the wp scaffold package-readme . --force command. No more!

We have now added a package wp-cli/regenerate-readme that automates this process. It adds both a precommit and a postcommit git hook that collaborate to transparently regenerate the README.md file behind the scenes and then amend your commit to add the required changes automatically.

This has not been deployedDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors. to all command packages yet while we still experiment with some of the finer points of its implementation, but you’ll slowly see the annoying “please regenerate README.md kthxbye” reminders from my side disappear and become forgotten artifacts of the past.

Improved debug output

The debug output was always a bit sparse for WP-CLI. This is why we took the opportunity of v2 to improve upon it and make it more useful. It will now add debug messages for the hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. that are triggered, or details about how commands are being loaded or deferred. This will be very useful for third-party command developers that ignore why their command is not properly registered.

We’ll make sure to add even more useful debugging information in the future.

Small side note: To make debugging work as early as possible, it is now smart enough to just store all messages until the logger it needs to send them to becomes available. This means you don’t need to worry about the timing here, if the WP_CLI exits for your code, the debugger is good to go!

Breaking changes

Here are a few things you need to be aware of when moving from ^v1 to ^v2:

  • An obvious breaking change is the bump to the minimum version of PHP. This will break for anyone trying to run WP-CLI on PHP 5.3.
  • The separation of the “framework” and the “bundle” into two separate packages will cause a breaking change if a third-party command is being pulled-in via Composer AND that third-party command relies on running bundled commands as well. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted.
  • As many dependencies could be removed from the framework by not including the package manager automatically, any third-party command that relies on one of the removed Symfony packages or other dependencies AND hasn’t declared that requirement in its own Composer configuration will break. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted as the package manager still comes with these requirements included.
  • The versions of some the dependencies will be bumped. If you happen to not lock WP-CLI into a specific version constraint, but do so for some of its dependencies, you might see a version constraint conflict when using Composer.
  • Any external code that relies on internal file structure, file naming or other internal details that are not part of the provided API could run the risk of breaking due to us moving things around from v1 to v2. This should hopefully not ever be the case, but you never know…
  • As a side-effect of adding the --all flag to plugin uninstall, a breaking change was introduced for consistency reasons. Whereas WP-CLI used to consider uninstalling a non-existent plugin as a “Success: Plugin already uninstalled”, it will now throw an error “Error: No plugin uninstalled”.
  • 不要な破壊的変更を避けるため、最善を尽くしました。しかし、今回のような大きな構造変更では、細部が重要になります。ほかに問題が発生した場合はお知らせください!

完全な変更履歴

wp-cli/wp-cli-bundle

  • wp-cli/i18n-command をバンドル [#9]

wp-cli/wp-cli

  • 名詞を複数形にするための Inflector クラスと便利な関数を追加 [#4881]
  • wiki リンクをスキップするよう make-phar テストの正規表現を調整 [#4873]
  • PHPCSPHP Code Sniffer PHP Code Sniffer, コード品質を分析する人気のツール。WordPress Coding Standards は PHPCS に依存しています。 設定を更新 [#4867]
  • PHP バージョンチェックを修正 [#4864]
  • WordPress の 'plugins_loaded' アクション中に新しい 'cli_init' フックを実行。 [#4861]
  • core-command のテンプレートを phar に追加 [#4854]
  • PHP < 7 では $mode の代わりに完全な文字列へフォールバック [#4853]
  • wp-cli/wp-cli をバンドルではなくフレームワークのみを表すようリファクタリング [#4851]
  • WP 4.4 の要件を削除 [#4845]
  • —skip-theme テストを修正 [#4843]
  • ci/deploy.sh のシェルスクリプト問題を修正 [#4842]
  • bin/wp のシェルスクリプト問題を修正 [#4841]
  • ci/prepare.sh に引用符を追加 [#4840]
  • wp-completion.bash を v1.5.1 に固定 [#4839]
  • サービスが終了したため Gemnasium バッジを削除 [#4815]
  • プライバシーポリシーの変更により壊れたテストを修正するため、最新の search-replace パッケージを使用 [#4807]
  • 'latest' をバージョン番号に変換 [#4806]
  • WP5.0 により壊れたテストを修正するためパッケージを更新 [#4804]
  • 固定パッケージコマンドに切り替え [#4803]
  • テスト対象の最低 PHP バージョンを 5.4 に引き上げ [#4798]
  • wp cli alias に不足していた受け入れ可能な出力形式を追加 [#4765]
  • --skip-plugins および --skip-themes フラグの説明を改善 [#4759]
  • 一般的なインストール方法へのサブリンクを README.md に追加 [#4756]
  • ABSPATH を定義 [#4743]
  • 後方互換性のため wp_blogmeta テーブルをスキップ [#4736]
  • \WP_CLI\Utils\normalize_path 関数を導入。ABSPATH 定数に使用。 [#4718]
  • bootstrap テストの一時的な一度限りの @require-php-5.4 を取り消し。 [#4716]
  • 「最低 PHP 5.4 を要求」を取り消し [#4715]
  • auto-composer-updatepre-commit フックをスキップ [#4711]
  • wp cli info を更新」を取り消し [#4702]
  • cli update info チェックから : を削除。 [#4697]
  • pre-commit PHPCS 検証中はステージ済みファイルのみをチェック [#4696]
  • get_sites_by_path の変更後のフレームワークテストでドメインが空になる問題。 [#4695]
  • Phar からファイルを抽出する際に uniq_id() を追加 [#4692]
  • 特定の一時ファイル拡張子でシステムエディターを起動できるよう対応 [#4691]
  • GitGit Git は、小規模から非常に大規模なプロジェクトまでを高速かつ効率的に扱うために設計された、無料でオープンソースの分散バージョン管理システムです。Git は習得が容易で、フットプリントが小さく、非常に高速に動作します。現代のプラグインおよびテーマ開発の多くは、このバージョン管理システムで行われています。
    https://git-scm.com/
    pre-commit フックを作成するスクリプト。 [#4622]
  • wp cli info を更新 [#4613]

wp-cli/handbook

  • トラブルシューティング方法のドキュメントを追加 [#243]
  • プレースホルダーとして <example.com> を使用 [#242]
  • <code-review.md> の誤字を修正 [#239] & [#241]
  • リンク切れを削除 [#238]
  • brew 経由で WP-CLI をインストールする手順のドキュメントを更新 [#236]
  • alias に引用符を追加 [#235]
  • 適切なキーを使用するよう署名手順を調整 [#232]
  • WP-Optimize プラグインの optimize WP CLICLI コマンドラインインターフェース。Mac のターミナル (Bash)、Windows のコマンドプロンプト、または WordPress 用の WP-CLI。 コマンドを追加 [#231]
  • updraftplus WP CLI コマンドを追加 [#228]
  • ドキュメントの段落の文法を修正 [#226]
  • リポジトリに LICENSE ファイルを追加 [#224]
  • wp-cli/ideas リポジトリについて戦略的にいくつか言及 [#223]
  • ウェブサイトからウィッシュリストを削除 [#222]
  • WP-CLI 設定ドキュメントに WP_CLI_PHP_ARGS を記載 [#221]
  • Docker のインストール方法について言及 [#220]
  • タイトルにラテン文字を含む投稿の作成に関する問題をドキュメント化 [#214]
  • よくある問題として wp-config.php に BOM を追加 [#212]
  • 環境変数に WP_CLI_PHP を追加 [#211]
  • ドキュメント内の不足していた引用符を修正 [#210]
  • バンドルされていないインストールを分離し、現在の WP-CLI インスタンスに対して生成。 [#207]
  • Daniel のプロジェクトとの関係を更新 [#206]

wp-cli/wp-cli.github.com

  • スペイン語向けに <index.md> を更新 [#313]
  • Gemnasium バッジを削除 [#312]
  • pt_BR 翻訳を更新 [#311]
  • リポジトリに LICENSE ファイルを追加 [#309]
  • 翻訳のソースには英語版のみを使用する旨の注記を追加 [#308]
  • ホームページをスペイン語に翻訳 [#307]
  • すべての wp-cli.org リンクを http から https に変更。 [#305]

wp-cli/autoload-splitter

  • v2.0.0 以降、このパッケージは廃止されています

wp-cli/cache-command

  • フレームワーク v2 に対応 [#32]

wp-cli/checksum-command

  • プラグインのチェックサムに対するソフト変更をより柔軟に [#43]
  • より柔軟なソフト変更チェック (issue #34) [#41]
  • Windows パスを正しく照合するため正規表現にバックスラッシュを追加 [#39]
  • 正しい GitHubGitHub GitHub は、他の開発者が簡単に共有、コピー、変更できる Git リポジトリをオンラインで提供するウェブサイトです。パブリックリポジトリは無料でホスティングでき、プライベートリポジトリには有料サブスクリプションが必要です。GitHub は「プルリクエスト」という概念を導入しました。これは、コントリビューターがブランチで行ったコード変更を、リポジトリ所有者がマージする前にレビューおよび議論できる仕組みです。 https://github.com/ ラベルを作成 [#37]
  • フレームワーク v2 に対応 [#50]

wp-cli/config-command

  • ライブラリのバージョンを ^1.2.1 に固定 [#53]
  • 残っていた remove() 操作を削除 [#52]
  • config edit コマンドを導入 [#48]
  • より長いタイムアウト設定値を追加 [#67]
  • フレームワーク v2 に対応 [#66]
  • file_put_contents()wp-config.php のパスに書き込むよう保証 [#63]
  • shuffle-salts コマンドを追加 [#62]
  • WP_CACHE_KEY_SALT を設定 [#59]

wp-cli/core-command

  • wp-cli/wp-cli からテンプレートファイルを移行 [#73]
  • mustache テンプレートファイルのパスを修正 [#77] & [#78]
  • 重複データを防ぐため、インストールの最後にデータベースをサニタイズ [#76]
  • フレームワーク v2 に対応 [#81]

wp-cli/cron-command

  • フレームワーク v2 に対応 [#29]

wp-cli/db-command

  • db columns コマンドを追加 [#100]
  • スモークテストで投稿数ではなくユーザー数をカウント [#98]
  • wp_blogmetaテーブルの導入によるテスト失敗を修正 [#94]
  • db cleanコマンドを追加 [#93]
  • 特定の投稿をエクスポートする例を追加 [#90]
  • mysqldumpコマンドに--column-statistics=0を渡す [#105]
  • db sizeにISOサイズ形式を追加 [#104]
  • フレームワークv2向けにパッケージを適応 [#110]

wp-cli/embed-command

  • フレームワークv2向けにパッケージを適応 [#38]
  • 不足しているトップレベルコマンドをスキャフォールド [#35]

wp-cli/entity-command

  • Coreによるデフォルトの「Privacy Policy」ページ導入後のテストを修正 [#177]
  • メタCRUDをメソッドに抽象化 [#174]
  • 重複する--user_email=<user-email>引数を削除 [#173]
  • latestを実際のバージョン番号に変換 [#171]
  • 各種formatパラメータのドキュメントの書式を改善 [#168]
  • site metaサブコマンドを追加 [#159]
  • option listコマンドに--unserializeフラグを追加 [#156]
  • 重複投稿を作成するための--from-post=<post_id>フラグを追加 [#154]
  • 比較用にオブジェクトを正しくクローン [#152]
  • ドキュメント内の引用符の欠落を修正 [#147]
  • カテゴリーカテゴリー 「カテゴリー」タクソノミーを使うと、共通の結びつきを持つ投稿やコンテンツをまとめることができます。カテゴリーはあらかじめ定義されており、広範囲にわたります。一覧の件数を修正 [#146]
  • user check-passwordサブコマンドを追加 [#144]
  • 「install」を「installation」に置換 [#187]
  • post generate--post_date_gmtをサポート [#184]
  • wp user updateに任意指定の--skip-emailフラグを追加 [#155]
  • フレームワークv2向けにパッケージを適応 [#192]

wp-cli/eval-command

  • フレームワークv2向けにパッケージを適応 [#27]
  • STDINからのeval-fileをサポート(#19の実装) [#21]

wp-cli/export-command

  • 件数の問題を避けるため、空のサイトから開始 [#36]
  • フレームワークv2向けにパッケージを適応 [#44]

wp-cli/extension-command

  • このリポジトリに不足しているテンプレートを追加 [#107]
  • テストで使用している廃止されたテーマを新しいものに置換 [#105]
  • theme mod listを導入 [#100]
  • v1.1.10リリース前にREADME.mdとテストスイートを更新 [#89]
  • modern-wordpress redirectを許可 [#85]
  • plugin uninstallコマンドに--allフラグを追加 [#84]
  • Mustacheファイルのパスを修正 [#109] & [#112]
  • 検索:<wordpress.org>でプラグインまたはテーマのURLURL インターネット上のウェブサイトまたはウェブページの特定のウェブアドレス。たとえばウェブサイトのURL www.wordpress.orgを追加 [#108]
  • plugin delete--allフラグを追加 [#103]
  • フレームワークv2向けにパッケージを適応 [#116]

wp-cli/i18n-command

  • v2リリースに向けて準備 [#72]
  • WordPress Coreをサポート [#69]
  • 翻訳可能な文字列にさらに誤りがないか確認 [#64]
  • 翻訳の抽出とPoファイルの書き込みを分離 [#63]
  • PhpFunctionsScanner拡張可能に拡張可能 コードに追加機能を加えられる性質。プラグインはWordPressコアソフトウェアを拡張します。する [#62]
  • コマンド引数の処理を実際の__invoke()から分離 [#60]
  • --headersパラメータを追加 [#58]
  • POTファイルにX-Generator ヘッダーヘッダー サイトのヘッダーは通常、人々が最初に目にするものです。ページ上部に配置されるマストヘッドやヘッダーアートは、ウェブサイトの外観や雰囲気の一部です。コンテンツや、あなたまたは組織のブランドに対する訪問者の印象に影響を与えることがあります。また、画面サイズによって見え方が異なる場合があります。を追加 [#57]
  • より役立つデバッグメッセージを出力 [#56]
  • ディレクトリイテレーターをトレイトとして切り出し [#54]
  • テキストドメインヘッダー [#43]
  • コマンド名前空間に@when before_wp_loadを追加 [#42]
  • 任意のテキストドメインで文字列を抽出するオプションを追加 [#38]
  • excludeオプションをJsCodeExtractorに正しく渡す [#37]
  • 文字列に異なる翻訳者コメントが2つある場合に警告を追加 [#34]
  • 一般的なディレクトリをいくつか除外 [#32]
  • 既存のPOTファイルとマージする機能を追加 [#31]
  • JavaScript文字列の抽出 [#26]
  • PHPファイルがない場合は何も抽出しない [#24]
  • 翻訳者コメントに関するテストをさらに追加 [#23]
  • ファイル名を標準化 [#21]
  • サポートされているすべての関数を抽出 [#13]

wp-cli/import-command

  • プライバシーポリシーページの追加に耐えられるよう投稿・ページ生成を適応 [#25]
  • フレームワークv2向けにパッケージを適応 [#30]

wp-cli/language-command

  • 「プラグインおよびテーマコマンドを追加」を取り消し [#28]
  • フレームワークv2向けにパッケージを適応 [#43]
  • 言語パックアップグレーダーでdownload_url()を使用 [#41]
  • 個別のプラグインとテーマの言語更新を有効化 [#40]
  • プラグインまたはテーマが指定されていない場合に警告 [#38]
  • 指定した言語がインストールされているか確認するis-installedコマンドを追加 [#36]
  • language core update --dry-runのメッセージを更新 [#32]
  • language pluginおよびlanguage themeコマンドを追加 [#29]

wp-cli/media-command

  • フレームワークv2向けにパッケージを適応 [#85]
  • ドキュメントの例を更新 [#81]
  • ghostscript/imagickのインストールを復元し、regenerateテストでbmp名を修正 [#69]
  • インポート後に添付ファイルのURLを取得する方法を文書化 [#68]
  • media regenerate/importで定期的にWPオブジェクトキャッシュをクリア [#62]

wp-cli/package-command

  • composer.jsonファイルを取得できない場合はデフォルトのパッケージ名を使用 [#78]
  • phar内にある場合はComposerのCAバンドルの使用を回避 [#73]
  • test-commandをGithubのwp-cli-test組織に移動 [#66]
  • Composerで使用する前にPharからSSLSSL Secure Socket Layer(セキュアソケットレイヤー)—サーバーからブラウザーへ、またその逆方向の暗号化。ブラウザーとサーバー間で送受信する内容を他人に覗き見されるのを防ぎます。証明書を先に抽出 [#83]
  • フレームワークv2向けにパッケージを適応 [#87]
  • 壊れたComposerバージョンを除外 [#91]

wp-cli/php-cli-tools

  • 二重セミコロンを削除 [#130]
  • prompt()内で発生する可能性のある無限ループループ ループは、投稿を表示するためにWordPressが使用するPHPコードです。ループを使用して、WordPressは現在のページに表示する各投稿を処理し、ループタグ内で指定された条件との一致に応じて書式を設定します。ループ内のHTMLまたはPHPコードは各投稿で処理されます。 https://codex.wordpress.org/The_Loopを修正 [#129]
  • 進行状況バーの例におけるオフバイワンエラーを修正 [#128]
  • cli\Progress\Bar::tick()に任意指定の$msgパラメータを追加 [#126]

wp-cli/rewrite-command

  • フレームワークv2向けにパッケージを適応 [#20]

wp-cli/role-command

  • wp cap list--show-grant引数を追加し、wp cap add--grantを追加 [#19]
  • ロールの一覧表示に--field=<field>のサポートを追加 [#17]
  • フレームワークv2に対応 [#23]

wp-cli/scaffold-command

  • PHP 7.2以降ではPHPUnitテストをスキップ [#145]
  • scaffold blockを変更してindex.jsを作成 [#142]
  • スキャフォールドされたブロックのテーマ固有のパスを修正 [#137]
  • CIテンプレートにPHP 7.2を追加 [#135]
  • phpunit.xml.distファイルを介してtests/test-sample.phpを除外 [#134]
  • MacOSでのsed -iオプションを修正 [#132]
  • MacOSで正しいデフォルトの$WP_TESTS_DIRを使用 [#131]
  • PHP 7.2でコアテストとの互換性問題を回避するため、phpunit 6.5.6を使用 [#125]
  • theme-tests生成時のWPCSWordPress Community Support WordPress Foundationの子会社である公益法人。2016年に設立されました。を修正 [#121]
  • CircleCIテンプレートをCircleCI 2.0に切り替え。 [#115]
  • 'add_new_item'ラベルを修正 [#163]
  • エスケープ警告から文字列を除外 [#162]
  • PHPCSのデフォルトルールセットを更新 [#161]
  • scaffold _sコマンドに--woocommerceフラグを追加 [#159]
  • スキャフォールドされたコードにPHPCompatibilityのsniffssniff PHP Code Sniffer用のモジュールで、特定の問題がないかコードを分析します。複数のsniffを組み合わせてPHPCS標準を作成します。この用語は、犬が食べ物を「嗅ぎ分ける」のと同様に、コードの臭いを検出することに由来します。を追加 [#154]
  • blockBlock ブロックとは、WordPressエディターを使用して、組み合わせることでウェブページのコンテンツやレイアウトを形成するマークアップ単位を表す抽象的な用語です。過去にはショートコード、カスタムHTML、埋め込み検出によって実現されていた概念を、単一の一貫したAPIとユーザー体験に統合したものです。タイトルのエスケープを追加 [#153]
  • スタイルの依存関係から'wp-blocks'を削除 [#151]
  • ブロックPHPテンプレートにfunction_exists()チェックを追加 [#147]
  • フレームワークv2に対応 [#166]

wp-cli/search-replace-command

  • 「プライバシーポリシー」ページの追加により壊れていたテストを修正 [#78]
  • 不完全なクラスのシリアライズおよびデシリアライズを適切に処理 [#76]
  • PCREエラーを適切に処理 [#75]
  • multisiteMultisite マルチサイトは、1つのWordPressインストール上にユーザーがサイトのネットワークを作成できるWordPressの機能です。WordPressバージョン3.0以降で利用可能で、WPMUまたはWordPress Multiuserプロジェクトの後継です。WordPress MultiUserプロジェクトは終了し、その機能はWordPressコアに含まれました。高度な管理ハンドブック -> ネットワークの作成。の使用箇所から「サイトが見つかりません」メッセージを削除 [#69]
  • 壊れていたGUIDテストを修正 [#81]
  • --regex-limitのロジックを改善 [#70]
  • フレームワークv2に対応 [#86]
  • --regex-limitオプションを追加。 [#62]

wp-cli/server-command

  • フレームワークv2に対応 [#42]

wp-cli/shell-command

  • フレームワークv2に対応 [#25]
  • --basicフラグの説明を改善 [#23]

wp-cli/widget-command

  • フレームワークv2に対応 [#19]

貢献者

これを実現するために協力してくださった素晴らしい皆さんの完全なリストです:

@2020media, @abhijitrakas, @ajitbohra, @alpipego, @austinginder, @benlk, @BhargavBhandari90, @burhandodhy, @chesio, @CodeProKid, @danielbachhuber, @drzraf, @emirpprime, @ericgopak, @erlendeide, @felicianotech, @felipeelia, @fumikito, @GaryJones, @ghost, @gitlost, @greatislander, @JanVoracek, @janw-oostendorp, @javorszky, @jblz, @jmichaelward, @johnbillion, @josephfusco, @kirtangajjar, @kshaner, @lalaithan, @lf-jeremy, @libertamohamed, @marcovalloni, @marksabbath, @miya0001, @MoisesMN, @montu1996, @NicktheGeek, @ocean90, @pdaalder, @pekapl, @pixolin, @pjeby, @pmbaldha, @ptrkcsk, @ryanjbonnell, @sagarnasit, @salcode, @sasagar, @schlessera, @spacedmonkey, @spicecadet, @stevegrunwell, @strandtc, @svenkaptein, @swissspidy, @terriann, @thrijith, @tiagohillebrandt, @tomjn, @torounit, @wojsmol, @wp-make-coffee, @yousan, @zipofar

関係者の皆さん、本当にありがとうございました! ❤️

#リリース#v2-0-0