Admin.Web Workspace (PeachStateTechnologies.Cms.Plugins.Admin.Web)

An Angular CLI workspace (angular.json) that builds the two front-ends consumed by the Admin plugin. It's not an independently deployed plugin — it's a build-time dependency, packaged as static web assets inside Plugins.Admin's wwwroot/admin.

Layout

apps/
  dashboard/       PeachGrove Admin — the main back-office SPA
  visual-editor/   Toolbar + outline injected into live front-end pages
libs/
  shared/          Code shared by both apps (see below)

• apps/dashboard — a standard routed Angular app. Feature areas live one-per-folder under src/app/features/* (e.g. pages, page-templates, settings, users), wired up in app.routes.ts with lazy-loaded standalone components, and surfaced in navigation via AdminShell's nav groups (src/app/core/layout/admin-shell.ts).
• apps/visual-editor — not a routed SPA. It builds two Angular Elements custom elements (<cofoundry-visual-editor-toolbar>, <visual-editor-outline>) that Plugins.Admin's VisualEditorScriptGenerator injects into a live front-end page being edited, replacing the page's normal chrome with an editing UI drawn in Shadow DOM. See its top-level main.ts and the extensive inline comments throughout — there's no separate design doc, the code is the documentation.
• libs/shared — consumed by both apps via TypeScript path mapping (no separate library build/pack step): admin-api (typed HTTP client for Plugins.Admin's REST API), bootstrap, custom-entity-picker, document-picker, dynamic-form (renders a block/entity's field schema as a form — the basis of the Visual Editor's generic block editor), image-picker, monaco (shared Monaco editor setup, used by both the page-template source dialog and the Visual Editor's inline source-code dialog).

Local development

From src/PeachStateTechnologies.Cms.Plugins.Admin.Web:

npm ci                     # first time / after dependency changes
npm run start:dashboard    # ng serve — Dashboard dev server
npm run start:visual-editor  # copies HugeRTE runtime assets, builds visual-editor, serves via Vite
npm run build               # builds both apps (production)
npm test                    # runs dashboard, visual-editor, and shared unit tests

Both dev servers need a running backend to actually do anything — start the example site alongside them and authenticate against it. visual-editor isn't served as a standalone page like a normal SPA; it's a toolbar meant to be injected into a real front-end page, so its Vite dev server (vite.visual-editor.config.js) is set up to serve the built custom elements for injection into whatever page you're testing against rather than a page of its own.

Adding a new Dashboard feature

Follow the existing pattern — e.g. features/settings:

1. New folder under features/, with a *-page.ts/.html/.scss standalone component, a .model.ts for its DTOs, and a .service.ts for API calls (typically thin wrappers over libs/shared's admin-api).
2. Add a lazy-loaded route in app.routes.ts.
3. Add a nav entry in AdminShell's nav groups if it should appear in the sidebar.
4. Corresponding Api/<Area> controller + query/command handlers on the Admin plugin backend, following the pattern in Api/Settings or Api/PageTemplates.

Adding a new Visual Editor block editor

Look at an existing one under apps/visual-editor/src/app/ — image-block-editor for a simple dialog-based editor, html-block-inline-editor for an inline (non-dialog) editor, or fall back to generic-block-editor (which drives libs/shared's dynamic-form off the block type's field schema and needs no bespoke UI at all) if a dedicated editor isn't warranted.