search-replace-command icon indicating copy to clipboard operation
search-replace-command copied to clipboard

search-replace does not update wp_blogs and wp_site tables

Open paulschreiber opened this issue 3 years ago • 5 comments

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

paulschreiber avatar Oct 12 '21 15:10 paulschreiber

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.

nickbasham-ltnow avatar Apr 01 '22 15:04 nickbasham-ltnow

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

paulschreiber avatar Apr 01 '22 15:04 paulschreiber

@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.

nickbasham-ltnow avatar Apr 04 '22 12:04 nickbasham-ltnow

@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.

paulschreiber avatar Apr 04 '22 17:04 paulschreiber

@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?

schlessera avatar May 30 '22 12:05 schlessera