MishkaCmsCore.Runtime.Resources.Changes.ScheduleSiteRuntime (Mishka CMS Core v0.0.1)

Copy Markdown View Source

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}.