# `MishkaCmsCore.Runtime.Workers.SiteRuntimeWorker`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/workers/site_runtime_worker.ex#L5)

Gives a site created in the admin the content a first install gets, and recompiles or purges a
site's dependent parts when the site is activated / deactivated / renamed / rehosted / archived /
unarchived.
Enqueued by `MishkaCmsCore.Runtime.Resources.Changes.ScheduleSiteRuntime` on the dedicated
`:maintenance` queue, deduped per `site_id`.

  * `"provision"` (create) → `MishkaCmsCore.Install.StarterContent.ensure_auth/1`: the `auth`
    layout, the sign-in pages and the built-in words of its languages; then
    `MishkaCmsCore.Install.StarterContent.seed/2`: the theme, the header, the footer, the
    `site-main` layout and the home page, the installer's own, so every site of an install is
    drawn in the same frame. Both write only what the site is missing, so a job that runs again
    writes nothing twice. The sign-in pages come first: a starter that cannot be written — an
    install with no master site to keep the logo in — is logged, and the site can still be
    signed into. A site that is gone by the time the job runs cancels it. Then the site's `"js"`
    asset job (`BootHandler.asset_job/4`), under its name now: compiling those pages queues its
    CSS and sitemap, but nothing else builds a new site's JS until a JS hook is saved, and
    without it no page of the site connects.
  * `"recompile"` (activate / unarchive) → `BootHandler.compile_site/2`
  * `"rehost"` (a new host) → unload the site's modules, which are compiled for its host
    (`SiteRuntime.unload_modules/2`) → `BootHandler.compile_site/2`
  * `"purge"` (deactivate / archive) → `SiteRuntime.purge_parts/3` (keep templates)
  * `"rename"` → purge under the OLD name (drop templates) → recompile under the new name

The child DB rows still exist here (only permanent-delete removes them), so the
module list is streamed at run time via `SiteRuntime.module_specs/1`.

## Events

  * `"provision"` fires `ensure_auth/1`'s own, `runtime:site:before_auth_pages` and
    `runtime:site:after_auth_pages`.
  * Every other transition fires `runtime:site:before_rebuild` and `runtime:site:after_rebuild`,
    with `%{site_id: site_id, site_name: site_name, transition: transition}`.

---

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