Appearance
Federation modes
Federation mode is set at the federation level — every spoke in a federation runs under the same mode. There are three; full conceptual treatment is in Concepts → Federation.
Picking the right mode
| If you want… | Pick |
|---|---|
| Authoring once, distributing to independent spokes | content |
| Single sign-on across spokes; shared identity | identity |
| Both of the above (most common in production) | both |
If you're not sure, start with content. It's the simpler half and you can switch to both later without losing data.
Switching modes
/policies → Federation mode → pick the new mode → save. Behind the scenes:
- The control plane writes the new mode to the federation row.
- It calls
local_nucleuscommon_set_federation_modeagainst every Moodle in the federation. - Each Moodle's plugin re-evaluates which flows are active.
The change takes effect within ~30 seconds. There's no maintenance window — both old and new modes serve traffic during the transition.
What stays per-spoke
A few things stay strictly per-spoke regardless of federation mode:
- Theme + branding (modulo the wizard's brand override)
- Site-level admin settings (mail config, plugins, etc.)
- Local courses (anything created on the spoke and not pulled from the hub)
- Activity completion + grades — stays on the spoke even in identity mode
- Files uploaded to per-spoke courses
The federation runs on top of an otherwise-vanilla Moodle. Disabling it should leave each spoke working as a normal standalone site.
Hub-side: publishing courses (mode A and both)
/courses on the hub Moodle is where you author. Once a course is "published", spokes in subscribe mode will pull it on the next sync. Published courses get a version number; you can publish updates and roll back to a prior version.
Spoke-side: pulling courses (mode A and both)
By default spokes auto-pull. To force a sync, use the spoke's /admin/local/nucleusspoke/pull.php page or POST /api/spokes/:id/actions with { action: "pull_courses" }.
Identity projection (mode B and both)
When a user signs in to a spoke for the first time and identity mode is on, the spoke creates a "projected" user record on the hub. The hub becomes the source of truth for that user's email, display name, and role across the federation. Subsequent logins on other spokes recognise them automatically.
Identity projection is one-way (spoke → hub). Editing a user on the hub doesn't push the change back to spokes; the next spoke login picks up the latest values.