# RENAME.md

The brand name is not decided yet, so the codebase ships with placeholders.

**Run this the moment the name arrives, whatever phase you are on.** At phase 01 it is a find and replace that takes twenty minutes. At phase 12 it is a data migration. Do not save it for the end.

---

## 1. Decide four values

| Value | Rule | Example if the brand were "Nishaan" |
|---|---|---|
| Display name | as the client writes it | `Nishaan` |
| Slug | lowercase, hyphenated, no spaces | `nishaan` |
| PHP prefix | 2 to 4 letters, lowercase, trailing underscore | `nsh_` and `NSH_` |
| Text domain | same as the slug | `nishaan` |

Keep the prefix short. It appears in every function name, class name and meta key.

## 2. Replacements, in this order

Order matters, `brand-commerce` contains `brand`.

| # | Find | Replace with | Where |
|---|---|---|---|
| 1 | `brand-commerce` | `<slug>-commerce` | all files, plus the plugin directory and its main PHP file |
| 2 | `brand-theme` | `<slug>-theme` | all files, plus the theme directory |
| 3 | `wc-bc-` | `wc-<prefix>-` | status slugs |
| 4 | `_bc_` | `_<prefix>_` | meta keys |
| 5 | `BC_` | `<PREFIX>_` | class and constant names |
| 6 | `bc_` | `<prefix>_` | function names, table segments, hook names, CSS class hooks |
| 7 | `'brand'` | `'<slug>'` | text domain in every translation function |
| 8 | `brand/v1` | `<slug>/v1` | REST namespace |
| 9 | `Brand Name` | `<Display Name>` | user-facing copy, README, docs |

Run 3 and 4 before 5 and 6. A bare `bc_` replacement first would still produce the right result inside `_bc_`, but doing the longer, more specific patterns first means every step is unambiguous and you can check each one.

## 3. Rename on disk

```
wp-content/themes/brand-theme/                        -> wp-content/themes/<slug>-theme/
wp-content/plugins/brand-commerce/                    -> wp-content/plugins/<slug>-commerce/
wp-content/plugins/<slug>-commerce/brand-commerce.php -> <slug>-commerce.php
```

## 4. Files that break the build if you miss them

This is the part people forget. Every one of these hard-codes a placeholder and silently breaks something.

| File | What to change | What breaks if you miss it |
|---|---|---|
| `package.json` | **all four build script paths** hard-code `wp-content/themes/brand-theme/assets/...` | `npm run build` and `npm run watch` fail, so `assets/dist/` goes stale and the site loses its CSS |
| `phpcs.xml` | both `<file>` paths, the `prefixes` array `bc_,BC_`, the `text_domain` value `brand` | linting silently checks nothing, and the prefix sniff stops catching unprefixed globals |
| `.gitignore` | the two allowlist lines, `!/wp-content/themes/brand-theme/` and `!/wp-content/plugins/brand-commerce/` | the renamed directories are not tracked at all, and a fresh clone has no code in it |
| `deploy/.cpanel.yml` | the copy paths | deploys push nothing, or push to the old path |
| `tools/hash-assets.js`, `tools/check-budget.js` | the dist path | the manifest is written to the wrong place and every asset URL 404s |
| Theme `style.css` | Theme Name, Text Domain | |
| Plugin main file docblock | Plugin Name, Text Domain, Domain Path | translations never load |
| `composer.json` | name field | |
| `languages/brand-commerce.pot` | filename and header | |

## 5. Verify

```
grep -ri "brand-commerce\|brand-theme\|BC_\|bc_\|_bc_\|'brand'" \
  --include="*.php" --include="*.js" --include="*.scss" \
  --include="*.json" --include="*.xml" --include="*.yml" .
```

Should return nothing but this file and the decision log.

Then, in order:

1. `npm run build` succeeds and writes into the renamed theme directory
2. `composer run lint` passes and actually reports on files (not "0 files checked")
3. `git status` shows the renamed directories as tracked
4. Activate the plugin on a clean install, no fatals
5. Place a test order and confirm the meta keys written carry the new prefix

## 6. If the rename happens after orders exist

Only relevant if orders were already placed on a test or staging site. If nothing has been placed, skip this entirely.

Add a one-off migration in `class-installer.php`, run on a schema version bump, that:

1. Copies every `_bc_*` order meta key to `_<prefix>_*`
2. Maps every `wc-bc-*` status to `wc-<prefix>-*` on existing orders
3. Renames the custom tables, or recreates them and rebuilds from orders using the Tools page rebuild, which is simpler and safer
4. Leaves the old keys in place for one version so a rollback is possible

This is the whole reason to rename early.