Updating the catalog was only possible from the admin "Catalog audit" page, which streams `runCatalogAudit` over SSE and always compares against every enabled clone source. This adds the same engine to the terminal so it can be run by hand or from cron: - `scripts/catalog-sync.ts` — CLI driver around `runCatalogAudit`. Prints the live progress, the per-source "on the source but not in this hotel" counts and a summary block; generated catalog SQL is saved to `storage/catalog-sync/*.sql` (gitignored). Supports `--list-sources`, `--sources=<a,b>`, `--icons`, `--nitros`, `--furnidata`, `--structure`, `--check-ids`, `--sql`, `--apply-sql`, `--organize-sql`, `--all`, `--json` and `--fail-on-errors`. - `scripts/catalog-sync.sh` — interactive menu (`pnpm catalog:sync`). Lists the configured sources (so the menu always matches `clone_sources`), lets Habbo (COM) be taken with Enter, and offers audit-only through full repair + applying the catalog SQL, each with a distinct confirmation. With no arguments it needs a terminal; with any flag it passes straight through to the CLI. - `runCatalogAudit` gains `sourceIds` to restrict which sites are compared; omitting it keeps the previous "compare against everything enabled" behaviour. An audit writes nothing, and `--apply-sql` is the only flag that changes the catalog. Verified against the live DB: 16370 items_base rows, 16479 catalog items, 2871 Habbo (COM) entries missing from this hotel.
Scripts Documentation
This directory contains utility scripts for managing the EpicNext-Cms project.
Scripts Overview
| Script | Description |
|---|---|
dashboard.sh |
Main interactive menu to run all other scripts. |
deploy.sh |
Safely redeploys the application by freeing the port first. |
logs.sh |
View logs for cms and mariadb services. |
backup.sh |
Creates a database backup in /backups. |
db-restore.sh |
Restores a database backup. |
db-optimize.sh |
Optimizes database tables. |
docker-prune.sh |
Cleans up unused Docker resources. |
verify-deploy.sh |
Checks if the CMS is reachable after deployment. |
check-env.sh |
Validates .env against .env.example. |
check-security.sh |
Runs pnpm audit and checks for image updates. |
monitor.sh |
Shows system disk/container resource usage. |
perf-report.sh |
Runs performance profiling. |
setup-dev.sh |
Configures development environment. |
check-updates.sh |
Checks for package and image updates. |
sync-readme-versions.mjs |
Syncs the versions in README.md with package.json / .nvmrc. |
maintenance.sh |
Toggles maintenance mode flag. |
doctor.sh |
Runs a system diagnostic report. |
setup-cron.sh |
Configures automated cron jobs. |
alert.sh |
Sends notifications to a configured webhook. |
catalog-sync.sh |
Interactive catalog update against a clone source (see below). |
Usage
Run any script directly, or use the dashboard:
./scripts/dashboard.sh
Keeping the README versions in sync
Bumping a dependency (or the pinned Node.js version) leaves README.md stale.
Rather than editing it by hand, run:
pnpm readme:versions # rewrite README.md to match package.json / .nvmrc
pnpm readme:versions:check # verify only; exits 1 when out of date (used in CI)
It manages the pnpm and Node.js rows of the System Requirements table and
the "Core stack" line. The CI check job runs the --check variant, so a
version change cannot reach main with a stale README — the pipeline fails
until you run pnpm readme:versions.
Updating the catalog (catalog-sync.sh)
Compares this hotel's catalog against a clone source (Habbo and the retros) and
fixes what is broken: missing furniture icons, missing .nitro bundles,
FurnitureData.json drift, orphaned/duplicate catalog rows, and items that
exist in items_base but have no catalog offer.
pnpm catalog:sync # interactive menu
./scripts/catalog-sync.sh --list-sources # which sites can be compared
./scripts/catalog-sync.sh --all --sources=default-habbo-com
./scripts/catalog-sync.sh --all --sql --apply-sql # catalogs changes are written
The menu asks which sources to compare (Habbo (COM) is the preset) and what may be written. With no arguments it needs a terminal; with any flag it skips the menu, so it is usable from cron.
Safety notes:
- An audit writes nothing — no repair flag means read-only.
--apply-sqlis the only flag that changes the catalog, and the generated SQL is always written tostorage/catalog-sync/*.sql(gitignored) so it can be reviewed or replayed by hand.- The engine is the same one the admin Catalog audit page streams
(
runCatalogAudit), so a terminal run and an in-admin run agree. --jsonprints one machine-readable report;--fail-on-errorsexits3when error-severity issues remain, which is what a scheduled check should use.