Quick answer

On December 3, 2025 I renamed WowShipping's primary UI-facing concept from "shipping rules" to "shipping methods" across 45 files, mostly folder and file renames covering carrier forms, condition components, and rate-cost components. A month earlier, on November 4, 2025, I had moved the old "shipping rules" add/edit implementation into a folder explicitly named ShippingRulesAddEdit(Deprecated), rather than deleting it, while its replacement was being built elsewhere. Neither commit explains the business reason for the rename. WowShipping's PHP layer already integrates with WooCommerce's own WC_Shipping_Method class - built by a teammate, not by me - a plausible reason to align the term, but that's inference, not a documented decision. It's the fourth case study in the WowShipping series, paired with the naming convention overhaul →.

TL;DR

TL;DR summary

Problem	WowShipping's primary end-user noun needed to become "shipping methods," while a replacement UI was mid-build
What I did	Isolated the old implementation into an explicitly deprecated folder, then renamed the live feature folder and its dependents a month later
Scope	13 files moved into the deprecated folder; 45 files renamed or touched in the rename itself
What stayed as-is	REST API paths, some internal function names, and one image asset filename still read "shipping-rules" right after the rename
Timeline	Nov 4, 2025 (deprecation move) → Dec 3, 2025 (rename), one month apart
Team	Both changes are mine; the WooCommerce WC_Shipping_Method integration referenced above was built by a teammate
Paired with	Renaming a Component Library to Kebab-Case →

The old implementation, marked deprecated

On November 4, 2025 I moved the existing "shipping rules add/edit" implementation - carrier forms, condition sections, the shipping-zone section, its stylesheet - into a new folder named ShippingRulesAddEdit(Deprecated). Thirteen files changed, and most were near-identical moves. The diff shows zero content change for files like the carrier services and shipping-conditions sections, just a new path. The one file that did change was the live ShippingRulesAddEdit/index.js, which lost 61 lines - its skeleton-loading markup and its imports of the section sub-components were stripped out, while the deprecated copy kept everything intact. That's a deliberate choice. Rather than delete the old implementation while its replacement was being built, I gave it an explicit, unambiguous name and left it in the tree, so anyone opening the codebase later could see exactly what was being replaced.

The rename

A month later, on December 3, 2025, I renamed the feature folder itself: ShippingRules became ShippingMethods, cascading through carrier forms, condition components, rate-cost fields, and the onboarding tour - 45 files in total. Most of those files are pure path renames with no content change. Git tracked them as renames, not deletions-plus-additions, consistent with a folder move rather than a rewrite. A smaller set carried real edits: import-rules.js changed its translated label from "Import Shipping Rules" to "Import Shipping Method," and the feature's own index.js updated its empty-state copy the same way. One file in that commit, src/pages/Settings/index.js, isn't part of the rename at all - it adds an unrelated effect that fetches shipping zones and regions on mount. I can't tell from the diff why it landed in the same commit. I'd already used "method" as a narrower, internal term months earlier. A sectionShippingMethod.js component from July 2025 handled carrier/rate selection within a single shipping rule, before "method" became the product's top-level noun.

Renaming a live, shipping codebase

WowShipping ships to real WooCommerce stores, so a rename here isn't a find-and-replace exercise. Every import had to keep resolving and every merchant-facing screen had to keep working through the transition. The rename commit's own content shows it operated at three different layers, each with a different level of completeness. Folder and file paths were renamed thoroughly - that's the bulk of the 45-file diff. User-facing translated strings were renamed too, wherever the diff touched them. Internal identifiers were a different story. Right after the rename, the page's default export was still ShippingRules(), and its helper components were still named ShippingRulesListEmpty, ShippingRulesListHeader, and ShippingRulesList. The empty-state image still pointed at /assets/img/shipping-rules-empty-list.png, and the REST API paths in ShippingRuleConfigContext.js - a file that itself kept its old name - were almost entirely untouched. Only one navigation-target string in that file was updated. That's not a mistake so much as a scope decision. The rename covered what a user or developer skimming the file tree would see, and left backend plumbing for later. Renaming every layer atomically would mean a much larger, riskier commit on a codebase real stores actively use. Doing the user-visible layer first is a smaller blast radius per change, even if it leaves the vocabulary inconsistent underneath for a while.

FAQ

Why isolate the old implementation into a deprecated folder instead of deleting it during the rename? Because the replacement was still being built. Naming the folder ShippingRulesAddEdit(Deprecated) kept the old, working implementation available for reference or rollback while the new one took shape. Why rename "shipping rules" to "shipping methods" at all? The repo doesn't say - no commit message or comment states the business reason. WowShipping's PHP layer does integrate with WooCommerce's own WC_Shipping_Method class, which already uses "shipping method" as its vocabulary, so aligning the UI term with that is plausible - but that's inference from the code, not a confirmed decision, and that integration class was built by a teammate, not by me. Why leave REST API paths and internal function names as "shipping rules" instead of renaming everything in the same commit? I can't say for certain it was deliberate, but the effect was a smaller, lower-risk commit - user-facing paths and strings changed where a developer or merchant would notice, while backend-facing plumbing was left for a separate pass. Why did the deprecation move and the rename happen a month apart instead of together? The repo doesn't record a reason for the gap. It's consistent with the replacement UI needing that month to reach a state where the rename made sense to apply, but I can't confirm that from the diff alone. The other case studies in this series look at the Select component trade-off → and native drag-and-drop →.

Part of the WowShipping frontend engineering case study series →