skip-revisions, select columns, callbacks = The forever reroll (now with tests)

[drzraf]

Replacement callback & row-based filtering (include/exclude posts revisions)

• Replacing revisions is confusing (total replacements count) and annoying
• Specifying rows/columns/custom --where expression has been a long requested feature (for more than 8 years)
• Extra flexibility regarding replacements (custom PHP callback) has also been requested multiple times

---

• Added --where flag to precisely select rows aimed for replacement

• Added --revision / --no-revision

• Added --callback

• Reroll of Feature: Call user function with --callback flag #104 (Dec 2018), Replacement callback & row-based filtering #128 (Sept 2019) (Feature: Call user function with --callback flag Feature: Call user function with --callback flag #104 and skip-revisions, select columns, callbacks = The forever reroll #184 (June 2023)

• Fix Filter by post types and post status in post table #125 (Introduce --where flag) and Limit search-replace in DB --wp_db_id="wp_posts:1234" (New command parameter) #142 (--wp_db_id)

• Resolves Pass current $col and $primary_keys down to the SearchReplacer #127 (Callback access to current primary key & column)

[codecov]

Codecov Report

❌ Patch coverage is 95.37037% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/WP_CLI/SearchReplacer.php	77.27%	5 Missing ⚠️

📢 Thoughts on this report? Let us know!

[swissspidy]

Thanks for your PR!

Would it be possible to split it up into 3 individual ones, one per new argument? That would make reviews much easier.

There could also be one .feature file per new argument for example. search-replace-new-options.feature doesn't really make sense (define new... what if we add even newer arguments two months from now 😄)

PS. Notice the lint failure

[drzraf]

• Splitting the *.features: sure. I just did in this later commit (+ phpcs)

• But splitting logically the actual code changes seems over my forces.

1. It would have been humanly impossible for me develop them separately and keep them in sync one with the other and all against upstream branch across these many years and actually use them (maintaining a combined branch).
2. I think this was my last burst of motivation : if anything goes out of sync again, I'm too likely to just definitely give up

I understand it's a significant diff on core code, but: 175 insertions(+), 43 deletions(-) doesn't seem that much considering the amount of capabilities these new options brings to search-replace

• I don't understand the phpstan error:
  php -r '$r["post"]["*"][] = "c"; print_r($r);' is valid.

There is also at least one imperfection I'm aware of:

--where <table>:<col>:<cond> is actually adding <col> restrictions globally (not actually scoped to said table (reusing the logic of --include-columns). Moving the restriction more precisely, within the search and replace inner loops is probably doable, but would be even more complex (to write/assess and review).
It's better left to a future improvement (and the current logic is not breaking anything anyway)

[drzraf]

ping

[swissspidy]

Heya, apologies for missing your previous reply. Thanks a lot for your effort, it's truly appreciated!