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 cli, help (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 add, delete, get, list, patch, 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 sizenow knows about ISO size units as welloption listgot a new--unserializeflagpost generatecan now deal with--post_date_gmtuser updatenow allows you to--skip-emaileval-filecan read fromSTDIN- Both
plugin uninstallandplugin deletecan now act on--allplugins at once cap listcan now--show-grantcap add, seeing what its list sibling had done, grew a new--grantflagrole listcan now print a single--field=<field>scaffold _slearned the new--woocommercetricksearch-replacelets 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
--allflag toplugin 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]
- 调整
make-phar测试中的正则表达式以跳过 wiki 链接 [#4873] - PHPCSPHP Code Sniffer PHP Code Sniffer,一种用于分析代码质量的热门工具。WordPress 编码标准依赖于 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中的 shell 脚本问题 [#4842] - 修复
bin/wp中的 shell 脚本问题 [#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-update中跳过pre-commit钩子 [#4711] - 还原“更新
wp cli info” [#4702] - 从 cli 更新信息检查中移除
:。[#4697] - 在
pre-commitPHPCS 验证期间仅检查已暂存的文件 [#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] - 为别名添加引号 [#235]
- 调整签名流程以使用正确的密钥 [#232]
- 为 WP-Optimize 插件添加
optimizeWP CLICLI 命令行界面。Mac 上的终端(Bash)、Windows 中的命令提示符,或用于 WordPress 的 WP-CLI。 命令 [#231] - 添加
updraftplusWP 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]
- 更灵活的软更改检查(问题 #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
wp-cli/entity-command
- 修复 Core 引入默认“隐私政策”页面后的测试问题 [#177]
- 将元数据 CRUD 抽象为方法 [#174]
- 移除重复的
--user_email=<user-email>参数 [#173] - 将
latest转换为实际版本号 [#171] - 改进各种格式参数文档的格式 [#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
wp-cli/export-command
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> 上添加插件或主题的网址网址 网站或互联网上网页的特定网络地址,例如网站的网址 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]
- 将目录迭代器提取为 trait [#54]
- 文本域标头 [#43]
- 向命令命名空间添加
@when before_wp_load[#42] - 添加使用任意文本域提取字符串的选项 [#38]
- 正确地将
exclude选项传递给JsCodeExtractor[#37] - 当字符串包含两条不同的译者注释时添加警告 [#34]
- 排除一些常见目录 [#32]
- 添加与现有 POT 文件合并的功能 [#31]
- JavaScript 字符串提取 [#26]
- 没有 PHP 文件时不要尝试提取任何内容 [#24]
- 添加更多与译者注释相关的测试 [#23]
- 统一文件名 [#21]
- 提取所有受支持的函数。 [#13]
wp-cli/import-command
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移至wp-cli-testGitHub 组织 [#66] - 先从 Phar 中提取SSLSSL 安全套接字层——在服务器与浏览器之间进行加密,反之亦然。防止窥探者看到你在浏览器与服务器之间传输的内容。证书,然后再在 Composer 中使用 [#83]
- 使软件包适配框架 v2 [#87]
- 排除损坏的 Composer 版本 [#91]
wp-cli/php-cli-tools
- 移除重复的分号 [#130]
- 修复
prompt()中潜在的无限循环循环 Loop 是 WordPress 用于显示文章的 PHP 代码。借助 Loop,WordPress 处理当前页面上要显示的每篇文章,并根据其与 Loop 标签中指定条件的匹配情况进行格式化。Loop 中的任何 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]
- 将 PHP 7.2 添加到 CI 模板 [#135]
- 通过 phpunit.xml.dist 文件排除
tests/test-sample.php[#134] - 修复 MacOS 上的
sed -i选项 [#132] - 在 MacOS 上使用正确的默认
$WP_TESTS_DIR[#131] - 在 PHP 7.2 中使用
phpunit6.5.6,以绕过核心测试不兼容问题。[#125] - 修复主题测试生成中的 WPCSWordPress Community Support 一家公益公司,也是 WordPress 基金会的子公司,于 2016 年成立。 [#121]
- 将 CircleCI 模板切换到 CircleCI 2.0。[#115]
- 修正
'add_new_item'标签 [#163] - 将字符串排除在转义警告之外 [#162]
- 更新 PHPCS 默认规则集 [#161]
- 向
scaffold _s命令添加--woocommerce标志 [#159] - 向生成的代码脚手架添加 PHPCompatibility 嗅探器嗅探器 PHP Code Sniffer 的一个模块,用于分析代码中的特定问题。多个嗅探器组合后可创建一个 PHPCS 标准。该术语源于它能够检测代码异味,类似于狗“嗅探”食物。 [#154]
- 为 区块区块 区块是用于描述标记单元的抽象术语,这些单元组合在一起,使用 WordPress 编辑器构成网页的内容或布局。这一理念将过去可能通过短代码、自定义 HTML 和嵌入发现实现的概念,整合为一致的 API 和用户体验。标题添加转义 [#153]
- 从样式依赖中移除
'wp-blocks'[#151] - 向区块 PHP 模板添加
function_exists()检查 [#147] - 使软件包适配框架 v2 [#166]
wp-cli/search-replace-command
- 修复因添加“隐私政策”页面而损坏的测试 [#78]
- 优雅地处理不完整类的(反)序列化 [#76]
- 优雅地处理 PCRE 错误 [#75]
- 从 多站点多站点 多站点是 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
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
感谢所有参与其中的人!❤️