When there are database table permissions errors, search-replace should be able to alert the user.
I was working with an older DB that I had manually imported the wp_posts table with the wrong DB permissions. (the table was read-only)
When I did a dry-run of the search-replace it worked great, showed me all the replacements to be made, etc.
Then when I did a live run, it went through the process and still reported that there were 527 changes to make, but instead of making them it returned Success: 0 Replacements made
I downloaded a more blunt tool for forcing the DB updates through, and that's when I discovered that the table in question is read-only. Once I knew that, the workaround was simple: export the DB to a fresh DB using wp db export and then import that fresh database, which resets the permissions, then search-replace worked like a charm.
I also tried with --verbose and --debug but the critical piece (when the actual SQL is running) is not outputting anything useful.
Output of the Dry Run
Output of the --debug argument on a live run
Proposed solution
It would be more helpful if table permission errors are preventing the actual changing, that this is output.
I'd propose an additional argument of --errors or adding this output to the existing --debug argument.
Thanks for the report, @Benunc! I think it might make even more sense to actually forward errors or warnings, and in this case show an error that a read-only db/table cannot be changed.
Feature Request
Use Case and user story
When there are database table permissions errors, search-replace should be able to alert the user.
I was working with an older DB that I had manually imported the wp_posts table with the wrong DB permissions. (the table was read-only)
When I did a dry-run of the search-replace it worked great, showed me all the replacements to be made, etc.
Then when I did a live run, it went through the process and still reported that there were 527 changes to make, but instead of making them it returned
Success: 0 Replacements made
I downloaded a more blunt tool for forcing the DB updates through, and that's when I discovered that the table in question is read-only. Once I knew that, the workaround was simple: export the DB to a fresh DB using
wp db export
and then import that fresh database, which resets the permissions, thensearch-replace
worked like a charm.I also tried with
--verbose
and--debug
but the critical piece (when the actual SQL is running) is not outputting anything useful.Output of the Dry Run
Output of the --debug argument on a live run
Proposed solution
It would be more helpful if table permission errors are preventing the actual changing, that this is output.
I'd propose an additional argument of
--errors
or adding this output to the existing--debug
argument.