尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證web based POS system with woocommerce sync
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
docker-compose.yml runs the app against local SQLite by default, persisted via a bind-mounted ./data volume (TURSO_DATABASE_URL: file:/app/data/pos.db). Product images and PO attachments persist separately under ./uploads. To use Turso instead, remove that env line and set TURSO_DATABASE_URL to a real libsql:// URL plus TURSO_AUTH_TOKEN.
Always update the checkout before rebuilding — --build only rebuilds from whatever source is already on disk in this directory; it does not pull anything. Run git pull (or git fetch && git reset --hard origin/master) first, every time.檢視完整 README ↗docker-compose.yml runs the app against local SQLite by default, persisted via a bind-mounted ./data volume (TURSO_DATABASE_URL: file:/app/data/pos.db). Product images and PO attachments persist separately under ./uploads. To use Turso instead, remove that env line and set TURSO_DATABASE_URL to a real libsql:// URL plus TURSO_AUTH_TOKEN.
docker compose up -d --build
Always update the checkout before rebuilding — --build only rebuilds from whatever source is already on disk in this directory; it does not pull anything. Run git pull (or git fetch && git reset --hard origin/master) first, every time.
The running app shows exactly which commit it was built from — in Settings and on the login screen (Build: <short sha>) — so a stale deploy is obvious instead of silently running old code. This is detected automatically at build time from .git (see the Dockerfile's build stage), no env var or extra flag needed; it only shows "unknown" if the image was built from a source with no .git at all (e.g. GitHub's "Download ZIP" instead of a clone).
This repo is deployed as a Portainer Git repository stack (Repository URL + branch, not a pasted/uploaded docker-compose.yml) — that's what makes "redeploy" actually fetch new code instead of reusing whatever Portainer cloned last time:
master redeploys on its own.Build: <sha> (Settings, or the login screen before signing in) against the latest commit on GitHub's master branch. If it doesn't match, the stack didn't actually pick up the new code — re-check step 1.Use this when test/demo data needs to be wiped before going live — e.g. after user acceptance testing on the production Docker deployment. Only applies when running on local SQLite (the default); if TURSO_DATABASE_URL is set to a real libsql:// URL, delete/recreate the tables via the Turso dashboard or CLI instead.
docker compose down
rm -f ./data/pos.db ./data/pos.db-wal ./data/pos.db-shm
docker compose up -d
On next boot, database.js recreates the full schema and reseeds defaults — the three built-in security groups (Administrator, Manager, Cashier) and the default admin login admin / 123456 (forced password change on first login).
This wipes all transactions, products, customers, and settings table entries (SMTP, Cloudinary, WooCommerce, tax config, etc.) — those will need to be re-entered after reset.
To also clear test product images and PO attachments, remove their contents before restarting:
rm -rf ./uploads/products/* ./uploads/po-attachments/*