The Admin Panel

The CWA has no separate CMS URL. Editing happens on the live page — the admin bar overlays the front end, and the manager panel slides up from the bottom when you click a component.

Access

Log in at /login with ROLE_ADMIN credentials. Once logged in, the admin bar appears at the top of every page.

The Admin Bar

The bar shows:

• Edit / Done toggle — activates inline editing mode
• A menu linking to the admin pages: Layouts, Pages, Data, Routes, Users and Settings
• The current page's name with a cog — click it to open that page's settings
• A loading indicator for API activity

Edit Mode

When edit mode is active:

• An empty ComponentGroup shows a dashed placeholder with a single + hotspot — click it to open the "Add Component" dialog
• Click any component to select it and open the manager panel
• The manager panel slides up from the bottom and shows your component's admin tabs
• Right-click a component in the live page layout (not in the /_cwa/ admin pages) to open a context menu listing the nested resources under the cursor — use it to select the parent component position or group instead of the innermost component

The Admin Pages (/_cwa/)

Managing Routes

The /_cwa/routes admin page manages URL paths for pages and redirects.

Editing a path

The path editor uses a prefix + suffix layout. For top-level routes the prefix is / (root) and you type the full slug. For child routes (e.g. a blog article nested under /blog) the Prefix select also offers the parent path — pick it and you only type the suffix. This makes it clear what the final URL will be without having to remember the parent path.

An SEO recommendation appears below the input showing a full path preview built from the parent prefix and a slugified version of the page title. Click it to apply.

When you save a changed path, a dialog asks Update child routes? Confirming it renames all child paths to keep them under the new parent prefix and creates redirects from every old path automatically. Without it only the parent route is renamed (with a redirect from its old path); children keep their old paths.

Visibility

The route editor (a page's Routes tab, also reached from /_cwa/routes) has a Visibility setting that decides whether the public can see the page:

• Live — public now
• Scheduled — public from the date and time you pick in the Goes live field. Times are in your computer's time zone: hover the calendar button to see the zone and its offset at that date, for example "Times are in Europe/London, UTC+01:00"
• Not live — hidden, with the path still reserved. Use it to take a page offline without deleting its route

The change is saved with Save Route.

Choosing Live on a route that is already live keeps its go-live date, which is shown beside the control. Only a route that was scheduled or not live gets the current time. Module builds before 003ab4a9 (cwa-nuxt-module#341) overwrote the date with the current time. Because a route can't go live before its parent, that also moved its child routes' effective dates forward.

Visibility is inherited: a page can't go live before its parent route does, so if the parent is scheduled or not live, the route editor tells you what is holding the page back. The routes list and each route's summary show the state that actually applies, with the go-live date for scheduled routes.

As an admin you can still open, preview and edit a scheduled or hidden page. Visitors get a 404, and it stays out of the sitemap until it goes live. For the full rules see Scheduling and Taking Routes Offline.

Redirects

Each route entry shows two sections:

Forward visitors to — the outbound redirect field. Set this to send visitors arriving at this URL to a different destination. When a redirect target is set and edit mode is active, the admin panel suppresses the redirect so the page remains navigable for editing.

Incoming redirects — the redirectedFrom list. Shows all other routes that currently forward visitors to this route. Useful for auditing redirect chains and identifying stale paths.

Redirects can be chained. The API walks the chain when it serialises a route and returns the final destination as redirectPath — the Nuxt module's route middleware then issues a 308 to it. A chain that loops back on itself is rejected with a circular reference error rather than being followed.

To seed redirects in fixtures, see Data Fixtures → Seeding Redirects.

Adding a Component

1. Enter edit mode
2. In an empty group, click its + hotspot. In a group that already has content, click a component to select it, then use the manager panel's CTA button — Add Before / Add After (or Add to Start / Add to End when the ComponentGroup itself is selected)
3. The "Add Component" dialog lists available component types
4. Select one — if instantAdd: true is set in nuxt.config, it's added immediately; otherwise a config panel appears first
5. The new component is added to the group

Reordering

Select a component and open the manager panel's Order tab. Turn on Enable reordering, then use Move Up / Move Down or type a position number. The module patches sortValue on each ComponentPosition automatically.

The Manager Panel

When you click a component, the manager panel shows all admin/*.vue files for that component type as tabs. Each tab is defined by a call to useCwaResourceManagerTab({ name: 'Tab Name' }) in the Vue file.

Changes in the admin tabs apply to the draft version of the component. Click Publish in the panel to make changes live.

Scheduling a Publish

A component with a draft can be published now or at a later time. Select it and open the manager panel's Publish tab. It says whether the component is Draft, Scheduled or Live, and for a draft it has a Schedule toggle:

• Schedule off: click Publish now to publish the draft straight away.
• Schedule on: pick a date and time, then click Schedule. The state changes to Scheduled. Type into the day, month, year, hour and minute, or use the calendar button. Minutes go in steps of 5, and times before you opened the tab can't be chosen.

A scheduled draft opens with the toggle on. To keep it unpublished, click Cancel schedule, which clears the date.

Scheduling needs @cwa/nuxt 2.0.0-alpha.2 or later.

Visitors see the new version from the scheduled time: the API holds the draft back until then and caps cached responses at that time, see Scheduled Publication and Cache Lifetime. Nothing is pushed to open browsers at that moment, so a page that is already open shows the change the next time it loads.

Deleting is on the panel's Info tab. There is no duplicate/clone action.

Orphaned Resources

Content you remove from a page can leave records behind: a component nothing displays any more, an empty position, or a group nothing owns. The API can report these, and the admin lets you review and delete them. What counts as orphaned is set by the API, see Orphaned resource report.

This needs @cwa/nuxt 2.0.0-alpha.3 or later.

Scanning from site settings

Site settings (/_cwa/settings) has an Orphaned resources section. It shows when the last scan ran, or Never scanned, with two buttons:

• Scan now asks the API for a new report.
• Review orphaned resources opens /_cwa/orphaned.

When the last scan found anything, a notice at the top of settings reads "Orphaned resources discovered", with the count and a Review now button. Opening settings only reads the stored report. It never starts a scan, so the report is only as fresh as the last scan: a scan button here, a delete on /_cwa/orphaned, or the API's scan-orphaned command, which can run on a schedule and email you when the orphans change. The template's production deploy runs it every day at 03:00 London time (see Daily Orphan Scan), so there the report is at most a day old.

After a scan is requested, the page reads the report again every 2 seconds, for about 10 seconds, until its scan time changes. If the API queues the scan for a Messenger worker, the report only changes once a worker runs it, so with no worker running the page shows "The scan has been requested but has not finished yet" and the report stays as it was. The worker setup is in Orphaned resource report.

Reviewing and deleting

/_cwa/orphaned shows the last report in three sections: Components, Component positions and Component groups, each with its count. Before the first scan it has a Scan button instead. The page doesn't link from the admin menu; open it from site settings.

Each row shows the resource's IRI (and, for a component, its collection) with two buttons:

• View shows the resource's data as JSON. For a component this is the published version.
• Delete deletes that resource.

Each section with rows has Delete all, which deletes that section's rows. Delete everything asks the API to delete every orphan it finds when it checks again, including anything that has become unused since the last scan. Every delete asks you to confirm first.

Delete, Delete all and Delete everything each send one request to POST /_/orphaned_resources/delete. The API checks each resource again first and deletes only what is still orphaned, along with what it contains, and an orphaned component takes its unused draft with it. It then refreshes the stored report, and the page reads it again.

Above the buttons, the page then says what was deleted, counting everything the delete took with it, such as "Deleted 2 components and 1 component group, including anything they contained." If nothing went, it says "Nothing was deleted." Each resource you asked for that wasn't deleted is listed with its IRI and the reason:

A report can be minutes old, so something may have been reused since. The rest of your selection is still deleted.

The page shows the report the API stored after the delete. Anything else that has changed since appears when you click Scan again.