operate on files too - important for plugins that cache or generate code

[widepath]

Feature Request

Is your feature request directly related to a specific, existing command? Yes Is your feature request about a new command, or a more general idea? No --- ✅ If you are in the correct location now... --->

• [x] Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

A clear and concise description of what you are actually trying to do, and in what way the current version of WP-CLI is not up to the task.

I do believe it would be helpful if wpcli operated on files, as well as the database. There is a very specific and practical use-case for this: plugins that do some kind of caching or code-generation, eg. formidable.

Formidable generates css files and writes them to the file system. This might include urls that reference the current siteurl or home option. Then later when you update the siteurl or home, because the host name of the site changed, that css file still references the old hostname.

Some plugins have a purge-like feature for caching, but it would be nice if search-replace could dip into the files and fix that problem directly.

Totally open to discussion about this, maybe there's already a solution I don't know about. Would be happy to write this feature if deemed useful to the community.

Describe the solution you'd like

A clear and concise description of what you want to happen. Add any considered drawbacks if you can think of any.

• The search-replace command has an extra option --files that, when added, also performs a search-replace on all the files under wp-content
• PHP serialized values should be handled seamlessly, just like how it does now for the database.
• Matches and replaces will happen just like the way the command works now except it will search for all matches in all files under wp-content and for each file with a match, replace all the old with the new then write those changes to the same file.
• --dry-run should still apply to this as well.
• --verbose will show what was replaced in each file.
• The regexp flags can work the same way.
• Update the docs to reflect these changes.

Problems or weirdness:

• When the file system is less file system-y (S3 or compatible backends, elastic storage systems, redis stores, etc.)
• Multiple levels or recursive serialization (I think this might be a problem now anyways)
• File permissions - the underlying user needs to have file permissions to be able to read/write files
• Platform issues - windows vs linux system paths (probably mostly handled by php)
• Might be good to not operate on non-text-like media, like images
• Maybe the args for [<table>...] could also be files - if one in the list is a file that exists, then the files search-replace will do that one, instead of the database search-replace