OjaMEA PrestaShop — Migration, Cloning & Data-Cleanup Runbook

Version 1.0 · 17 Aug 2026 · authored from the live remediation of the Sept 2025 migration damage.

⚠ Redacted for the Hive App Store. Server IPs, hostnames, DB names/users, the admin directory and exposed-file names are masked because this page is publicly reachable. Full unredacted runbook lives in the secure prestashop-migration-runbook skill. Procedures, lessons & principles are intact. Credentials never live in this doc — they are in each install's app/config/parameters.php; root is via hPanel → Web console.

1 · Infrastructure map

Production — ojamea.com (+ www): Hostinger VPS, KVM 4, 200 GB · host ‹vps-host› · IP ‹ip› · Jakarta · Ubuntu 24.04 · Apache 2.4.58 · PHP 8.2.29 · MySQL. Docroot /var/www/html/ojamea.com/public_html (9.8 GB). DB ‹prod-db›, prefix ps_, admin dir ‹admin-dir›. PrestaShop 8.x · theme v1_organic_33 (ThemeVolty). TLS Let's Encrypt (certbot --apache, auto-renew). Mail: AWS SES eu-west-1:587 out / AWS in. GA4 ‹GA4-id›.

vhost inventra*.conf has no DocumentRoot — it falls through to the Apache default. It is not a second store / dev instance. Housekeeping backlog on the box: a loose .sql dump outside docroot, a .tar.gz backup, a stale backup DB, and a cache___backup dir inside docroot.

Dev / staging: Hostinger VPS KVM 4 · host ‹vps-host› · IP ‹ip› · Ubuntu 24.04 · Apache · PHP 8.2.33 · MySQL (LAMP). Hosts under /var/www/<host>/public_html: the OjaMEA dev store (‹dev-db/user›, prefix ps_, 7.2 GB), the GCC instance (created 17 Aug 2026, ‹gcc-db/user›, 6.6 GB), plus cashflo / comms / events / harvest / trt.

Domain / DNS: intellahivecloud.com (double-L, .com). Registrar Hostinger. NS aster/helios.dns-parking.com. DNS via hPanel → Domains → DNS Manager. Root A record on separate hosting, not the VPS. Common error: the domain is not intelahive.cloud or intellihivecloud.com (the latter exists only as a ServerAlias typo on the prod inventra vhost).

2 · What went wrong (Sept 2025)

Signature: 8,973 of 9,554 products carry date_add of 2025-09-01 or -09-05 — the whole catalogue landed in two days (a further 237 on 2025-10-09). Products were created without image records and without descriptions; the image files were never carried across.

Measure	Count	%
Total products	9,554	100%
Active / Inactive	2,087 / 7,467	22% / 78%
No ps_image row at all	5,543	58%
No description (<20 chars)	7,552	79%
No image AND no description	5,626	59%
Never sold / Has sales	7,306 / 2,248	76% / 24%

The catalogue was mostly damaged, not partially. Any rule that treats "missing data" as "junk row" will delete most of the business.

3 · Hard-won lessons — read before writing any cleanup

3.1 "No description" is NOT junk. A naive rule (no image OR no description AND never sold) flagged 6,637 for deletion — wrong, would have destroyed live inventory. 1,379 of those had a working image and a real price. Corrected tiers cut the safe-delete pile to 1,031. Calibrate "broken" against the population, not an ideal: if 79% of rows lack a field, that field cannot be your deletion criterion.

3.2 Images are sized variants, not a base file. PrestaShop writes only 13110-home_default.jpg, -large_default.jpg, etc. — there is no base 13110.jpg. Test for a known variant (<id>-home_default.jpg), or you report good images as missing.

3.3 .htaccess image rewrites are hostname-locked — THE clone-breaker. PrestaShop bakes the shop domain into every image rewrite rule. Clone to a new host and every friendly image URL 404s while files sit intact (direct /img/p/... paths return 200). Produced 82 broken homepage images on the GCC clone. Fix after every clone/domain change: sed -i 's/<oldhost>/<newhost>/g' $G/.htaccess (or Shop Parameters → Traffic & SEO → Save).

3.4 Never delete products with raw SQL. A product spans ~15 tables; raw DELETE leaves orphans. Use the ORM: $p=new Product($id); if(Validate::isLoadedObject($p)) $p->delete();. Budget ~90s per 1,000; run under nohup.

3.5 Products with sales history are never deletion candidates. Segment first; deactivate, don't delete. On GCC, of 4,515 image-less products, 470 had sales — deactivated.

3.6 Post-migration security sweep, every time. Two publicly-downloadable files (an exposed DB-admin tool and a customer export) were found in the prod web root, dated right after the migration — quarantined to /root/quarantine/. Check: no db-admin tool, *.sql, *.csv, *.tar.gz, phpinfo*, or .git/ inside docroot.

3.7 The Hostinger web terminal truncates long pastes. Heredocs lose their closing delimiter and stray commands run. Prefer scp; else chunked base64 (≤450 chars/line) then base64 -d | gunzip + md5sum. Console URLs are single-use — mint a fresh one; run long jobs under nohup.

3.8 Looks broken but isn't: geolocated city in the top bar is derived from the visitor IP (live), not a misconfig; the maintenance page reappears when your IP changes (add every address to PS_MAINTENANCE_IP); ThemeVolty mega-menu items are cache-dependent and not controlled by the ps_tvcmsmegamenu tables — change them through the theme admin, not the DB.

4 · Clone procedure (validated 17 Aug 2026)

Produces an isolated instance that cannot email customers, cannot be indexed, and cannot touch the source DB.

Snapshot the source — mysqldump --single-transaction --quick --routines --triggers <DB> | gzip > snap.sql.gz then gzip -t. Never proceed without ARCHIVE_OK.
Copy files — rsync -a --exclude 'var/cache/*' $S/ $G/ under nohup (~6–7 GB ≈ 8 min).
New DB & user — create DB (utf8mb4), a dedicated user, grant, import the snapshot. Generate the password on the server; never transcribe it.
Rewrite parameters.php — set new DB/user/pass and fresh cookie_key / cookie_iv (else sessions leak between instances).
Isolate BEFORE reachable — set shop domain; PS_MAIL_METHOD=3 (never send — the single most important line); PS_SHOP_ENABLE=0 (maintenance); set PS_MAINTENANCE_IP; name it "(TEST)"; SSL on.
Block crawlers, clear cache, fix ownership — robots.txt Disallow /; rm -rf var/cache/*; chown -R www-data:www-data.
Fix .htaccess (§3.3) — do not skip.
Apache vhost — clone the conf, swap hostnames, remove any http→https redirect until the cert exists, configtest, reload.
DNS then TLS — add the A record; wait for dig +short; certbot --apache --redirect -d <newhost>.
Verify isolation — storefront 503/200; parameters DB is NOT the source; source still 200; PS_MAIL_METHOD = 3.

5 · Cleanup risk tiers — classify before deleting, never invert

Tier	Definition	Action
A — Empty	No image, no description, price 0, never sold	Safe to delete
B — No image, priced	No image but has price + real SKU	Human review
C — Needs desc	Working image + price, no description	Keep, write copy
C — Complete	Image + description	Keep
D — Has sales	Any purchase history	Never delete — fix / deactivate

Order: snapshot → dry-run & record counts → sanity-check independently → delete tier A only → clear cache & count broken images in-browser → re-measure → decide on tier B. GCC result: 9,534 → tier-A delete → no-image/no-sales delete → 4,459 (89% with images; active-without-image down from thousands to 4). Broken homepage images 82 → 1 after the .htaccess fix.

6 · Production change window & pre-flight

Window: Sat night / Sun (quiet). Sequence: GCC (disposable) → dev → ojamea.com (live) — never skip a stage. Full mysqldump AND docroot tar, both verified, before touching production. Rollback = restore the dump. After scale deletion, add 301s for deleted URLs Google indexed.

Pre-flight: DB dump + gzip -t verified · docroot tar taken · dry-run counts sanity-checked · tier D excluded (confirmed by query) · low-traffic window · rollback written down · .htaccess hostname correct for this instance · post-change storefront + broken-image count + admin all checked.

7 · Open items

Item	Status
~5,500 products missing images	Only recoverable from the pre-Sept-2025 host; absent from both current servers. Old host location unknown.
470 no-image products with sales	Deactivate or source images — do not delete.
Mega-menu not controlled by ps_tvcmsmegamenu	Unresolved — use the theme admin.
Quarantined admin tool + customer export	Decide on permanent deletion.
Stale backup DB · OS updates (140, reboot) · uptime monitoring · scheduled backups	All outstanding.

8 · Principles

Measure the population before defining "broken."
Never delete anything with sales history.
Dry-run, print the count, then execute — every destructive script takes an explicit DELETE argument.
Verified backup before every destructive step — gzip -t, not hope.
Test on a disposable clone, then dev, then production — never fewer than three stages.
Isolate clones before they are reachable — mail off, crawlers blocked, separate credentials.
Check your own instrument — the image-existence test was wrong for hours until verified against the filesystem.
Distinguish "damaged by the migration" from "damaged by the fix" — the 82 broken images were a hostname in .htaccess.

HIVE My Apps