Portal home: single Status card; rename params placement API

- Merge initial status and guidance into one wm-card (Status) on Home.
- Add .wm-home-summary styling for the primary status line.
- Replace legacy setParamsPage with setParametersEmbeddedInWifi (matches
  _paramsInWifi / SPA Setup vs WiFi placement); remove setParamsPage.
- Update README, handlers comment, and advanced-options tests.
This commit is contained in:
2026-05-04 12:58:38 +10:00
parent 3af9706f87
commit 93711d981d
7 changed files with 21 additions and 18 deletions
+1 -1
View File
@@ -32,7 +32,7 @@ This fork currently includes the following architectural improvements:
- **Capability-driven UI flags** in bootstrap/API payloads so features like info, update, erase, and action visibility can be controlled by backend state.
- **SPA-native feedback UX** using in-DOM dialog/toast behavior rather than page-based action flows.
- **Request-scoped shell rendering**: the root portal page is built for each `GET /` from `WM_ROOT_SHELL_TEMPLATE` using a fresh placeholder registry. Shell inputs are only `%PAGE_TITLE%`, `%STYLES%`, `%BOOTSTRAP_JSON%`, and `%PORTAL_APP_JS%` — filled in `WiFiManagerHandlers` from WiFiManager state and embedded assets (not from a server-wide template registry).
- **Customization via WiFiManager APIs** (`setTitle`, `setShowInfo`, `setParamsPage`, bootstrap-facing flags, etc.), not by exposing placeholder-registry mutation to consumers.
- **Customization via WiFiManager APIs** (`setTitle`, `setShowInfo`, `setParametersEmbeddedInWifi`, bootstrap-facing flags, etc.), not by exposing placeholder-registry mutation to consumers.
- A clearer separation between:
- shell rendering (handlers + SPA bootstrap)
- JSON API responses