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

Manages sites in the MishkaCMS multi-tenant runtime system.

This resource represents individual sites (tenants) in the CMS, each with its own domain,
content, and configuration. Sites serve as the top-level organizational unit, containing
pages, layouts, components, error pages, and JavaScript hooks. The host-based routing system
uses priority ordering to determine which site handles incoming requests when multiple sites
might match a domain pattern.

Sites implement activation/deactivation controls allowing temporary disabling without data
loss, and soft deletion through archival for recovery capabilities. Each site maintains
relationships with all its associated resources, providing complete content isolation in
the multi-tenant architecture. The resource enforces unique constraints on both site names
and hosts to prevent conflicts.

Database-level constraints ensure valid domain formats and prevent modifications to archived
sites. When sites are modified, background jobs are triggered to recompile associated resources.
The resource provides comprehensive access control through the policy system, ensuring proper
authorization for site management operations.

# `t`

```elixir
@type t() :: %MishkaCmsCore.Runtime.Site{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  active: term(),
  aggregates: term(),
  allowed_origins: term(),
  archived_at: term(),
  calculations: term(),
  components: term(),
  error_pages: term(),
  frontend_domain: term(),
  host: term(),
  id: term(),
  inserted_at: term(),
  js_hooks: term(),
  layouts: term(),
  master: term(),
  mode: term(),
  name: term(),
  pages: term(),
  priority: term(),
  updated_at: term(),
  users: term()
}
```

# `__guarded_change__`

Apply the full GuardedStruct pipeline (sanitize → validate → derive →
main_validator) to `attrs` and return either `{:ok, transformed_attrs}`
or `{:error, errors}`. Wire this into an `Ash.Resource.Change` to plug
guardedstruct rules into Ash's changeset pipeline.

The function is named `__guarded_change__` because it does more than
validate — it can also transform values (trim, downcase, slugify,
auto-fill, etc.) before they reach the data layer.

# `__guarded_field_meta__`

O(1) lookup of a field's compile-time metadata by name. Returns
`nil` for unknown fields.

# `__guarded_field_name_set__`

Compile-time-baked `MapSet` of every field name owned by the
`guardedstruct` block. Used by `GuardedStruct.AshResource.Change`
to decide, in O(1), whether a key in `changeset.atomics`
belongs to the pipeline.

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `json_api_match_route`

# `mode_badge_config`

Mode → badge colours and labels, in the shape the Gervaz `:badge` column type expects. Shared by the
Mode table column and the site detail modal so both draw the same badge from one definition.

# `primary_key_matches?`

---

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