Skip to content

Data, APIs, and persistence

How menu and navigation data are stored

Menu data

  • Source – The sidebar menu is built from the WordPress admin menu (and optionally FleekDash-specific items). The frontend loads menu data via an API (e.g. wordpressMenuAPI or menu endpoint under /wp-json/fleekdash/v1/ or WordPress REST). The MenuContext (e.g. useMenuContext()) provides adminMenu, isMenuLoading, and methods to update overrides (order, renames, per-role).

  • Overrides – Reordering and renaming are stored as overrides (e.g. in backend or localStorage). The context merges overrides with the base menu so the sidebar and Menu Management drawer see the same list. Reset clears overrides and reloads the base menu.

  • Cache – Menu data can be cached (frontend and backend). Reset Menu (in the sidebar when search returns no results) or Clear cache (in Menu Management) clears cache and forces a fresh load so the sidebar and drawer stay in sync.

WP mode and routing

  • Navigation – Links to WordPress screens use #/wp/<path>?<query> (e.g. #/wp/edit.php?post_type=post). The router matches /_layout/wp/$ and renders the WordPress iframe page, which loads the WordPress URL in an iframe. So WP mode is just another route inside the same SPA.

  • Default mode – "Set as default" (when available) stores the preference (e.g. in localStorage) keyed by menu href or storage key. When you open that menu item from the sidebar, the app can navigate directly to the WP URL so the iframe opens by default.

Admin bar

  • Settings – Stored via the admin bar settings API (e.g. GET/POST .../settings/admin-bar). Theme (light/dark/auto) is persisted so it survives refresh.

Benefit: Menu and WP mode and admin bar are all driven by APIs and stored preferences; one layout, consistent behavior.