skip-revisions, select columns, callbacks = The forever reroll #184
Conversation
Added --revision / --no-revision Added --callback Reroll wp-cli#104, wp-cli#128 Fixes wp-cli#125, wp-cli#127, wp-cli#142
There was a problem hiding this comment.
This PR lack tests
It will need tests. We recently got bit by a bad bug: #183
This search-replace code is complex. It's more important that it works properly, vs. adding new features.
tests are always hard and painful to write for external contributors but less time-consuming/easier to write correctly by long-time codebase maintainers.
The only difference between these two groups: one group put in the time to figure out how to write good tests.
Our docs clearly state that tests are required. Additionally, from the homepage: "remember, libre != gratis; the open source license grants you the freedom to use and modify, but not commitments of other people’s time. Please be respectful, and set your expectations accordingly."
Replacement callback & row-based filtering (include/exclude posts revisions)
--whereexpression has been a long requested feature (for more than 6 years)Added --where flag to finely select rows aimed for replacement
Added --revision / --no-revision
Added --callback
Reroll of Feature: Call user function with --callback flag #104 (Dec 2018) and Replacement callback & row-based filtering #128 (Sept 2019) (Feature: Call user function with --callback flag Feature: Call user function with --callback flag #104 )
Fix Filter by post types and post status in post table #125 (Introduce
--whereflag), close Limit search-replace in DB --wp_db_id="wp_posts:1234" (New command parameter) #142Preliminary work for Pass current
$coland$primary_keysdown to the SearchReplacer #127 (Callback access to current primary key & column)I plea upstream to consider the PR without incurring X more extra rerolls to contributors (who already pumped dozens of hours of man work into the useless and error-prone task of rebasing) [The diff talks for itself]
This PR lack tests: Yes because tests are always hard and painful to write for external contributors but less time-consuming/easier to write correctly by long-time codebase maintainers.
Is this feature better inside (without automated tests) rather than unavaiable? I believe so.