search-replace does not update wp_blogs and wp_site tables

[paulschreiber]

• [X] Yes, I reviewed the contribution guidelines.
• [X] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior wp search-replace does not update the wp_blogs and wp_site tables. It appears the wp_blogmeta and wp_sitemeta tables are also affected, but my wp_blogmeta table is empty.

Describe how other contributors can replicate this bug

$ wp search-replace terraso.org terraso.test $ mysql terraso

MariaDB [terraso]> select * from wp_blogs;
+---------+---------+-------------+------+---------------------+---------------------+--------+----------+--------+------+---------+---------+
| blog_id | site_id | domain      | path | registered          | last_updated        | public | archived | mature | spam | deleted | lang_id |
+---------+---------+-------------+------+---------------------+---------------------+--------+----------+--------+------+---------+---------+
|       1 |       1 | terraso.org | /    | 2021-05-07 12:13:50 | 2021-10-11 15:41:43 |      1 |        0 |      0 |    0 |       0 |       0 |
|       4 |       1 | terraso.org | /es/ | 2021-10-04 18:29:57 | 2021-10-11 15:41:43 |      1 |        0 |      0 |    0 |       0 |       0 |
|       6 |       1 | terraso.org | /pt/ | 2021-10-05 15:23:28 | 2021-10-11 15:41:44 |      1 |        0 |      0 |    0 |       0 |       0 |
+---------+---------+-------------+------+---------------------+---------------------+--------+----------+--------+------+---------+---------+

MariaDB [terraso]> select * from wp_site;
+----+-------------+------+
| id | domain      | path |
+----+-------------+------+
|  1 | terraso.org | /    |
+----+-------------+------+

Describe what you would expect as the correct outcome

wp_blogs and wp_sites (and their meta tables) contain terraso.test instead of terraso.org

Let us know what environment you are running this on

OS: Linux 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64
Shell:  /bin/bash
PHP binary: /usr/bin/php7.4
PHP version:    7.4.24
php.ini used:   /etc/php/7.4/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.5.12-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
SQL modes:  STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:    phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:  phar://wp-cli.phar/vendor
WP_CLI phar path:   /srv/www/terraso
WP-CLI packages dir:    /home/vagrant/.wp-cli/packages/
WP-CLI global config:   
WP-CLI project config:  /srv/www/terraso/wp-cli.yml
WP-CLI version: 2.5.1-alpha-41c44d5

[nickbasham-ltnow]

I've been running into the same issue lately. I have a script to pull a remote production database and run search-replace with my local dev environment's url. Search-replace doesn't make any changes, but if I run wp db search, I can see the strings wp search-replace missed.

[paulschreiber]

@nickbasham-ltnow I found supplying the --all-tables flag does what I want.

[nickbasham-ltnow]

@paulschreiber I'll test that, but my problem is actually with search-replace on any table…it's simply not working, and the same with or without the --precise flag. The only thing I can think of is if this might be a problem on an M1 Mac? I wouldn't think so, but that's the only thing that's changed in my setup recently, otherwise it's the same scripts.

[paulschreiber]

@nickbasham-ltnow You're describing a totally different problem. Please file a separate bug, and include the command you are running along with the output, including/especially any errors.

[schlessera]

@paulschreiber The default behavior of search-replace is to act on a single site only, namely the site you've provided via the --url flag (or whatever WP-CLI defaults to when the --url flag was not provided).

The tables that are unaffected by this default behavior are the ones that control the multisite behavior, so this is why you need to provide either --network or --all-tables.

Have you tried the behavior with --network for your use case?