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”. - Wir haben unser Bestes getan, um unnötige inkompatible Änderungen zu vermeiden. Bei einer so großen strukturellen Änderung wie dieser steckt der Teufel jedoch im Detail. Lass uns wissen, wenn du auf weitere Probleme stößt!
Vollständiges Änderungsprotokoll
wp-cli/wp-cli-bundle
wp-cli/i18n-commandbündeln [#9]
wp-cli/wp-cli
- Inflector-Klasse und Hilfsfunktion zum Pluralisieren von Substantiven hinzufügen [#4881]
- Regulären Ausdruck im
make-phar-Test anpassen, um Wiki-Links zu überspringen [#4873] - PHPCSPHP Code Sniffer PHP Code Sniffer, ein beliebtes Werkzeug zur Analyse der Codequalität. Die WordPress Coding Standards verwenden PHPCS. Konfiguration aktualisieren [#4867]
- PHP-Versionsprüfung korrigieren [#4864]
- Während der WordPress-Aktion
'plugins_loaded'einen neuen'cli_init'-Hook auslösen. [#4861] - Vorlage für core-command zum Phar hinzufügen [#4854]
- Bei PHP < 7 auf die vollständige Zeichenkette statt auf $mode zurückgreifen [#4853]
wp-cli/wp-cliumstrukturieren, sodass es nur das Framework und nicht das Bundle repräsentiert [#4851]- Anforderung von WP 4.4 entfernen [#4845]
—skip-theme-Tests korrigieren [#4843]- Probleme mit Shell-Skripten in
ci/deploy.shbeheben [#4842] - Probleme mit Shell-Skripten in
bin/wpbeheben [#4841] - Zusätzliche Anführungszeichen in
ci/prepare.sh[#4840] wp-completion.bashauf v1.5.1 festlegen [#4839]- Gemnasium-Badge entfernen, da der Dienst eingestellt wurde [#4815]
- Aktuellstes
search-replace-Paket verwenden, um aufgrund der Änderung der Datenschutzrichtlinie fehlschlagende Tests zu beheben [#4807] 'latest'in eine Versionsnummer umwandeln [#4806]- Pakete aktualisieren, um aufgrund von WP5.0 fehlschlagende Tests zu beheben [#4804]
- Zum festgelegten Paketbefehl wechseln [#4803]
- Niedrigste zu testende PHP-Version auf 5.4 anheben [#4798]
- Fehlendes akzeptiertes Ausgabeformat zu
wp cli aliashinzufügen [#4765] - Beschreibungen der Flags
--skip-pluginsund--skip-themesverbessern [#4759] - Unterlinks zu beliebten Installationsmethoden in
README.mdaufnehmen [#4756] ABSPATHdefiniert [#4743]- Tabelle
wp_blogmetaaus Gründen der Abwärtskompatibilität überspringen [#4736] - Funktion
\WP_CLI\Utils\normalize_patheinführen. Sie für die KonstanteABSPATHverwenden. [#4718] - Vorübergehendes einmaliges
@require-php-5.4im Bootstrap-Test rückgängig machen. [#4716] - „Require minimum PHP 5.4“ rückgängig machen [#4715]
pre-commit-Hook inauto-composer-updateüberspringen [#4711]- „
wp cli infoaktualisieren“ rückgängig machen [#4702] :aus der Prüfung der CLI-Aktualisierungsinformationen entfernen. [#4697]- Während der PHPCS-Prüfung in
pre-commitnur bereitgestellte Dateien prüfen [#4696] - Leere Domain im Framework-Test nach der Änderung von
get_sites_by_path. [#4695] - Beim Extrahieren einer Datei aus dem Phar
uniq_id()anhängen [#4692] - Das Starten des Systemeditors mit einer bestimmten temporären Dateierweiterung unterstützen [#4691]
- Skript zum Erstellen des GitGit Git ist ein kostenloses und quelloffenes verteiltes Versionskontrollsystem, das für kleine bis sehr große Projekte mit hoher Geschwindigkeit und Effizienz entwickelt wurde. Git ist leicht zu erlernen und hat einen geringen Platzbedarf sowie eine blitzschnelle Leistung. Die Entwicklung der meisten modernen Plugins und Themes erfolgt mit diesem Versionskontrollsystem.
https://git-scm.com/–pre-commit-Hooks. [#4622] wp cli infoaktualisieren [#4613]
wp-cli/handbook
- Dokumentation zur Fehlerbehebung hinzufügen [#243]
- <example.com> als Platzhalter verwenden [#242]
- Tippfehler in <code-review.md> beheben [#239] & [#241]
- Toten Link entfernen [#238]
- Dokumentation zur Installation von WP-CLI über
brewaktualisieren [#236] - Anführungszeichen zum Alias hinzufügen [#235]
- Signaturverfahren anpassen, um den richtigen Schlüssel zu verwenden [#232]
- Den
optimize-WP-CLICLI Befehlszeilenschnittstelle. Terminal (Bash) auf dem Mac, Eingabeaufforderung unter Windows oder WP-CLI für WordPress.-Befehl des WP-Optimize-Plugins hinzufügen [#231] - Einen
updraftplus-WP-CLI-Befehl hinzufügen [#228] - Grammatik im Dokumentationsabsatz korrigieren [#226]
- Eine
LICENSE-Datei zum Repository hinzufügen [#224] - Einige strategische Verweise auf das
wp-cli/ideas-Repository aufnehmen [#223] - Wunschliste von der Website entfernen [#222]
WP_CLI_PHP_ARGSim WP-CLI-Konfigurationsdokument dokumentieren [#221]- Die Docker-Installationsmethode erwähnen [#220]
- Problem beim Erstellen eines Beitrags mit lateinischen Zeichen im Titel dokumentieren [#214]
- BOM in
wp-config.phpals häufiges Problem hinzufügen. [#212] WP_CLI_PHPzu den Umgebungsvariablen hinzufügen [#211]- Fehlendes Anführungszeichen in der Dokumentation korrigieren [#210]
- Nicht gebündelte Installation trennen; gegen die aktuelle WP-CLI-Instanz generieren. [#207]
- Daniels Beziehung zum Projekt aktualisieren [#206]
wp-cli/wp-cli.github.com
für die spanische Sprache aktualisieren [#313] - Gemnasium-Badge entfernen [#312]
pt_BR-Übersetzung aktualisieren [#311]- Eine
LICENSE-Datei zum Repository hinzufügen [#309] - Hinweis hinzufügen, dass nur die englische Version als Quelle für Übersetzungen verwendet wird [#308]
- Startseite ins Spanische übersetzen [#307]
httpin allenwp-cli.org-Links inhttpsändern. [#305]
wp-cli/autoload-splitter
- Das Paket ist seit v2.0.0 veraltet
wp-cli/cache-command
- Paket an Framework v2 anpassen [#32]
wp-cli/checksum-command
- Nicht-invasive Änderungen für Plugin-Prüfsummen flexibler gestalten [#43]
- Flexiblere Prüfungen nicht-invasiver Änderungen (Issue #34) [#41]
- Backslash zum regulären Ausdruck hinzufügen, um Windows-Pfade korrekt abzugleichen [#39]
- Korrekte GitHubGitHub GitHub ist eine Website, die eine Online-Implementierung von Git-Repositories anbietet, die von anderen Entwicklern einfach geteilt, kopiert und geändert werden können. Öffentliche Repositories können kostenlos gehostet werden, für private Repositories ist ein kostenpflichtiges Abonnement erforderlich. GitHub führte das Konzept des „Pull Requests“ ein, bei dem Codeänderungen in Branches von Mitwirkenden überprüft und diskutiert werden können, bevor sie vom Repositorybesitzer zusammengeführt werden. https://github.com/-Labels erstellen [#37]
- Paket an Framework v2 anpassen [#50]
wp-cli/config-command
- Bibliotheksversion auf
^1.2.1festlegen [#53] - Übrig gebliebene
remove()-Operation entfernen [#52] config edit-Befehl einführen [#48]- Höheren Konfigurationswert für das Zeitlimit hinzufügen [#67]
- Paket an Framework v2 anpassen [#66]
- Sicherstellen, dass
file_put_contents()in den Pfad vonwp-config.phpschreibt [#63] shuffle-salts-Befehl hinzufügen [#62]WP_CACHE_KEY_SALTfestlegen [#59]
wp-cli/core-command
- Vorlagendateien aus
wp-cli/wp-cliübernehmen [#73] - Mustache-Vorlagendateipfad korrigieren [#77] & [#78]
- Datenbank am Ende der Installation bereinigen, um doppelte Daten zu verhindern [#76]
- Paket an Framework v2 anpassen [#81]
wp-cli/cron-command
- Paket an Framework v2 anpassen [#29]
wp-cli/db-command
db columns-Befehl hinzufügen [#100]- Für den Smoke-Test Benutzer statt Beiträge zählen [#98]
- Testfehler aufgrund der Einführung der Tabelle
wp_blogmetabeheben [#94] - Befehl
db cleanhinzufügen [#93] - Beispiele für den Export bestimmter Beiträge hinzufügen [#90]
--column-statistics=0an den Befehlmysqldumpübergeben [#105]- ISO-Größenformate zu
db sizehinzufügen [#104] - Paket an Framework v2 anpassen [#110]
wp-cli/embed-command
- Paket an Framework v2 anpassen [#38]
- Fehlende Befehle der obersten Ebene als Scaffold erstellen [#35]
wp-cli/entity-command
- Tests nach der Einführung einer standardmäßigen Seite „Datenschutzerklärung“ durch den Core korrigieren [#177]
- Meta-CRUD in Methoden abstrahieren [#174]
- Doppeltes Argument
--user_email=<user-email>entfernen [#173] latestin eine tatsächliche Versionsnummer umwandeln [#171]- Formatierung der Dokumentation verschiedener Formatparameter verbessern [#168]
- Unterbefehl
site metahinzufügen [#159] - Flag
--unserializezum Befehloption listhinzufügen [#156] - Flag
--from-post=<post_id>zum Erstellen doppelter Beiträge hinzufügen [#154] - Objekte für den Vergleich korrekt klonen [#152]
- Fehlendes Anführungszeichen in der Dokumentation korrigieren [#147]
- Anzahl der KategorienCategory Die Taxonomie „category“ ermöglicht es, Beiträge / Inhalte mit einer gemeinsamen Verbindung zu gruppieren. Kategorien sind vordefiniert und weit gefasst. in der Liste korrigieren [#146]
- Unterbefehl
user check-passwordhinzufügen [#144] - „install“ durch „installation“ ersetzen. [#187]
- Unterstützung für
--post_date_gmtinpost generatehinzufügen [#184] - Optionales Flag
--skip-emailfürwp user update[#155] - Paket an Framework v2 anpassen [#192]
wp-cli/eval-command
- Paket an Framework v2 anpassen [#27]
eval-fileausSTDINunterstützen (Implementierung für #19) [#21]
wp-cli/export-command
- Mit einer leeren Website starten, um Probleme mit der Anzahl zu vermeiden [#36]
- Paket an Framework v2 anpassen [#44]
wp-cli/extension-command
- Fehlende Vorlagen zu diesem Repository hinzufügen [#107]
- In Tests verwendete veraltete Themes durch neue ersetzen [#105]
theme mod listeinführen [#100]README.mdund Testsuite vor der Veröffentlichung vonv1.1.10aktualisieren. [#89]modern-wordpress redirectermöglichen [#85]- Flag
--allfür den Befehlplugin uninstallhinzufügen [#84] - Mustache-Dateipfade korrigieren [#109] & [#112]
- Suche: URLURL Eine bestimmte Webadresse einer Website oder Webseite im Internet, z. B. die URL www.wordpress.org einer Website des Plugins oder Themes auf <wordpress.org> hinzufügen [#108]
- Flag
--allzuplugin deletehinzufügen [#103] - Paket an Framework v2 anpassen [#116]
wp-cli/i18n-command
- Für die Veröffentlichung von v2 vorbereiten [#72]
- Unterstützung für den WordPress-Core [#69]
- Auf weitere Fehler in übersetzbaren Zeichenfolgen prüfen [#64]
- Extraktion von Übersetzungen vom Schreiben der Po-Datei trennen [#63]
PhpFunctionsScannererweiterbarExtensible Dies ist die Möglichkeit, dem Code zusätzliche Funktionen hinzuzufügen. Plugins erweitern die WordPress-Kernsoftware. machen [#62]- Verarbeitung von Befehlsargumenten vom eigentlichen
__invoke()trennen [#60] - Parameter
--headershinzufügen [#58] X-Generator–HeaderHeader Der Header deiner Website ist normalerweise das Erste, was Besucher erleben. Der über den oberen Bereich deiner Seite verlaufende Schriftzug oder die Header-Grafik ist Teil der Gestaltung und des Erscheinungsbilds deiner Website. Er kann die Meinung eines Besuchers über deine Inhalte und die Marke von dir bzw. deiner Organisation beeinflussen. Auf unterschiedlichen Bildschirmgrößen kann er außerdem unterschiedlich aussehen. zur POT-Datei hinzufügen [#57]- Weitere hilfreiche Debug-Nachrichten ausgeben [#56]
- Verzeichnisiterator als Trait auslagern [#54]
- Textdomain-Header [#43]
@when before_wp_loadzum Befehlsnamespace hinzufügen [#42]- Option zum Extrahieren von Zeichenfolgen mit beliebigem Textdomain hinzufügen [#38]
- Option
excludekorrekt anJsCodeExtractorübergeben [#37] - Warnung hinzufügen, wenn eine Zeichenfolge zwei unterschiedliche Übersetzerkommentare besitzt [#34]
- Einige häufig verwendete Verzeichnisse ausschließen [#32]
- Möglichkeit zum Zusammenführen mit einer vorhandenen POT-Datei hinzufügen [#31]
- Extraktion von JavaScript-Zeichenfolgen [#26]
- Nichts zu extrahieren versuchen, wenn keine PHP-Dateien vorhanden sind [#24]
- Weitere Tests zu Übersetzerkommentaren hinzufügen [#23]
- Dateinamen standardisieren [#21]
- Alle unterstützten Funktionen extrahieren. [#13]
wp-cli/import-command
- Generierung von Beiträgen/Seiten so anpassen, dass sie gegenüber einer hinzugefügten Datenschutzerklärungsseite resilient ist [#25]
- Paket an Framework v2 anpassen [#30]
wp-cli/language-command
- „Add plugin and theme command“ rückgängig machen [#28]
- Paket an Framework v2 anpassen [#43]
download_url()im Sprachpaket-Upgrader verwenden [#41]- Aktualisierung von Sprachen für einzelne Plugins und Themes ermöglichen [#40]
- Warnen, wenn kein Plugin oder Theme angegeben wurde [#38]
- Befehl
is-installedhinzufügen, um zu prüfen, ob eine bestimmte Sprache installiert ist [#36] - Nachricht von
language core update --dry-runaktualisieren [#32] - Befehle
language pluginundlanguage themehinzufügen. [#29]
wp-cli/media-command
- Paket an Framework v2 anpassen [#85]
- Beispiele in der Dokumentation aktualisieren [#81]
- Installation von
ghostscript/imagickwiederherstellen und den Namenbmpimregenerate-Test korrigieren. [#69] - Dokumentieren, wie die URL eines Anhangs nach dem Import abgerufen wird [#68]
- WP-Objektcache bei
media regenerate/importregelmäßig leeren. [#62]
wp-cli/package-command
- Standardmäßigen Paketnamen annehmen, wenn die Datei
composer.jsonnicht abgerufen werden kann [#78] - Composer-CA-Bundle nicht verwenden, wenn es sich um ein Phar handelt. [#73]
test-commandin die GitHub-Organisationwp-cli-testverschieben [#66]- SSLSSL Secure Socket Layer – Verschlüsselung vom Server zum Browser und zurück. Verhindert, dass neugierige Blicke sehen, was du zwischen deinem Browser und dem Server sendest.-Zertifikat zuerst aus dem Phar extrahieren, bevor es in Composer verwendet wird [#83]
- Paket an Framework v2 anpassen [#87]
- Defekte Composer-Version ausschließen [#91]
wp-cli/php-cli-tools
- Doppeltes Semikolon entfernen [#130]
- Mögliche Endlosschleife SchleifeLoop The Loop ist PHP-Code, der von WordPress zur Anzeige von Beiträgen verwendet wird. Mithilfe von The Loop verarbeitet WordPress jeden auf der aktuellen Seite anzuzeigenden Beitrag und formatiert ihn entsprechend seiner Übereinstimmung mit den in den The-Loop-Tags angegebenen Kriterien. Jeder HTML- oder PHP-Code in The Loop wird für jeden Beitrag verarbeitet. https://codex.wordpress.org/The_Loop in
prompt()beheben [#129] - Off-by-one-Fehler in Beispielen für Fortschrittsbalken beheben [#128]
- Optionalen Parameter
$msgzucli\Progress\Bar::tick()hinzufügen [#126]
wp-cli/rewrite-command
- Paket an Framework v2 anpassen [#20]
wp-cli/role-command
- Argument
--show-grantzuwp cap listund--grantzuwp cap addhinzufügen [#19] - Unterstützung für
--field=<field>beim Auflisten von Rollen hinzufügen [#17] - Paket für Framework v2 anpassen [#23]
wp-cli/scaffold-command
- PHPUnit-Tests für PHP 7.2+ überspringen [#145]
scaffold blockso ändern, dassindex.jserstellt wird [#142]- Typspezifische Pfade in generierten Blöcken korrigieren [#137]
- PHP 7.2 zu CI-Vorlagen hinzufügen [#135]
tests/test-sample.phpüber die Datei phpunit.xml.dist ausschließen [#134]sed -i-Option unter MacOS korrigieren [#132]- Den korrekten Standardwert für
$WP_TESTS_DIRunter MacOS verwenden [#131] phpunit6.5.6 für PHP 7.2 verwenden, um die Inkompatibilität mit den Core-Tests zu umgehen. [#125]- WPCSWordPress Community Support Eine gemeinnützige Körperschaft und Tochtergesellschaft der WordPress Foundation, die 2016 gegründet wurde. bei der Generierung von Theme-Tests korrigieren [#121]
- CircleCI-Vorlage auf CircleCI 2.0 umstellen. [#115]
- Das Label
'add_new_item'korrigieren [#163] - String aus der Escape-Warnung ausschließen [#162]
- PHPCS-Standardregelsatz aktualisieren [#161]
--woocommerce-Flag zum Befehlscaffold _shinzufügen [#159]- PHPCompatibility-SniffsSniff Ein Modul für PHP Code Sniffer, das Code auf ein bestimmtes Problem analysiert. Mehrere Sniffs werden kombiniert, um einen PHPCS-Standard zu erstellen. Der Begriff ist so benannt, weil damit Code Smells erkannt werden, ähnlich wie ein Hund Nahrung „erschnüffelt“. zu generierten Dateien hinzufügen [#154]
- Escaping für den BlockBlock Block ist der abstrakte Begriff zur Beschreibung von Markup-Einheiten, die zusammen den Inhalt oder das Layout einer Webseite mit dem WordPress-Editor bilden. Die Idee vereint Konzepte, die früher möglicherweise mit Shortcodes, benutzerdefiniertem HTML und der Erkennung eingebetteter Inhalte umgesetzt wurden, in einer einheitlichen API und Benutzererfahrung.-Titel hinzufügen [#153]
'wp-blocks'aus der Style-Abhängigkeit entfernen [#151]- Prüfung auf
function_exists()zur PHP-Blockvorlage hinzufügen [#147] - Paket für Framework v2 anpassen [#166]
wp-cli/search-replace-command
- Tests korrigieren, die durch das Hinzufügen einer „Datenschutz“-Seite fehlschlagen [#78]
- Unvollständige Klassen bei der (De-)Serialisierung ordnungsgemäß behandeln [#76]
- PCRE-Fehler ordnungsgemäß behandeln [#75]
- Die Meldung „Website nicht gefunden“ aus der Verwendung von MultisiteMultisite Multisite ist eine WordPress-Funktion, mit der Benutzer ein Netzwerk von Websites innerhalb einer einzigen WordPress-Installation erstellen können. Multisite ist seit WordPress 3.0 verfügbar und eine Fortsetzung des WPMU- bzw. WordPress-Multiuser-Projekts. Das WordPress-MultiUser-Projekt wurde eingestellt und seine Funktionen wurden in den WordPress-Kern aufgenommen. Handbuch für erweiterte Administration -> Ein Netzwerk erstellen. entfernen [#69]
- Fehlerhaften GUID-Test korrigieren [#81]
- Logik von
--regex-limitverbessern [#70] - Paket für Framework v2 anpassen [#86]
- Option
--regex-limithinzufügen. [#62]
wp-cli/server-command
- Paket für Framework v2 anpassen [#42]
wp-cli/shell-command
wp-cli/widget-command
- Paket für Framework v2 anpassen [#19]
Mitwirkende
Hier ist die vollständige Liste der großartigen Menschen, die geholfen haben, dies zu verwirklichen:
@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
Ein großes Dankeschön an alle Beteiligten! ❤️