BLOCKING: WooCommerce base URL must be declared in Docker Compose, not user-editable #11

New Issue

2026-09-01T22:45:17Z

Ty commented

2026-09-01 22:45:17 +00:00

Problem

The WooCommerce base URL is currently treated as a per-store setting editable through the Settings UI. If two app users can point the same deployment at two different Woo stores, drafts, SKUs, and taxonomy sync split across stores with no single source of truth.

Plan of record

The Docker Compose file is the single source of truth for the WooCommerce base URL. It is declared as a named environment variable (e.g. WOO_BASE_URL) in the compose config, injected into the FastAPI container at startup, and read-only from the application's perspective. No separate config file, no UI field, no database row.

SSL-only constraint

Only HTTPS URLs are supported. The compose value must be an https:// URL; the server rejects any http:// value at startup (or on first use) so plaintext traffic to the store is impossible. This matches the TLS-enforced deployment posture and keeps credentials off the wire in cleartext.

UX requirement

The Settings UI must present the URL as a non-mutable display — read-only text showing the store the user is connected to, so the user always knows which store they are working against. It must not be an editable input.

Docs to update

DEPLOYMENT.md — declare WOO_BASE_URL in the compose example and state it is the plan of record
ARCHITECTURE.md — remove the URL from the mutable settings surface; show it as a deploy-time env var
CONTENT-WOO.md — base URL comes from the environment, not from user settings
OPENAPI.md — drop any editable URL field from SettingsView; document the read-only presentation
AGENTS.md / PROMPTS.md — note the immutability rule so agents don't reintroduce a settings field

Acceptance criteria

WOO_BASE_URL is defined in the compose file and injected at container start
No code path reads the URL from the database or the Settings UI
Settings UI renders the URL as non-editable text
Only https:// URLs are accepted; http:// is rejected at startup or first use
Docs above are updated to match
Smoke test: changing the compose value and restarting the container changes the target store; the UI reflects it read-only

## Problem The WooCommerce base URL is currently treated as a per-store setting editable through the Settings UI. If two app users can point the same deployment at two different Woo stores, drafts, SKUs, and taxonomy sync split across stores with no single source of truth. ## Plan of record The **Docker Compose file** is the single source of truth for the WooCommerce base URL. It is declared as a named environment variable (e.g. `WOO_BASE_URL`) in the compose config, injected into the FastAPI container at startup, and read-only from the application's perspective. No separate config file, no UI field, no database row. ## SSL-only constraint Only **HTTPS** URLs are supported. The compose value must be an `https://` URL; the server rejects any `http://` value at startup (or on first use) so plaintext traffic to the store is impossible. This matches the TLS-enforced deployment posture and keeps credentials off the wire in cleartext. ## UX requirement The Settings UI must present the URL as a **non-mutable display** — read-only text showing the store the user is connected to, so the user always knows which store they are working against. It must not be an editable input. ## Docs to update - DEPLOYMENT.md — declare `WOO_BASE_URL` in the compose example and state it is the plan of record - ARCHITECTURE.md — remove the URL from the mutable settings surface; show it as a deploy-time env var - CONTENT-WOO.md — base URL comes from the environment, not from user settings - OPENAPI.md — drop any editable URL field from SettingsView; document the read-only presentation - AGENTS.md / PROMPTS.md — note the immutability rule so agents don't reintroduce a settings field ## Acceptance criteria - [ ] `WOO_BASE_URL` is defined in the compose file and injected at container start - [ ] No code path reads the URL from the database or the Settings UI - [ ] Settings UI renders the URL as non-editable text - [ ] Only `https://` URLs are accepted; `http://` is rejected at startup or first use - [ ] Docs above are updated to match - [ ] Smoke test: changing the compose value and restarting the container changes the target store; the UI reflects it read-only

Ty added this to the POC milestone 2026-09-01 23:49:47 +00:00

grokbot_ty referenced this issue from a commit

2026-09-02 00:29:12 +00:00

docs(#11): WOO_BASE_URL in compose, HTTPS-only, Settings read-only

grokbot_ty commented

2026-09-02 00:29:28 +00:00

Docs slice for #11 on docs/refactor-v2 @ 3921a9d:

Checked in deploy/docker-compose.yml, deploy/.env.example, deploy/Caddyfile.fragment
WOO_BASE_URL injected at container start; HTTPS-only (FastAPI must refuse http:// at startup — code still pending, not this docs pass)
Settings: GET returns URL for read-only display; PUT not writable; not a SQLite settings row (DATA-MODEL/OPENAPI/AGENTS/ARCHITECTURE/CONTENT-WOO/DEPLOYMENT)

Remaining issue acceptance: compose-change smoke + startup reject http:// need app code (not DOC COMPLETE / not Gate B).

Docs slice for #11 on `docs/refactor-v2` @ `3921a9d`: - Checked in `deploy/docker-compose.yml`, `deploy/.env.example`, `deploy/Caddyfile.fragment` - `WOO_BASE_URL` injected at container start; HTTPS-only (FastAPI must refuse `http://` at startup — **code still pending**, not this docs pass) - Settings: GET returns URL for **read-only** display; PUT not writable; not a SQLite settings row (DATA-MODEL/OPENAPI/AGENTS/ARCHITECTURE/CONTENT-WOO/DEPLOYMENT) Remaining issue acceptance: compose-change smoke + startup reject `http://` need app code (not DOC COMPLETE / not Gate B).

Ty referenced this issue

2026-09-03 02:36:57 +00:00

Test plan: POC acceptance test cases for all milestone issues #19

Ty closed this issue

2026-09-03 03:06:05 +00:00

Ty commented

2026-09-03 03:06:08 +00:00

Docs work complete. All docs on docs/refactor-v2 consistently state that WOO_BASE_URL is the compose-only single source of truth, HTTPS-only, read-only in Settings, and not a settings row. The compose file already declares the env var and the .env.example has the placeholder.

Code acceptance criteria (startup http:// rejection, Settings UI read-only display, smoke test) are deferred until the backend/frontend is implemented. Those will be addressed when the app is built.

Docs work complete. All docs on `docs/refactor-v2` consistently state that `WOO_BASE_URL` is the compose-only single source of truth, HTTPS-only, read-only in Settings, and not a settings row. The compose file already declares the env var and the `.env.example` has the placeholder. Code acceptance criteria (startup `http://` rejection, Settings UI read-only display, smoke test) are deferred until the backend/frontend is implemented. Those will be addressed when the app is built.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Ty_Tech/SlabUploader#11