DocsWP — WordPress Help

Notes de version de 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 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 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”.
  • Nous avons fait de notre mieux pour éviter les changements incompatibles inutiles. Mais avec un changement structurel aussi important que celui-ci, le diable se cache dans les détails. Faites-nous savoir si vous rencontrez d’autres problèmes !

Journal complet des modifications

wp-cli/wp-cli-bundle

  • Intégrer wp-cli/i18n-command [#9]

wp-cli/wp-cli

  • Ajouter la classe Inflector et une fonction pratique pour mettre les noms au pluriel [#4881]
  • Adapter l’expression régulière du test make-phar pour ignorer les liens wiki [#4873]
  • PHPCSPHP Code Sniffer PHP Code Sniffer, un outil populaire pour analyser la qualité du code. Les normes de codage WordPress reposent sur PHPCS. Actualisation de la configuration [#4867]
  • Corriger la vérification de la version de PHP [#4864]
  • Déclencher le nouveau hook 'cli_init' pendant l’action WordPress 'plugins_loaded'. [#4861]
  • ajouter un modèle pour core-command au phar [#4854]
  • Utiliser la chaîne complète au lieu de $mode sur PHP < 7 [#4853]
  • Refactoriser wp-cli/wp-cli afin de représenter uniquement le framework, et non le bundle [#4851]
  • Supprimer l’exigence de WP 4.4 [#4845]
  • Corriger les tests —skip-theme [#4843]
  • Corriger les problèmes de script shell dans ci/deploy.sh [#4842]
  • Corriger les problèmes de script shell dans bin/wp [#4841]
  • Ajouter des guillemets supplémentaires dans ci/prepare.sh [#4840]
  • Verrouiller wp-completion.bash à la version 1.5.1 [#4839]
  • Supprimer le badge Gemnasium, car le service a été fermé [#4815]
  • Utiliser la dernière version du paquet search-replace pour corriger les tests cassés en raison d’une modification de la politique de confidentialité [#4807]
  • Transformer 'latest' en numéro de version [#4806]
  • Mettre à jour les paquets pour corriger les tests cassés par WP5.0 [#4804]
  • Passer à la commande de paquet fixe [#4803]
  • Augmenter la version minimale de PHP à tester à 5.4 [#4798]
  • Ajouter un format de sortie accepté manquant à wp cli alias [#4765]
  • Améliorer les descriptions des options --skip-plugins et --skip-themes [#4759]
  • Inclure des sous-liens dans README.md vers les méthodes d’installation populaires [#4756]
  • ABSPATH défini [#4743]
  • Ignorer la table wp_blogmeta pour assurer la rétrocompatibilité [#4736]
  • Introduire la fonction \WP_CLI\Utils\normalize_path. L’utiliser pour la constante ABSPATH. [#4718]
  • Annuler le @require-php-5.4 temporaire et ponctuel dans le test d’amorçage. [#4716]
  • Annuler « Exiger PHP 5.4 au minimum » [#4715]
  • Ignorer le hook pre-commit dans auto-composer-update [#4711]
  • Annuler « mettre à jour wp cli info » [#4702]
  • Supprimer : de la vérification des informations de mise à jour de l’interface CLI. [#4697]
  • Vérifier uniquement les fichiers indexés lors de la vérification PHPCS du pre-commit [#4696]
  • Domaine vide dans le test du framework après la modification de get_sites_by_path. [#4695]
  • Ajouter uniq_id() lors de l’extraction d’un fichier depuis Phar [#4692]
  • Prendre en charge le lancement de l’éditeur système avec une extension de fichier temporaire spécifique [#4691]
  • Script pour créer le hook GitGit Git est un système de contrôle de version distribué, libre et open source, conçu pour gérer des projets allant des plus petits aux très grands avec rapidité et efficacité. Git est facile à apprendre et possède une faible empreinte, avec des performances extrêmement rapides. La plupart des développements modernes d’extensions et de thèmes sont réalisés avec ce système de contrôle de version.
    https://git-scm.com/     pre-commit. [#4622]
  • Mettre à jour wp cli info [#4613]

wp-cli/handbook

  • Ajouter une documentation expliquant comment résoudre les problèmes [#243]
  • Utiliser <example.com> comme espace réservé [#242]
  • Corriger les fautes de frappe dans <code-review.md> [#239] & [#241]
  • Supprimer le lien mort [#238]
  • Mettre à jour la documentation sur l’installation de WP-CLI via brew [#236]
  • Ajouter des guillemets à l’alias [#235]
  • Adapter la procédure de signature afin d’utiliser la clé appropriée [#232]
  • Ajouter la commande optimize de WP CLICLI Interface de ligne de commande. Terminal (Bash) sur Mac, invite de commandes sous Windows ou WP-CLI pour WordPress. du plugin WP-Optimize [#231]
  • Ajouter une commande WP CLI updraftplus [#228]
  • Corriger la grammaire dans un paragraphe de la documentation [#226]
  • Ajouter un fichier LICENSE au dépôt [#224]
  • Intégrer quelques mentions stratégiques du dépôt wp-cli/ideas [#223]
  • Supprimer la liste de souhaits du site web [#222]
  • Documenter WP_CLI_PHP_ARGS dans le document de configuration de WP-CLI [#221]
  • Mentionner la méthode d’installation avec Docker [#220]
  • Documenter le problème de création d’un article avec des caractères latins dans le titre [#214]
  • Ajouter le BOM dans wp-config.php comme problème courant. [#212]
  • Ajouter WP_CLI_PHP aux variables d’environnement [#211]
  • Corriger le guillemet manquant dans la documentation [#210]
  • Séparer l’installation sans bundle ; générer à partir de l’instance WP-CLI actuelle. [#207]
  • Mettre à jour la relation de Daniel avec le projet [#206]

wp-cli/wp-cli.github.com

  • Mettre à jour <index.md> pour la langue espagnole [#313]
  • Supprimer le badge Gemnasium [#312]
  • Mettre à jour la traduction pt_BR [#311]
  • Ajouter un fichier LICENSE au dépôt [#309]
  • Ajouter une note indiquant d’utiliser uniquement la version anglaise comme source des traductions [#308]
  • Traduire la page d’accueil en espagnol [#307]
  • Remplacer http par https dans tous les liens wp-cli.org. [#305]

wp-cli/autoload-splitter

  • Le paquet est désormais obsolète depuis la version v2.0.0

wp-cli/cache-command

  • Adapter le paquet au framework v2 [#32]

wp-cli/checksum-command

  • Rendre les modifications souples plus flexibles pour les sommes de contrôle des extensions [#43]
  • Vérifications plus flexibles des modifications souples (problème n° 34) [#41]
  • Ajouter une barre oblique inverse à l’expression régulière pour faire correspondre correctement les chemins Windows [#39]
  • Créer les libellés GitHub appropriés [#37]
  • Adapter le paquet au framework v2 [#50]

wp-cli/config-command

  • Corriger la version de la bibliothèque à ^1.2.1 [#53]
  • Supprimer l’opération remove() résiduelle [#52]
  • Introduire la commande config edit [#48]
  • Ajouter une valeur de configuration avec un délai d’expiration plus élevé [#67]
  • Adapter le paquet au framework v2 [#66]
  • S’assurer que file_put_contents() écrit vers le chemin de wp-config.php [#63]
  • Ajouter la commande shuffle-salts [#62]
  • Définir WP_CACHE_KEY_SALT [#59]

wp-cli/core-command

  • Transférer les fichiers modèles depuis wp-cli/wp-cli [#73]
  • Corriger le chemin du fichier modèle Mustache [#77] & [#78]
  • Assainir la base de données à la fin de l’installation pour éviter les données en double [#76]
  • Adapter le paquet au framework v2 [#81]

wp-cli/cron-command

  • Adapter le paquet au framework v2 [#29]

wp-cli/db-command

  • Ajouter la commande db columns [#100]
  • Compter les utilisateurs plutôt que les articles pour le test de fumée [#98]
  • Corriger l’échec du test dû à l’introduction de la table wp_blogmeta [#94]
  • Ajouter la commande db clean [#93]
  • Ajouter des exemples pour exporter certains articles [#90]
  • Transmettre --column-statistics=0 à la commande mysqldump [#105]
  • Ajouter les formats de taille ISO à db size [#104]
  • Adapter le paquet pour la version 2 du framework [#110]

wp-cli/embed-command

  • Adapter le paquet pour la version 2 du framework [#38]
  • Créer les commandes de niveau supérieur manquantes [#35]

wp-cli/entity-command

  • Corriger les tests après l’introduction par le cœur d’une page « Politique de confidentialité » par défaut [#177]
  • Abstraire les opérations CRUD des métadonnées dans des méthodes [#174]
  • Supprimer l’argument redondant --user_email=<user-email> [#173]
  • Transformer latest en véritable numéro de version [#171]
  • Améliorer la mise en forme de la documentation de divers paramètres de format [#168]
  • Ajouter la sous-commande site meta [#159]
  • Ajouter l’option --unserialize à la commande option list [#156]
  • Ajouter l’option --from-post=<post_id> pour créer des articles en double [#154]
  • Cloner correctement les objets pour la comparaison [#152]
  • Corriger un guillemet manquant dans la documentation [#147]
  • Corriger le nombre d’éléments de la liste catégorieCatégorie La taxonomie « catégorie » permet de regrouper les articles et le contenu qui partagent un lien commun. Les catégories sont prédéfinies et couvrent un large éventail de sujets. [#146]
  • Ajouter la sous-commande user check-password [#144]
  • Remplacer « install » par « installation ». [#187]
  • Ajouter la prise en charge de --post_date_gmt dans post generate [#184]
  • Option --skip-email facultative pour wp user update [#155]
  • Adapter le paquet pour la version 2 du framework [#192]

wp-cli/eval-command

  • Adapter le paquet pour la version 2 du framework [#27]
  • Prendre en charge eval-file depuis STDIN (implémentation de #19) [#21]

wp-cli/export-command

  • Commencer avec un site vide pour éviter les problèmes de comptage [#36]
  • Adapter le paquet pour la version 2 du framework [#44]

wp-cli/extension-command

  • Ajouter les modèles manquants à ce dépôt [#107]
  • Remplacer les thèmes retirés utilisés dans les tests par de nouveaux thèmes [#105]
  • Introduire theme mod list [#100]
  • Actualiser README.md et la suite de tests avant la version v1.1.10. [#89]
  • Autoriser modern-wordpress redirect [#85]
  • Ajouter l’option --all à la commande plugin uninstall [#84]
  • Corriger les chemins des fichiers Mustache [#109] & [#112]
  • Recherche : ajouter l’URLURL Adresse web spécifique d’un site ou d’une page web sur Internet, telle que l’URL d’un site web www.wordpress.org du plugin ou du thème sur <wordpress.org> [#108]
  • Ajouter l’option --all à plugin delete [#103]
  • Adapter le paquet pour la version 2 du framework [#116]

wp-cli/i18n-command

  • Préparer la version 2 [#72]
  • Prise en charge du cœur de WordPress [#69]
  • Vérifier la présence d’autres erreurs dans les chaînes traduisibles [#64]
  • Séparer l’extraction des traductions de l’écriture du fichier Po [#63]
  • Rendre PhpFunctionsScanner extensibleExtensible Capacité à ajouter des fonctionnalités supplémentaires au code. Les extensions enrichissent le logiciel de base de WordPress. [#62]
  • Séparer la gestion des arguments de commande de __invoke() proprement dite [#60]
  • Ajouter le paramètre --headers [#58]
  • Ajouter l’en-têteEn-tête L’en-tête de votre site est généralement la première chose que les visiteurs découvrent. Le bandeau ou l’image d’en-tête situé en haut de votre page participe à l’apparence de votre site. Il peut influencer l’opinion d’un visiteur sur votre contenu et sur votre marque ou votre organisation. Il peut également s’afficher différemment selon la taille de l’écran. X-Generator au fichier POT [#57]
  • Afficher des messages de débogage plus utiles [#56]
  • Factoriser l’itérateur de répertoire sous forme de trait [#54]
  • En-tête du domaine de texte [#43]
  • Ajouter @when before_wp_load à l’espace de noms de la commande [#42]
  • Ajouter une option pour extraire les chaînes avec n’importe quel domaine de texte [#38]
  • Transmettre correctement l’option exclude à JsCodeExtractor [#37]
  • Ajouter un avertissement lorsqu’une chaîne possède deux commentaires de traducteur différents [#34]
  • Exclure certains répertoires courants [#32]
  • Ajouter la possibilité de fusionner avec un fichier POT existant [#31]
  • Extraction des chaînes JavaScript [#26]
  • Ne rien tenter d’extraire lorsqu’il n’y a aucun fichier PHP [#24]
  • Ajouter davantage de tests liés aux commentaires des traducteurs [#23]
  • Standardiser les noms de fichiers [#21]
  • Extraire toutes les fonctions prises en charge. [#13]

wp-cli/import-command

  • Adapter la génération des articles et des pages pour résister à l’ajout de la page de politique de confidentialité [#25]
  • Adapter le paquet pour la version 2 du framework [#30]

wp-cli/language-command

  • Annuler « Ajouter la commande plugin et thème » [#28]
  • Adapter le paquet pour la version 2 du framework [#43]
  • Utiliser download_url() dans le programme de mise à niveau des packs linguistiques [#41]
  • Activer la mise à jour des langues pour les plugins et les thèmes individuels [#40]
  • Avertir si aucun plugin ni thème n’a été spécifié [#38]
  • Ajouter la commande is-installed pour vérifier si une langue donnée est installée [#36]
  • Mettre à jour le message de language core update --dry-run [#32]
  • Ajouter les commandes language plugin et language theme. [#29]

wp-cli/media-command

  • Adapter le paquet pour la version 2 du framework [#85]
  • Mettre à jour les exemples de la documentation [#81]
  • Rétablir l’installation de ghostscript/imagick et corriger le nom de bmp dans le test regenerate. [#69]
  • Documenter la manière de récupérer l’URL d’une pièce jointe après l’importation [#68]
  • Vider périodiquement le cache d’objets WP lors de media regenerate/import. [#62]

wp-cli/package-command

  • Supposer le nom de paquet par défaut si le fichier composer.json ne peut pas être récupéré [#78]
  • Éviter d’utiliser le bundle d’autorités de certification de Composer dans un fichier phar. [#73]
  • Déplacer test-command vers l’organisation Github wp-cli-test [#66]
  • Extraire d’abord le certificat SSLSSL Secure Socket Layer – chiffrement du serveur vers le navigateur et inversement. Empêche les regards indiscrets de voir ce que vous envoyez entre votre navigateur et le serveur. du fichier Phar avant de l’utiliser dans Composer [#83]
  • Adapter le paquet pour la version 2 du framework [#87]
  • Exclure la version défaillante de Composer [#91]

wp-cli/php-cli-tools

  • Supprimer le double point-virgule [#130]
  • Corriger une éventuelle boucleBoucle The Loop est du code PHP utilisé par WordPress pour afficher les articles. À l’aide de The Loop, WordPress traite chaque article à afficher sur la page actuelle et le met en forme selon sa correspondance avec les critères spécifiés dans les balises de The Loop. Tout code HTML ou PHP présent dans The Loop sera traité pour chaque article. https://codex.wordpress.org/The_Loop infinie dans prompt() [#129]
  • Corriger l’erreur de décalage de 1 dans les exemples de barre de progression [#128]
  • Ajouter le paramètre facultatif $msg à cli\Progress\Bar::tick() [#126]

wp-cli/rewrite-command

  • Adapter le paquet pour la version 2 du framework [#20]

wp-cli/role-command

  • ajouter l’argument --show-grant à wp cap list et --grant à wp cap add [#19]
  • Ajouter la prise en charge de --field=<field> pour l’affichage des rôles [#17]
  • Adapter le paquet au framework v2 [#23]

wp-cli/scaffold-command

  • Ignorer les tests PHPUnit pour PHP 7.2 et versions ultérieures [#145]
  • Modifier scaffold block pour créer index.js [#142]
  • Corriger les chemins spécifiques aux thèmes dans les blocs générés [#137]
  • Ajouter PHP 7.2 aux modèles CI [#135]
  • Exclure tests/test-sample.php via le fichier phpunit.xml.dist [#134]
  • Corriger l’option sed -i sur MacOS [#132]
  • Utiliser la valeur par défaut correcte de $WP_TESTS_DIR sur MacOS [#131]
  • Utiliser phpunit 6.5.6 pour PHP 7.2 afin de contourner l’incompatibilité avec les tests du cœur. [#125]
  • Corriger WPCSWordPress Community Support Une société d’intérêt public et une filiale de la WordPress Foundation, établie en 2016. lors de la génération des tests de thèmes [#121]
  • Passer le modèle CircleCI à CircleCI 2.0. [#115]
  • Corriger le libellé 'add_new_item' [#163]
  • Exclure les chaînes de l’avertissement d’échappement [#162]
  • Mettre à jour l’ensemble de règles PHPCS par défaut [#161]
  • Ajouter l’option --woocommerce à la commande scaffold _s [#159]
  • Ajouter les sniffssniff Un module de PHP Code Sniffer qui analyse le code à la recherche d’un problème spécifique. Plusieurs sniffs sont combinés pour créer une norme PHPCS. Le terme est utilisé parce qu’il détecte les odeurs de code, de la même manière qu’un chien « renifle » la nourriture. de PHPCompatibility aux éléments générés [#154]
  • Ajouter l’échappement du titre du blocBloc Bloc est le terme abstrait utilisé pour décrire des unités de balisage qui, assemblées, forment le contenu ou la mise en page d’une page web à l’aide de l’éditeur WordPress. L’idée combine les concepts qui, par le passé, pouvaient être réalisés avec des shortcodes, du HTML personnalisé et la découverte d’intégrations, en une API et une expérience utilisateur cohérentes. [#153]
  • Supprimer 'wp-blocks' des dépendances de style [#151]
  • Ajouter une vérification function_exists() au modèle PHP de bloc [#147]
  • Adapter le paquet au framework v2 [#166]

wp-cli/search-replace-command

  • Corriger les tests cassés en raison de l’ajout d’une page « Politique de confidentialité » [#78]
  • Gérer correctement la (dé)sérialisation des classes incomplètes [#76]
  • Gérer correctement les erreurs PCRE [#75]
  • Supprimer le message « Site introuvable » de l’utilisation de multisiteMultisite Multisite est une fonctionnalité de WordPress qui permet aux utilisateurs de créer un réseau de sites sur une seule installation WordPress. Disponible depuis WordPress 3.0, Multisite est la continuation du projet WPMU ou WordPress Multiuser. Le projet WordPress MultiUser a été abandonné et ses fonctionnalités ont été intégrées au cœur de WordPress. Manuel d’administration avancée -> Créer un réseau. [#69]
  • Corriger le test GUID défectueux [#81]
  • Améliorer la logique de --regex-limit [#70]
  • Adapter le paquet au framework v2 [#86]
  • Ajouter l’option --regex-limit. [#62]

wp-cli/server-command

  • Adapter le paquet au framework v2 [#42]

wp-cli/shell-command

  • Adapter le paquet au framework v2 [#25]
  • Mieux expliquer l’option --basic [#23]

wp-cli/widget-command

  • Adapter le paquet au framework v2 [#19]

Contributeurs

Voici la liste complète des personnes formidables qui ont contribué à rendre cela possible :

@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

Un grand merci à toutes les personnes impliquées ! ❤️

#release, #v2-0-0