Ref:

The session file appears to map wpcli to the admin_email field, and [email protected] to the admin_password field, however this isn't the case. The order of the values in the file appears to be determined by the order of the parameters as they're processed by the command, not by the order in which they're specified by the value of the --prompt flag.

This is as of commit 0e82566 of this repo.

I have a global wp-cli.yml where I have admin user details saved. Also wpd is aliased to the dev version of wp-cli.

To reproduce the issue:

$ which wpd
wpd: aliased to ~/wp-cli/bin/wp
$ mkdir wpcli-multisite && cd wpcli-multisite && wpd core download
Downloading WordPress 4.9.7 (en_US)...
md5 hash verified: 50efc5822bf550e9a526b9b9f4469b0d
Success: WordPress downloaded.
$ wpd core config --dbname="wpclims"
Success: Generated 'wp-config.php' file.
$ wpd db create
Success: Database created.
$ wpd core multisite-install --url="https://wpcms.test" --title="WPCLI Hack"
Created single site database tables.
Set up multisite database tables.
Success: Network installed. Don't forget to set up rewrite rules (and a .htaccess file, if using Apache).

Then opening the database, I see the following:

Why is this a problem?

When using persistent cache (redis), the value of site_admins is empty, and I lose access to the Network Admin dashboard.

If persistent cache is not used, then wp_load_core_site_options loads all important site meta into memory, and caches them one by one in a global. Because site_admins is present twice, the second one overwrites the first, and because the second one is the valid value, it accidentally works.

If persistent cache IS used, wp_load_core_site_options doesn't do anything, and a call to get_super_admins ends up at get_network_option, which retrieves the option the first time it's needed with

$row = $wpdb->get_row( $wpdb->prepare( "SELECT meta_value FROM $wpdb->sitemeta WHERE meta_key = %s AND site_id = %d", $option, $network_id ) );

That one grabs the first row, which is empty, thereby breaking functionality.

In #37 and #40, we added --skip-content so that users could download WordPress without the default themes and plugins in wp-content. However, this is restricted to the en_US locale of the latest version.

In order to emulate --skip-content for other locales and versions, we could improve WP_CLI\Extractor to skip extraction of the wp-content directory from the archive file.

The following changes need to be made to move the command over to the v2 structure:

• Make sure the correct framework is required:

  composer require wp-cli/wp-cli:^2
  

• Require the testing framework as a dev dependency:

  composer require --dev wp-cli/wp-cli-tests:^0
  

• Use the .travis.yml file from wp-cli/wp-cli:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
  

• Add the default script configuration to Composer file:

    "scripts": {
        "lint": "run-linter-tests",
        "phpcs": "run-phpcs-tests",
        "phpunit": "run-php-unit-tests",
        "behat": "run-behat-tests",
        "prepare-tests": "install-package-tests",
        "test": [
            "@lint",
            "@phpcs",
            "@phpunit",
            "@behat"
        ]
    },
  

• Remove scaffolded binary files:

  git rm bin/install-package-tests.sh
  git rm bin/test.sh
  

• Remove scaffolded Behat setup:

  git rm features/bootstrap/*
  git rm features/extra/*
  git rm features/steps/*
  

• Remove scaffolded Behat tags util script:

  git rm utils/behat-tags.php
  

• Add command packages that are needed for Behat tests as --dev dependencies.
  The following commands are already available, anything else needs to be explicitly required:
  • cli *
  • config *
  • core *
  • eval
  • eval-file
  • help
• Update all dependencies:

  composer update
  

• Optional - Add PHPCS rule set to enable CS & compatibility sniffing:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
  

• Run and adapt tests to make sure they all pass:

  composer test
  

I just made a new build for the 4.9 branch and then I tried upgrading to it via WP-CLI, which I had used to upgrade to a nightly branch build previously. WP-CLI tried to use the previously-cached ZIP:

$ wp core upgrade --force http://wordpress.org/nightly-builds/wordpress-4.9-latest.zip
Starting update...
Using cached file '/root/.wp-cli/cache/core/wordpress-4.9-latest-.zip'...
Unpacking the update...

Obviously this is not what I wanted. So I had to add a cache-busting query parameter to force it to skip the cache.

I think that if the URL contains “nightly-builds” then the caching should be bypassed.

Related: #17

Hi there,

Everytime i try to install wordpress in a regular folder with a subdomain pointing on it, it fails my installation by adding the name of the folder to the URL.

Example: I tried to install a site for testing the new gutenberg-editor on gutenberg.xxx.com. this installation is located on my server in a folder named gutenberg. when the installation finishes the options-table in the db for site-url and home shows me: gutenberg.xxx.com/gutenberg

I installed it with:

wp core install --url=gutenberg.xxx.com \ --title="Gutenberg Test" \ --admin_user=xxx \ --admin_password=xxx \ --admin_email=xxx
I also tried

wp core install --url=gutenberg.xxx.com --title="Gutenberg Test" --admin_name=xxx --admin_password=xxx --admin_email=xxx

On my local machine (with xampp) everything works fine.

Thanks

Hello,
I cannot get wp-cli to create the various pages (about, contact) and menu I got when installing manually. Is that by design?
All I get generated are the post page and the privacy page [2]

The command is successful though, which I why I wonder if that is by design:

$ wp core install --url=https://example.com --title="My Blog" --admin_user="admin" --admin_password='XXXXXXXXXX' --admin_email="[email protected]"                                     
Success: WordPress installed successfully.

[2] From DB server:

$ mysql -ss -e "SELECT post_title,post_status,post_name,post_parent,post_type,menu_order from wp_example.com.wp_posts WHERE post_type = 'page'\G"
*************************** 1. row ***************************
 post_title: Privacy Policy
post_status: draft
  post_name: privacy-policy
post_parent: 0
  post_type: page
 menu_order: 0
*************************** 2. row ***************************
 post_title: Sample Page
post_status: publish
  post_name: sample-page
post_parent: 0
  post_type: page
 menu_order: 0

What is your system?

lsb_release -a

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.5 (stretch)
Release:        9.5
Codename:       stretch

Which version of PHP are you using?

$ which -a php
/usr/bin/php

$ php -v
PHP 7.0.30-0+deb9u1 (cli) (built: Jun 14 2018 13:50:25) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.30-0+deb9u1, Copyright (c) 1999-2017, by Zend Technologies

Are you running suhosin? If so, make sure you've added suhosin.executor.include.whitelist = phar to your php.ini

php -m | grep -i suhosin
N/A

Which version of WordPress are you using?

$ grep '^\$wp_version\s' wp-includes/version.php
$wp_version = '4.9.8';

Can you share the results of which wp ?

which -a wp

/usr/local/bin/wp

stat $(which wp)

  File: /usr/local/bin/wp
  Size: 4577919         Blocks: 3457       IO Block: 131072 regular file
Device: 47h/71d Inode: 68176       Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-05-04 23:25:03.738614771 +0100
Modify: 2018-05-04 23:25:03.906614901 +0100
Change: 2018-05-04 23:25:03.910614904 +0100
 Birth: -

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

wp package list

+------+---------+---------+--------+----------------+
| name | authors | version | update | update_version |
+------+---------+---------+--------+----------------+
+------+---------+---------+--------+----------------+

Albeit --skip-email option is used with wp core install,
sendmail is still invoked, resulting in an error
(because it hadn't been installed/configured on that system).

sh: 1: -t: not found

This is a symptom for invoking sendmail that hadn't been installed and/or configured yet.
So some code in WordPress is indeed still trying to invoke sendmail.

Code with instructions for reliably reproducing the issue:
https://github.com/strarsis/wp-core-skip-email-demo

$ git clone https://github.com/strarsis/wp-core-skip-email-demo
$ cd wp-core-skip-email-demo
$ docker-compose up -d && ./setup.sh localhost 8080

The aforementioned error is logged during the first time setup.

# /usr/local/bin/wp core download --locale=pt_BR --version=4.8 --debug
Debug (bootstrap): No readable global config found (0.048s)
Debug (bootstrap): No project config found (0.048s)
Debug (bootstrap): ABSPATH defined: /var/www/wordpress/ (0.049s)
Debug (bootstrap): Running command: core download (0.049s)
Downloading WordPress 4.8 (pt_BR)...
md5 hash verified: bb0a041d922986f4d730ba176f89cd3e
Error: Couldn't extract WordPress archive. unable to decompress gzipped phar archive "/tmp/wp_595d37a3dad49.tar.gz" to temporary file

The same issue does not seem to happen with the en_US or es_ES locales (haven't had the time to test others).

Manually inspecting and extracting the archive with tar does not indicate there is any issue with it. All the files seem intact.

Currently if you do a wp download --version=4.9.4 it will download and cache a .tar.gz file and if you afterward do a wp download --version=4.9.4 --skip-content for example it will download a new .zip archive.

I think it would be better if we can always stick to downloading zip files so you can reuse archives and save some bandwith, or be able to work disconnected.

Hello

I am seeing the exact same thing as in #19
However, I get it for en_US but not for da_DK:

root@new:/var/www/html# sudo -u wpcli -i -- wp core download --path=/var/www/html
sudo: unable to resolve host new
Downloading WordPress 4.8.2 (en_US)...
md5 hash verified: 2e8744a702a3d9527782d9135a4c9544
Error: Couldn't extract WordPress archive. unable to decompress gzipped phar archive "/tmp/wp_59c27ad33802c.tar.gz" to temporary file

/var/www/html# sudo -u wpcli -i -- wp core download --locale=da_DK --path=/var/www/html
sudo: unable to resolve host new
Downloading WordPress 4.8.2 (da_DK)...
md5 hash verified: ebb3439bf5397abbc8fa3e8f05e84781
Success: WordPress downloaded.

Running wp core update --version=nightly now updates to 4.9 alpha, since core branched 4.8 a few days ago and trunk is now 4.9 alpha.

If the WordPress Beta Tester plugin is used and is set to Bleeding edge nightlies it sticks to 4.8-RC2-40868. It appears to do this by appending a _beta_tester=true flag on the update request (source).

It would be great if WP-CLI supported a version flag such as wp core update --version=beta which stuck to the current beta/RC in the same way that the beta tester plugins appears to.

Might be worth pinging Westi or Dion for clarification.

I have a bunch of machines which have been updated to the latest 4.9.7 release. These machines have a cronjob which daily executes this:

wp core update --minor

These machines also have the German locale pack installed. In order to prevent security issues we also check the ckecksum every hour:

/usr/local/bin/wp checksum core

Recently the update bump wordpress release from 4.9.8 to 4.9.7. Unfortunately all machine showed checksum errors because the wp-config-sample.conf had German content.

I haven't been able to reproduce this. Replacing the wp-config-sample.conf from the English wordpress release fixed it.

Funny enough you cannot force an update to the English installation once you have the German locale pack installed:

www-data@<some-host>:/data/backend/wordpress$ /usr/local/bin/wp core update --locale=en_US
Updating to version 4.9.7 (de_DE)...
PHP Warning:  mkdir(): Permission denied in phar:///usr/local/bin/wp/php/WP_CLI/FileCache.php on line 265
Warning: mkdir(): Permission denied in phar:///usr/local/bin/wp/php/WP_CLI/FileCache.php on line 265
Herunterladen der Aktualisierung von https://downloads.wordpress.org/release/de_DE/wordpress-4.9.7.zip …
Entpacken der aktualisierten Version …
Success: WordPress updated successfully.

Summary

Installing WP via wp core install creates rewrite rules with index.php as prefix, which then causes the .htaccess file never to be written, even not by wp rewrite flush --hard. The installation process via wp-admin produces a different set of rules which does not cause this problem.

Here's the output of wp rewrite list after an installation with wp core install:
cli-rewrite.txt

And here's the output for the same command after an installation via wp-admin:
manual-rewrite.txt

Workaround

Set a custom rewrite structure, such as wp rewrite structure '/%category%/%postname%/' --hard to (a) correct the rewrite rules and (b) force the writing of the .htaccess file.

There's an issue with PHP 7.1.4 and including "wp-include/version.php" when $wp_version is declared global (as is done in Core_Command::download() and Core_Command::update()) in that it doesn't seem to get set (though I haven't been able to find anything about this behaviour elsewhere, which is odd).

This is the cause of the "Make sure files are cleaned up" test failing (#6). A simple fix is to use Core_Command::get_wp_details() instead.

Another issue is the mysql extension being removed in PHP 7 (although it is possible to pecl install it in PHP 7.0 at least), which is only catered for in WordPress >= 3.9 (see trac changeset [27257]).

So upping the versions used to WP >= 3.9 (except for one, as a BC check) fixes that and gets all the tests (bar the BC one) running for PHP >= 7. See gitlost#3. I'll open a PR.

We have a new PHPCS standard for WP-CLI called WPCliCS (props @jrfnl). It is part of the wp-cli/wp-cli-tests package starting with version v2.1.0.

To adopt & enforce this new standard, the following actions need to be taken for this repository:

• Create a PR that adds a custom ruleset phpcs.xml.dist to the repository

  • Add phpcs.xml.dist file
  • Adapt .distignore to ignore phpcs.xml.dist & phpunit.xml.dist
  • Adapt .gitignore to ignore phpunit.xml, phpcs.xml & .phpcs.xml
  • Require version ^2.1 of the wp-cli/wp-cli-tests as a dev dependency

• Make any required changes to the code that fail the checks from the above ruleset in separate PRs

• Merge thre ruleset once all required changes have been processed and merged

A sample PR for a simple repository can be seen here: https://github.com/wp-cli/maintenance-mode-command/pull/3/files

Related wp-cli/wp-cli#5179

The following changes need to be made:

1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:

- composer behat || composer behat-rerun

2. In the composer-json file, the requirement on wp-cli/wp-cli-tests needs to be adapted to require at least v2.0.7:

"wp-cli/wp-cli-tests": "^2.0.7"

3. In the composer-json file, the "scripts" section needs to be extended. Immediately after the line "behat": "run-behat-tests",, the following line needs to be inserted:

"behat-rerun": "rerun-behat-tests",

Here's an example of how this should look like:

When a site is converted to Multisite with wp core multisite-convert, or when Multisite is installed with wp core multisite-install, the relevant Multisite constants are added to wp-config.php, but nothing is added to .htaccess if the server is running on Apache.

Similarly, both of these commands provide an informational message saying "Don't forget to set up rewrite rules", but nothing about .htaccess is mentioned.

WP-CLI could either attempt to write to .htaccess itself, using the same rules that core generates after installing Multisite from the Tools -> Network Setup screen, or it could simply add an extra informational message about .htaccess.

Instead of #3 and wp-cli/wp-cli#3880, we should come up with some reliable abstraction that means we don't have to update tests fro every WordPress release.

When testing to pull latest nightly and assert that they bypass the cache, the upgrader class can throw warnings when the checksums are missing, causing the tests to fail.

With a WordPress site on WordPress 5.1 that I want to downgrade to 5.0.3 for testing:

$ wp core update --version=5.0.3
Success: WordPress is up to date.

There are several problems with this message:

• "Success" is wrong; the installed WordPress version did not change
• "up to date" is not the desired outcome. Could this message be expanded to "Wordpress is up to date at version $version"?
• When attempting to "upgrade" to a version older than the currently-installed version, wp core update doesn't explain to the user why the version was not updated. Some additional verbosity here would be appreciated: "Did not upgrade to 5.0.3 because the newer version 5.1 is already installed. retry with --force to ignore this check."

A solution to this problem might look like:

• Do not display "Success" if the safety checks in wp core update abort an update
• Display the installed version number in "WordPress is up to date" messages
• When an "upgrade" to an older version is blocked by the presence of a newer version, output a message saying that that is the case, listing the newer version currently installed, and provide a "did you mean to --force?" message

$ wp core update --version=5.0.3 --force
Updating to version 5.0.3 (en_US)...
Downloading update from https://wordpress.org/wordpress-5.0.3.zip...
Unpacking the update...
Cleaning up files...
File removed: wp-includes/ms-site.php
File removed: wp-includes/ms-network.php
File removed: wp-includes/js/backbone.js
File removed: wp-includes/js/underscore.js
File removed: wp-includes/js/codemirror/fakejshint.js
File removed: wp-includes/js/codemirror/esprima.js
6 files cleaned up.
Success: WordPress updated successfully.

It seems like the core_updater.lock option isn't removed if we get a timeout from downloads.wordpress.org.

$ wp core update
Updating to version 4.8.2 (en_US)...
Laddar ner uppdatering från https://downloads.wordpress.org/release/wordpress-4.8.2-no-content.zip...
Warning: cURL error 28: Connection timed out after 10000 milliseconds
Error: cURL error 28: Connection timed out after 10000 milliseconds
$ wp core update
Updating to version 4.8.2 (en_US)...
Error: En annan uppdatering körs för närvarande.
$ wp option delete core_updater.lock

(The error message is in Swedish and says: Error: Another update is currently in progress )

See also:
https://core.trac.wordpress.org/ticket/41954

As I find some similar issues which do not help me I need to open this.

Got

Error: Cannot find SSL certificate.

problem when running

$ opt/bin/wp core download --debug
Debug (bootstrap): No readable global config found (0.854s)
Debug (bootstrap): Using project config: /home/www-data/www/wp-cli.yml (0.856s)
Debug (bootstrap): argv: /home/www-data/www/opt/lib/wp-cli/wp-cli/bin/../php/boot-fs.php core download --debug (0.856s)
Debug (bootstrap): ABSPATH defined: /home/www-data/www/srv/ (0.856s)
Debug (bootstrap): Running command: core download (0.857s)
Error: Cannot find SSL certificate.

www-data@41c970c6ce78:~/www$ cat ~/.curlrc
insecure

in this box (docker-compose)

version: '3'

services:
  php:
    image: pretzlaw/php:7.0-apache
    volumes:
      - ".:/var/www"
    environment:
      HTTPD__DocumentRoot: /var/www
      HTTPD_a2enmod: rewrite
      PHP__memory_limit: 512M
      PHP_php5enmod: mysqli xdebug zip

pls halp!

wp core install --url creates wrong URL.
I'm using WP-CLI on FreeBSD with no global installation. I have installed WP-CLI in home directory.
These are commands to reproduce:

[server]:<~/domains/domain.com/public_html>$ wp core install --url='http://www.domain.com/' --title=Example --admin_user=admin [email protected] --skip-email
Admin password: ****
Success: WordPress installed successfully.
[server]:<~/domains/domain.com/public_html>$ wp option get home
http://www.domain.com/domains/domain.com/public_html
[server]:<~/domains/domain.com/public_html>$ wp option get siteurl
http://www.domain.com/domains/domain.com/public_html
[server]:<~/domains/domain.com/public_html>$

I wanted to run this past the maintainers before preparing a pull request:

When running wp core update --force, the process will still abort if another update had been attempted but failed (for example, if the core_updater.lock option was left behind after a failed update). Would it make sense for --force to explicitly clear any locks that might exist, or might this be better served by a new option (e.g. --ignore-lock)?

I would like to suggest to introduce a --no-cache (or similar) option to explicitly avoid to use the cached zip files when performing wp core download. wp-cli/wp-cli#4308

It could be useful in different scenarios and probably not to complicated to implement (I guess).

The core command currently has several failures:

01. version	update_type	package_url
    4.4.10	minor	https://downloads.wordpress.org/release/wordpress-4.4.10-partial-0.zip
    4.7.5	major	https://downloads.wordpress.org/release/wordpress-4.7.5.zip
    In step `Then STDOUT should be a table containing rows:'. # vendor/wp-cli/wp-cli/features/steps/then.php:44
    From scenario `Check for update via Version Check API'.   # vendor/wp-cli/core-command/features/core-check-update.feature:3
    Of feature `Check for more recent versions'.              # vendor/wp-cli/core-command/features/core-check-update.feature
02. version	update_type	package_url
    4.0.18	minor	https://downloads.wordpress.org/release/wordpress-4.0.18-partial-0.zip
    In step `Then STDOUT should be a table containing rows:'.              # vendor/wp-cli/wp-cli/features/steps/then.php:44
    From scenario `No minor updates for an unlocalized WordPress release'. # vendor/wp-cli/core-command/features/core-check-update.feature:44
    Of feature `Check for more recent versions'.                           # vendor/wp-cli/core-command/features/core-check-update.feature
03. $ wp core update --minor
    Updating to version 3.7.21 (en_US)...
    Downloading update from https://downloads.wordpress.org/release/wordpress-3.7.21-partial-9.zip...
    Unpacking the update...
    Success: WordPress updated successfully.
    
    cwd: /tmp/wp-cli-test-run-591f3816366f34.23278218/
    exit status: 0
    In step `Then STDOUT should contain:'.                                 # vendor/wp-cli/wp-cli/features/steps/then.php:15
    From scenario `Update to the latest minor release'.                    # vendor/wp-cli/core-command/features/core-update.feature:34
    Of feature `Update WordPress core'.                                    # vendor/wp-cli/core-command/features/core-update.feature
04. $ wp core update --minor
    Updating to version 4.0.18 (en_US)...
    Descargando paquete de instalación desde https://downloads.wordpress.org/release/wordpress-4.0.18-partial-0.zip...
    Descomprimiendo actualización...
    <p>Algunas de tus traducciones necesitan actualizarse. Espera unos segundos más mientras las actualizamos también.</p>
    <div class="update-messages lp-show-latest"><h4>Actualizando traducciones de Twenty Fifteen (es_ES)&#8230;</h4><p>Descargando traducción desde <span class="code">https://downloads.wordpress.org/translation/theme/twentyfifteen/1.7/es_ES.zip</span>&#8230;</p>
    <p>Descomprimiendo actualización&#8230;</p>
    <p>Instalando última versión&#8230;</p>
    <p>Traducción actualizada con éxito.</p>
    </div><div class="update-messages lp-show-latest"><h4>Actualizando traducciones de Twenty Fourteen (es_ES)&#8230;</h4><p>Descargando traducción desde <span class="code">https://downloads.wordpress.org/translation/theme/twentyfourteen/1.2/es_ES.zip</span>&#8230;</p>
    <p>Descomprimiendo actualización&#8230;</p>
    <p>Instalando última versión&#8230;</p>
    <p>Traducción actualizada con éxito.</p>
    </div><div class="update-messages lp-show-latest"><h4>Actualizando traducciones de Twenty Seventeen (es_ES)&#8230;</h4><p>Descargando traducción desde <span class="code">https://downloads.wordpress.org/translation/theme/twentyseventeen/1.0/es_ES.zip</span>&#8230;</p>
    <p>Descomprimiendo actualización&#8230;</p>
    <p>Instalando última versión&#8230;</p>
    <p>Traducción actualizada con éxito.</p>
    </div><div class="update-messages lp-show-latest"><h4>Actualizando traducciones de Twenty Sixteen (es_ES)&#8230;</h4><p>Descargando traducción desde <span class="code">https://downloads.wordpress.org/translation/theme/twentysixteen/1.3/es_ES.zip</span>&#8230;</p>
    <p>Descomprimiendo actualización&#8230;</p>
    <p>Instalando última versión&#8230;</p>
    <p>Traducción actualizada con éxito.</p>
    </div><div class="update-messages lp-show-latest"><h4>Actualizando traducciones de Twenty Thirteen (es_ES)&#8230;</h4><p>Descargando traducción desde <span class="code">https://downloads.wordpress.org/translation/theme/twentythirteen/1.3/es_ES.zip</span>&#8230;</p>
    <p>Descomprimiendo actualización&#8230;</p>
    <p>Instalando última versión&#8230;</p>
    <p>Traducción actualizada con éxito.</p>
    </div><script type="text/javascript">
    					(function( wp ) {
    						if ( wp && wp.updates.decrementCount ) {
    							wp.updates.decrementCount( "translation" );
    						}
    					})( window.wp );
    				</script>Success: WordPress updated successfully.
    
    Warning: Failed to fetch checksums. Please cleanup files manually.
    cwd: /tmp/wp-cli-test-run-591f387cda1761.89821841/
    exit status: 0
    In step `Then STDOUT should contain:'.                                 # vendor/wp-cli/wp-cli/features/steps/then.php:15
    From scenario `Minor update on an unlocalized WordPress release'.      # vendor/wp-cli/core-command/features/core-update.feature:199
    Of feature `Update WordPress core'.                                    # vendor/wp-cli/core-command/features/core-update.feature

These seem to be due to a version change of WordPress core.

Related: #4

When running wp core multisite-install ... I don't always want to populate wp-config.php with the multisite constant definitions.

It would be nice if this was behind a flag, for example --skip-config.

I use WP-CLI 1.5.1 to configure WordPress 4.9.8.

Install the wordpress is done with command like :
wp core install --url=https://wp.foo.org} --title="the answer is not 42" --admin_user="admin" --admin_password="secretpassword" [email protected] --skip-email

Update the title, after the installation is done, looks to be with command like :
wp option update blogname 'the answer is 42, but the question was wrong'

title and blogname look to be the same object. If yes, using blogname in wp core install instead of title produces less confusion.

Hello,

When running the wp core multisite-convert command on a single-site installation, I get an error of wp_blogs table not being present. However, based on the documentation, those multisite related tables should be created as a part of the convert process.

I have wp-cli in cron jobs to check for updates. What's missing, is a non-0 return code when an update is available. I do a bunch of string matching now, but of course, that's not very robust.

Perhaps extra command-line flags would be the best, as not to break existing scripts.

And, there could be different return codes for major or minor upgrades, to script automatic minor updates, but notify on major, for instance.

In the documentation for wp core install you use wp.dev as an example domain.

then you’ll need to run wp option update siteurl http://wp.dev/wp

However, now that the .dev TLD actually exists and wp.dev is not registered, perhaps this should be changed to example.com or any of the other example domains.

As a side note, http://wp.dev/wp is invalid as the .dev TLD is on the HSTS Preload list.

Would it be possible to cache core checksums?

Does the API response change ever?

It would be useful to be able to easily query the available releases of WordPress core through the .org API and also get the download URLs for a given update.

A use case I'm currently working on that this would benefit is wp-cli/wp-cli-tests#51

After wp-cli/wp-cli#4009 lands, we should revert 6cc4f56

wp core multisite-convert appears to convert a single site install to multisite, but there doesn't appear to be a command that will facilitate converting a multisite back to a single-site install.

Hi!

I have something strange on one of my websites (out of ~140, on which the command works fine), and cannot pinpoint the issue.

wp core is-installed --allow-root && echo $? returns 0 in my project, while a simple PHP file at the root with

require_once 'wp-load.php';
var_dump(is_blog_installed());

called from CLI (php test.php) shows bool(true)

I read about the cache issues, but I cleared and deactivated WP Rocket on that project, with the same results.
Where could that inconsistence come from?

The websites runs perfectly, the other WP CLI commands work good too (wp option get siteurl returns the right value, wp option list returns them all, meaning that the DB is back there, wp theme list, etc.).

Any lead appreciated.

(can be a geeky comment/response, I'll handle).

If I update WP using wp core update I get a lot of unexpected HTML output coming from WordPress itself:

$ wp core update
Updating to version 4.0 (pt_BR)...
Descompactando a atualização...
<p>Algumas traduções precisam de atualização. Descanse por mais alguns segundos, enquanto atualizamos elas também.</p>
<div class="update-messages lp-show-latest"><h4>Atualizando traduções de WordPress (pt_BR)&#8230;</h4><p>Fazendo download da tradução de <span class="code">(http://downloads.wordpress.org/translation/core/4.0/pt_BR.zip)</span>&#8230;</p>
<p>Descompactando a atualização&#8230;</p>
<p>Instalando a versão mais recente&#8230;</p>
<p>Tradução atualizada com sucesso.</p>
</div><script type="text/javascript">
                (function( wp ) {
                    if ( wp && wp.updates.decrementCount ) {
                        wp.updates.decrementCount( "translation" );
                    }
                })( window.wp );
            </script></div></div>Success: WordPress updated successfully.

This output is coming from the new WP code to automatically update translations when updating core.

It seems that WP_CLI\UpgraderSkin is not being used in this context because the static method Language_Pack_Upgrader::async_upgrade() instantiate Language_Pack_Upgrader class with a hard coded skin. I guess we will have to open a new ticket on core. I decided to open an issue here first in case anyone has another idea on how to fix this.

would you know of any reasons why wp cli is not creating the database schema when running install or multisite install?

see an extract of the install here

wp core multisite-install --url='http://site.local/' --title='WordPress Site' --admin_email='[email protected]' --admin_name='admin' --admin_password='xxx' --debug
exit
<div id="error"><p class="wpdberror"><strong>WordPress database error:</strong> [Table &#039;wordpress.wp_options&#039; doesn&#039;t exist]<br /><code>INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`)...

just to confirm show tables on the db shows no tables present when this command is run

Currently check-update shows which version is available, but not what the current version is. One has to check that with a separate command.

Feature request: show the current version in the table with check-update.

Current feature tests for wp-cli/core-command are broken because of an edge case in the way command namespaces are handled. This was fixed in wp-cli/wp-cli with wp-cli/wp-cli#4950.

To get the tests to pass for now, we need to switch to the latest dev stability version of wp-cli/wp-cli until a new stable release of that package has been tagged. We only want to do that in tandem with wp-cli/wp-cli-bundle, though, to keep versions in sync between these two packages.

Once a new stable tag has been pushed for wp-cli/wp-cli, wp-cli/core-command should be moved back to require a stable version again.

wp core install requires --url parameter while
the interactive WordPress setup doesn't ask for it or need it.

For some environments (e.g. docker), this can cause problems because
the host and port have to be known – which can be even impossible in some cases.

Example invocation:

wp core install \
    --allow-root \
    --skip-email \
    --path=/var/www/html \
    --title="Example site" \
    --admin_user=admin \
    --admin_password="test" \
    [email protected]

I tried to download a wp core in Czech with a command wp core download --locale=cs_CZ but it tells me that Error: The requested locale (cs_CZ) was not found. How is that possible? Normally, from a repo I can download a Czech version. Thanks i advance

The Mustache template file required by this repository ( versions.mustache ) is still located in the wp-cli/wp-cli repository. This is an oversight from wp-cli/wp-cli#3728.

It should be moved over to this repository and then later removed from wp-cli/wp-cli once a new release for this package was tagged and required in wp-cli/wp-cli.

• Copy versions.mustache into wp-cli/core-command
• Add versions.mustache to inclusion list in utils/make-phar.php
• Tag a new release of wp-cli/core-command with added file
• Require that release or higher of wp-cli/core-command in wp-cli/wp-cli
• Remove versions.mustache from wp-cli/wp-cli

Running wp core update when:

• core is outdated AND
• site is running on a non-US English site AND
• core has new strings OR
• core is bundled with a version of Akismet that has new strings.

gives the following:

All seems to have worked, but the extra feedback includes messy HTML and JS.

For instance

WP_CLI_STRICT_ARGS_MODE=1 wp core download --path=/var/www/gosh

will download repeatedly.

(Is having to specify WP_CLI_STRICT_ARGS_MODE the only way to get --path recognized?)

I've a PR with this fix plus some miscellaneous test fixes incoming...

CentOS release 6.8 (Final) with PHP 5.3.3 & 7.0.17 for tests.
Installed with proposed procedure

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

In empty directory command fails with

wp core download
Error: This does not seem to be a WordPress install.
Pass --path=path/to/wordpress or run wp core download.

Tried with PHP 7.0 and error is the same.

php70 /usr/local/bin/wp --info
PHP binary:	/opt/remi/php70/root/usr/bin/php
PHP version:	7.0.17
php.ini used:	/etc/opt/remi/php70/php.ini
WP-CLI root dir:	phar://wp-cli.phar
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	1.1.0

php70 /usr/local/bin/wp core download --debug
Debug (bootstrap): No readable global config found (0.009s)
Debug (bootstrap): No project config found (0.01s)
Debug (bootstrap): No package autoload found to load. (0.034s)
Debug (bootstrap): ABSPATH defined: /home/testing/public_html/wordpress/ (0.034s)
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.

Tried with root and custom account - same result.
With missing directory as target error is same. So i think that it doesn't invoke download method at all

wp core download --path='/home/testing/public_html/missing' --debug
Debug (bootstrap): No readable global config found (0.014s)
Debug (bootstrap): No project config found (0.015s)
Debug (bootstrap): No package autoload found to load. (0.051s)
Debug (bootstrap): ABSPATH defined: /home/testing/public_html/missing/ (0.051s)
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.

I'd really like to be able to install WordPress without any default themes or plugins.
I raised this here wp-cli/ideas#59 (raising a new issue on this repo as per the docs)

As @danielbachhuber mentioned --skip-content would be an appropriate flag.

Hello there,

when running "core install" together with --path=..., the base URL gets messed up.

Steps to reproduce:

1. Run wp --path="~/public_html/example.com" core install --url="https://example.com" --title="example" --admin_email="[email protected]" --admin_user="x" (or core multisite-install).
2. Open "https://example.com".
3. Observe errors: All resources (and sub-pages like /wp-admin/) are fetched/embedded from base URL "https://example.com/public_html/example.com".

This error does not happen when I cd into the site directory and perform step 1 without the --path=... parameter.

The "~/public_html/" in the example path above is specific to my install, but I suspect that the "/public_html/example.com" which is appended to the actual base URL is some kind of default value that is not being overwritten by the core install command.

We are managing WordPress core through composer (https://packagist.org/packages/johnpbloch/wordpress-core), so it is not a localized wp package, but often install it in another language than the default en_US. Historically we have then been including translations through composer packages from https://wp-languages.github.io/ (which we probably don't need any more with all the improved language functionality in wp-cli).

However, our problem relates to the install process. Since we don't have use a localized WordPress package (eg that wp core download --locale=sv_SE would have given us), when we run wp core install it will be setup using en_US language.

We can also not run wp languages core activate sv_SE before the install since that requires wp core install to be run first.

We can obviously install/activate another language after installation but that then means that in the installation process, which typically creates a post/page/comment/default category, our content will still be in en_US.

So my suggestion would be to allow wp core install to be used with a language/locale parameter so a site can be installed with a specific language without using a localized wp core package.

I think it makes sense since the actual wp_install function in wp-admin/includes/upgrade.php also got this parameter (think it was added in to WP 4.0).

This would then mean that we could run:

wp language core install sv_SE
wp core install --locale=sv_SE

and then have a site which also have content in the correct language.