Search Replace Command Laravel Package

Product Decisions This Supports

• Domain/environment cutovers for WordPress properties. If the portfolio contains any WordPress site (marketing site, blog, legacy CMS), the recurring decision "how do we promote dev → staging → prod without corrupting content?" is answered by this command. It replaces URLs across all tables — including inside PHP-serialized payloads in wp_options, wp_usermeta, and page-builder meta — which is exactly where hand-written UPDATE ... REPLACE() statements silently break sites. That makes it a buy-not-build decision: the alternative is a bespoke script that costs engineering days and fails on serialized lengths.
• Content migration off WordPress into the Laravel product. If the roadmap includes consolidating a WordPress blog/CMS into a Laravel app, this is a prep step, not the migration itself: normalize absolute URLs, strip staging hostnames, and de-duplicate media references before the ETL into Eloquent models. Scope this as a one-day task in the migration epic rather than an unknown.
• Build vs. buy on internal tooling. A PM can kill a "write our own DB search-replace helper" ticket. The hard part is not string matching — it's serialization safety, dry-run diffing, and table/column scoping. This package already ships those; the decision is "pin the version, don't rebuild."
• Support and incident response. When a customer restores a database from another environment, or an HTTPS/www cutover leaves mixed-content references, this is the standard remediation path. Worth a runbook entry so support can resolve it without escalating to engineering.
• Multisite and subdirectory restructuring. Decisions to move a network from subdomain to subdirectory (or vice versa) are gated on whether the data can be rewritten safely and verifiably. The --dry-run and --report-changed-only output gives you a countable blast radius before you commit — that's the artifact you take into a go/no-go review.
• Vendor/version hygiene. Because it's bundled with WP-CLI rather than a standalone dependency, the real decision is "which WP-CLI version do we standardize on across environments" — a small, cheap platform-standardization call.

Caveat to carry into every one of these: this is not a Laravel/Composer package. It's a WP-CLI command for WordPress databases. If the decision at hand concerns a pure Laravel schema, it is out of scope — treat it as a WordPress-operations tool that happens to live in the PHP toolchain.

When to Consider This Package

Adopt (or rather, standardize on) it when:

• You operate at least one WordPress database, even indirectly — including Roots/Bedrock or Trellis stacks, which are Composer-managed PHP and therefore plausibly already in a Laravel team's repo.
• Serialized data is present. If wp_options or post meta holds serialized arrays (page builders, SEO plugins, widget config), a naive SQL replace is a data-corruption risk. This is the single strongest reason to use it.
• You need a reviewable dry run. Non-production verification matters more than speed; you want a diff count before mutating prod.
• Changes are string-level and environment-scoped — hostnames, http→https, path prefixes, brand renames. Not schema changes, not content restructuring.
• You can take a database dump first. Non-negotiable. This tool has no rollback.

Look elsewhere when:

• The target is a Laravel/MySQL schema you own. Use a Laravel migration with DB::table()->update() or raw SQL you control, plus a proper test. Installing a WP-CLI command into a Laravel app is a category error.
• The database is very large or under tight write budgets. Rewriting whole tables is I/O-heavy; on multi-GB datasets you need a batched, chunked approach and a maintenance window — evaluate whether --all-tables fits your downtime tolerance before committing.
• You need guaranteed atomicity or point-in-time recovery. This is a mutating CLI, not a transactional migrator.
• The work is really a CMS migration. Rewriting URLs doesn't convert shortcodes, taxonomies, or page-builder blocks. Budget separately for the ETL, or the migration will look 80% done and deliver 40%.
• The operator has no shell access. No CLI, no tool. Managed-host or GUI-only contexts need a different plan.
• Adoption signal matters to you. 61 stars and an opportunity score of 6 is a weak standalone signal — but note the stars understate it: the command ships with WP-CLI, so real-world usage is far higher than the repo implies. Don't read the star count as a maturity verdict; do read it as "don't expect a large third-party support community."

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed maintenance tool for our WordPress data, and it de-risks the two moments that most often break a WordPress site: moving it between environments and changing its domain. The failure mode it prevents is subtle — content stored in a serialized format gets silently corrupted by ordinary database edits, which surfaces later as broken page layouts and lost settings. Using the standard command instead of a custom script removes that class of incident for roughly the cost of a runbook entry. It is not a strategic investment and not a Laravel dependency; it's hygiene for any WordPress property we keep in the portfolio.

For engineering (one paragraph): wp-cli/search-replace-command is a bundled WP-CLI subcommand (wp search-replace), not a Composer library — do not add it to a Laravel composer.json. It rewrites strings across tables while correctly re-serializing PHP-serialized values and updating their length prefixes, with --dry-run, --report-changed-only, --all-tables, --skip-columns, --precise, and --recurse-objects for controlled execution. Operating rules: always take a dump first (no rollback), always dry-run and record the changed-row counts, scope to --all-tables only when you actually need it, and run inside a maintenance window on large datasets. Known limits: it's string-level only — no shortcode, taxonomy, or block conversion, and JSON payloads nested inside serialized or escaped strings deserve a spot check. If we ever consolidate WordPress content into the Laravel app, this is the normalization step upstream of the ETL, budgeted as a day, not a project.

Ask: approve a one-page runbook plus a pinned WP-CLI version across environments; no procurement, no new vendor.