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

The default base that compiled runtime modules are built on — pages, layouts, components and error
pages alike.

The compilers emit `use <base>, :live_view` into every module they generate, and `<base>` is
whatever `config :mishka_cms_core, :web_module` names. A host that has its own web entrypoint
should point that setting at it, so runtime templates can reach the host's components and `~p`
routes:

    config :mishka_cms_core, web_module: MyAppWeb

Left unset, generation falls back to this module, which supplies the smallest base a HEEx template
can render against: LiveView itself, HTML escaping, `Phoenix.LiveView.JS`, and the core components
whatever `config :mishka_cms_core, :core_components` names. It is still short of a host's base — no
gettext backend, no verified routes — because those are the host's to name. A template written
against them needs the host configured.

## Why the core components are in the smallest base

`MishkaCmsCore.Runtime.PageBuilder.Blocks` and
`MishkaCmsCore.Runtime.PageBuilder.Elements` ship forms built from `<.form>` and `<.input>`, and
`MishkaCmsCore.Runtime.Compilers.LiveViewCompiler.render_template/2` already evaluates them against
the same configured module — so the canvas, the preview and the published page resolve one set of
components. Leaving them out of the base meant a form dropped from the library rendered in the
editor and then failed to compile, on exactly the installs that have named no web module of their
own.

See `MishkaCmsCore.Runtime.Compilers.LayoutCompiler` and its siblings for where the base is emitted,
and `MishkaCmsCore.Runtime.LiveViewHelpers` for the `component/1,2` the same modules import.

---

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