Skip to main content
With the $wsCmsPage module, you access the page document of the currently requested CMS page in the template. The module delivers the JSON document from the object storage unchanged, without renaming or reordering. A typical use case is the CMS page template, which outputs the content of a content page maintained in Strapi.
The module is only populated on CMS pages, i.e. on pages rendered via the CmsPage view controller. On all other pages, $wsCmsPage is empty (null).
Further pages on this topic:
  • Delivery of CMS pages to the shop explains how the pages get into the object storage, how the SEO URL is created, and which fields the shop itself evaluates.
  • Template theme explains the CMS page template and its integration into the base template.

Module overview

Example / excerpt of $wsCmsPage
JSON output
Variables overview

Methods

No methods are available for $wsCmsPage.

Variables

$wsCmsPage.contentType

Returns the Strapi content type the requested page originates from. The content type corresponds to the input mask behind the page and defines which fields an editor can fill in.

$wsCmsPage.meta

Contains the administrative data and the SEO block of the page.
The shop already sets the meta title and meta description itself. In the base template, they are usually output via the functions $wsViews.metaTitle() and $wsViews.metaDescription(), so that all page types are handled consistently. Direct access via $wsCmsPage.meta is only needed if you require the raw values elsewhere.
Which of these fields the shop evaluates and which fields are purely administrative data is described under The SEO block in meta.

$wsCmsPage.fields

Contains the content fields of the page. Each entry has the keys name, type, and value. The shop passes this list on unchanged and does not interpret it. Which field names and components exist depends on the Strapi modeling of the respective shop. For access, the list is converted once into a name/value object:
The pattern applies at every level, including within components (value.fields) and for the blocks of content blocks. The field types and the form of the respective value are described under The field types, migrating existing field accesses under Step 4 and Step 5.
The order of the fields list follows the schema definition and is meaningless for rendering. Therefore, always access fields via name and never via position. The order within an array value (content blocks, repeatable components), by contrast, corresponds exactly to the editor’s arrangement and must be preserved when rendering.

Actions

No actions are available for $wsCmsPage.

Examples

Check a shared base template for CMS content

Since $wsCmsPage is null on all other pages, a shared base template can safely check for it:

Output alternate languages

meta.hreflang is not automatically included in the shop’s hreflang directives, $wsViews.current.getHreflangAutomatic() returns nothing for CMS pages. For output in the HTML head:

Make unknown components visible in test mode

Without an {{ else }} branch, a newly created component that is not implemented in the template silently disappears from the page:

Mark a draft in test mode

A draft (meta.publishedAt is null) is only delivered when test mode is active. This can be made visible in the template: