# `MishkaCmsCore.Runtime.Resources.Changes.ScheduleSiteRuntime`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/resources/__changes/schedule_site_runtime.ex#L5)

Owns the runtime side of a Site `:create` / `:update` / `:destroy` (archive):
keeps `SiteState` in sync **and** recompiles or purges the site's dependent
parts (Pages, Layouts, ErrorPages, Components, JsHooks, Stylesheets).

On success it classifies the transition from the changeset (old name/active vs
new) and, on the `:maintenance` queue (so it never starves the live `:modules`
queue), enqueues `SiteRuntimeWorker`:

  * **rename** (name changed) → purge the OLD-name artifacts, recompile under the new name
  * **deactivate** (active → false) / **archive** → purge the parts (free RAM)
  * **activate** / **unarchive** → recompile the parts
  * **host** change → rebuild the parts, which are compiled for the site's host — the address a
    page answers on and writes into its head — and the sitemap, every address of which is on
    that host
  * mode/priority/etc. change, or create → just update `SiteState`
  * create → also **provision**, which gives the new site its sign-in pages and the starter
    content a first install gets (the theme, the header, the footer, the `site-main` layout and
    the home page), unless the changeset context carries `auth_pages: :inline` (the caller
    writes them itself)

Under `config :mishka_cms_core, env_test?: true` nothing is enqueued.

`:permanent_destroy` is skipped here — that's owned by `ScheduleSiteTeardown`.
The old name is read from the changeset's pre-image, the only place the DB no
longer has it after a rename.

See `MishkaCmsCore.Runtime.Workers.SiteRuntimeWorker` and
`MishkaCmsCore.Runtime.Handlers.{SiteRuntime, BootHandler}`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*