Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter by post types and post status in post table #125

Open
1 task done
skorasaurus opened this issue Jul 22, 2019 · 4 comments
Open
1 task done

Filter by post types and post status in post table #125

skorasaurus opened this issue Jul 22, 2019 · 4 comments
Labels

Comments

@skorasaurus
Copy link

skorasaurus commented Jul 22, 2019

Feature Request

Describe your use case and the problem you are facing

I currently use search-replace for batch editing content (when the name of an event that we do has changed for example...)

There's been a couple instances where I would have preferred search-replace to only
edit the content that is currently published (post_status=published) not in past revisions; or only to only change in specified post_types (we updated the url structure for only one kind of custom post_type).

Describe the solution you'd like

I was wondering if it's possible to add an additional parameter to the search-replace command so that when search and replaces are made; the user can specify the
only affect the current revision of content in the wordpress database.
(Thinking aloud this could be done by filtering the post_status or post_type columns for specified values.

(I'd add an extra parameter like post_status=publish which would not update currently published content) using a parameter like --skip-post-status.
Example usage:
wp search-replace 'before' 'after' --skip-post-status=publish --recurse-objects --skip-columns=guid --skip-tables=wp_users

or to only edit certain post types like
--include-post-type-values=my_custom_post_type
Example usage:
wp search-replace 'before' 'after' --include-post-type-values=my_custom_post_type --recurse-objects --skip-columns=guid --skip-tables=wp_users

Filtering out the post_status and post_type columns for their values can be done using a SQL statement but adding this to wp-cli hopefully would be worth doing.

@schlessera
Copy link
Member

Thanks for introducing this feature request.

I don't think it is a good idea to move into that direction, though.

wp search-replace is a DB-level command, not an entity-level command. If we now add post-specific operations, I can already expect the next feature request to be about adding taxonomy-specific operations, etc...

Modifying a post's content is done through the wp post update command, and filtering what posts to work on is done via wp post list. These can then be combined with sed or other tools to make modifications as needed.

@drzraf
Copy link

drzraf commented Sep 17, 2019

I understand the concern, but I'm pretty sure that ignoring revisions is sufficiently common and useful to still be acceptable.
An alternative would be working on user-defined filtering (like the callback PR does for the substitution itself)

@skorasaurus
Copy link
Author

skorasaurus commented Sep 17, 2019

For what it's worth, I learned how to do within strictly SQL (this works for mariadb 10.x), not sure if the syntax would be different for other versions or):

First, go into a sql shell within by wp db cli
Then issue the following command:

update wp_posts SET post_content = REPLACE(post_content, 'before', 'after') where post_status = 'publish';

( note the 'before' and 'after' are case sensitive).

@leymannx
Copy link

Modifying a post's content is done through the wp post update command, and filtering what posts to work on is done via wp post list. These can then be combined with sed or other tools to make modifications as needed.

Indeed I'd agree on that. But then there still are the <old> and <new> options missing to replace strings via the post update command then.

(Coming from [WPSE] How can I search and replace by post type?)

drzraf added a commit to drzraf/search-replace-command that referenced this issue Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants