KAPITEL
4 Unterkapitel
Creating and Editing CMS Pages
<div class="prose prose-hyva max-w-none"><p>How to create, design and publish a new content page (e.g. "About Us").</p><p>Manage CMS pages under <em>Content > Elements > Pages</em>. Use <strong>Add New Page</strong> to create a new one – typical examples are "About Us", terms and conditions, a right-of-withdrawal page, or campaign landing pages.</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/newpage7kategorie.png}}" alt="NewPage" />
<h3>The most important fields</h3>
<ul>
<li><strong>Page Title:</strong> the internal title, also shown in the browser tab.</li>
<li><strong>URL Key:</strong> the path the page is reachable under (e.g. "about-us").</li>
<li><strong>Content:</strong> the actual page content – Hyvä themes typically use either the Page Builder or a simple WYSIWYG text field, depending on configuration.</li>
<li><strong>Search Engine Optimization:</strong> meta title, meta description, meta keywords, and the canonical URL field.</li>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/optimation7kategorie.png}}" alt="wichtigstenFelder" />
</ul>
<h3>Design tab</h3>
<p>Under <strong>Design</strong> you can choose a different layout per page (e.g. "1 column" with no sidebar for a full-width landing page) and add a custom <strong>Layout Update XML</strong> if you need to pull in extra blocks. <strong>Custom Design Update</strong> additionally lets you schedule a time-limited, different design for the page (e.g. a campaign look for one week).</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/design7kategorie.png}}" alt="Design tab" />
<h3>Store view assignment</h3>
<p>At the top of the <strong>Content</strong> tab, the <strong>Store View</strong> field determines which store views the page is visible on – for multilingual stores, ideally a separate version of the same page per language, with translated content and its own URL key.</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeview7kategorie.png}}" alt="Store-View-Zuordnung" />
<h3>Publishing</h3>
<p>Don't forget to enable the page via <strong>Enable Page</strong> — newly created pages are active by default, but not automatically linked anywhere. Embedding it in the menu, footer, or as a widget is handled separately (see the "Using CMS Blocks" and "Customizing Header and Footer" chapters).</p>
<h3>Content Heading vs. Page Title</h3>
<p>Next to <strong>Page Title</strong> in the Content tab there's a separate <strong>Content Heading</strong> field. The Page Title only shows in the browser tab and acts as the fallback for the meta title if none is set explicitly. The Content Heading, on the other hand, is rendered as the visible heading (typically an H1) above the page content. The two can deliberately differ – e.g. a short, SEO-focused Page Title paired with a more inviting, longer Content Heading. If you leave Content Heading blank, many themes won't output any automatic heading at all, so behavior depends on the theme.</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/contentheading7kategorie.png}}" alt="ContentHeading" />
<h3>Reserved system pages</h3>
<p>A handful of CMS pages take on technical special roles in the store. Under <em>Stores > Configuration > General > Web</em>, in the <strong>Default Pages</strong> section, you define which CMS page serves as the <strong>CMS Home Page</strong> (storefront homepage), the <strong>CMS No Route Page</strong> (404 error page), and the <strong>CMS No Cookies Page</strong> (notice shown when cookies are disabled). These pages must already exist under <em>Content > Elements > Pages</em> with a meaningful URL key before you can assign them here.</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/defaultpages7kategorie.png}}" alt="Reservierte System-Seiten" />
<p>Practical tip: Build your own designed 404 page instead of relying on the default error page, and register it under Default Pages – it looks far more professional and can include, for example, a search box or links to bestsellers.</p>
<h3>Configuring the WYSIWYG editor</h3>
<p>Whether and how the rich-text editor appears when editing content fields is controlled under <em>Stores > Configuration > General > Content Management</em> via the <strong>Enable WYSIWYG Editor</strong> field. Options include "Disabled Completely" (raw text/HTML only), "Enabled by Default" (editor is active on open), and "Enabled Manually" (editors switch it on via a button when needed). On Hyvä themes using Page Builder, this setting can also affect whether the classic WYSIWYG editor or Page Builder shows up as the default.</p>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/wygoptions7kategorie.png}}" alt="WYSIWYG-Editor" />
<h3>Inserting images into content</h3>
<p>The <strong>Insert Image</strong> button in the WYSIWYG toolbar opens the media browser, which uploads directly into the <em>pub/media/wysiwyg</em> directory and embeds images from there. Unlike product images, these files don't live in the catalog media folder and are managed separately. Practical tip: create topic-based subfolders inside the media browser (e.g. "wysiwyg/pages/about-us") – otherwise hundreds of images pile up unsorted in a single directory over time.</p></div>
Using CMS Blocks
Create reusable content blocks that you can place in multiple spots throughout your store.
CMS blocks (Content > Elements > Blocks) are smaller, reusable content fragments – unlike CMS pages, they don't have their own URL, they get embedded INTO other pages or theme areas instead.
Typical use cases
- Footer content that's the same on every page (opening hours, payment method icons, contact details).
- Static description text at the top of a category (display mode "Static Block and Products", see the "Managing Categories" chapter).
- Banners or notices placed at specific spots in the theme via a widget.
- Recurring text snippets that should appear identically in multiple places in the store, without having to maintain them multiple times.
Structure of a block
Every block has a Block Title (only visible internally, for your own orientation) and a Block ID (the technical identifier it's referenced by, e.g. in a category or via layout XML), plus the actual Content in the WYSIWYG editor.
Embedding it
Once created, you embed the block in three ways: directly in a category (the "Static Block" field, given the right display mode), via a widget anywhere in the theme (see the "Using Widgets" chapter), or – for developers – directly via layout XML using the block ID. Store-view-specific versions of the same block are also possible if you need multilingual content in the same spot.
Enabling and disabling a block
Every block has its own Enable Block field. Turning it off keeps the block in the system – including every reference to it from categories, widgets, or layout XML – but simply stops it from being output at those spots. This is handy for temporarily hiding a block (e.g. a seasonal announcement) without having to remove and later re-add its placements throughout the store.
Store-view-specific block versions
In the edit form, the Store View field determines which store views a block applies to. It defaults to "All Store Views" – for multilingual content, create a separate block per language instead, with the identical Block ID but restricted to the respective store view. Magento then automatically picks the version matching the current store view, without needing to adjust the placement itself (category, widget, layout XML).
Embedding blocks in email templates
Besides categories, widgets, and layout XML, CMS blocks can also be embedded into transactional emails: in templates under Marketing > Communications > Email Templates, the directive {{block id="your_block_id"}} pulls a block's content into the email body – useful for legal notices or seasonal add-ons you want to maintain centrally instead of duplicating them in every single email template.
Naming block IDs sensibly
Since the Block ID must be unique store-wide and is the technical reference point for every placement, it pays to settle on a clear naming convention from the start, e.g. footer_opening_hours or category_shipping_notice. Practical tip: avoid generic IDs like "block1" or "text" – as the number of blocks grows, it quickly becomes unclear where a block is actually used, and accidental overwrites or duplicate blocks become more likely.
Managing the Blog
<div class="prose prose-hyva max-w-none"><p>How to create new posts in the Magefan blog, assign categories, and publish articles.</p><p>Magento doesn't ship with a blog of its own – the widely used solution is the free <strong>Magefan Blog</strong> extension, reachable on this project under <em>Content > Magefan Blog > Posts</em>.</p>
<h3>Creating a post</h3>
<ol>
<li>Under <strong>Add New Post</strong>, enter the title, URL key, and the actual post content (via the WYSIWYG editor).</li>
<li>Assign one or more <strong>Blog Categories</strong> so the post shows up in the right section.</li>
<li>Upload a <strong>Featured Image</strong> – it shows in the blog overview and often as the social media preview image (Open Graph).</li>
<li>Set meta title and meta description under the "Search Engine Optimization" tab.</li>
</ol>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/newpage7kategorie_1.png}}" alt="Beitrag" />
<img loading="lazy"src="{{media url=wysiwyg/handbuch/1kapitel/displaysettings7kategorie.png}}" alt="settings" />
<h3>Scheduling publication</h3>
<p>Enable the post with <strong>Enable Post</strong>; the <strong>Publish Date</strong> field lets you schedule publication for the future too – the post stays hidden until that point in time, even if already saved.</p>
<h3>Blog categories and authors</h3>
<p>Manage the blog categories themselves under <em>Content > Magefan Blog > Categories</em> – structurally similar to regular product categories (its own URL key, its own meta tags), but completely independent of the product catalog. Under <em>Content > Magefan Blog > Authors</em> you can additionally create author profiles with a name, photo and short bio, which can then be assigned to each post.</p>
<h3>Multi-language blogging</h3>
<p>Since Magefan blog posts (unlike categories) are a separate, distinct row per language in the database, every post needs its own version with its own URL key per store view – the link between language versions of the same post is maintained via a shared group key, so switching languages doesn't lead to a 404 page.</p>
<h3>Assigning tags</h3>
<p>Under <em>Content > Magefan Blog > Tags</em> you manage a store-wide tag list which, unlike the hierarchical blog categories, represents looser, cross-topic keywords (e.g. "guides", "tips"). In the post editor, the <strong>Tags</strong> field lets you assign as many of them as you like to a post; new tags can usually be created directly while writing a post, without switching to tag management first.</p>
<h3>Moderating comments</h3>
<p>User comments on posts come together under <em>Content > Magefan Blog > Comments</em>. From there you can review incoming comments before they go live, approving or rejecting them – important for keeping spam and inappropriate content off the storefront before it becomes publicly visible. Whether comments are enabled at all, and how they behave, is controlled via the general blog configuration (see below).</p>
<h3>Short text for overview pages</h3>
<p>Besides the full <strong>Content</strong> field, the post editor has a separate <strong>Short Content</strong> field. This shorter teaser text is shown on the blog overview page, in "Recent Posts" widgets, and similar teaser displays, while the full post text only appears on the single post view. Practical tip: write the short content deliberately as editorial copy instead of letting it auto-generate from the opening lines of the content – that way the teaser can be optimized for curiosity rather than just mirroring the article's intro sentence.</p>
<img loading="lazy"src=" src="{{media url=wysiwyg/handbuch/1kapitel/shortcontent7kategorie.png}}" alt="shortcontent" />
<h3>General blog settings</h3>
<p>Overarching settings for the entire blog live under <em>Stores > Configuration > Magefan Blog</em>. From there you can enable or disable the blog altogether, set the number of posts shown per overview page, and control whether comments are allowed store-wide and whether an RSS feed is offered for the blog. Changes here apply globally to all store views unless overridden at the store view level.</p></div>
Using Widgets
<div class="prose prose-hyva max-w-none"><p>How to place widgets (e.g. product carousels or CMS blocks) at specific spots in your store.</p><p>Widgets (<em>Content > Elements > Widgets</em>) are the tool for showing dynamic or static content at precisely defined spots in the theme, without having to write layout XML yourself.</p>
<h3>Available widget types</h3>
<p>The exact range depends on the installed theme/modules, but common ones include: <strong>CMS Static Block</strong> (embed an existing CMS block), <strong>Catalog Products List</strong> (a product list by criteria like category or bestsellers), <strong>Catalog New Products List</strong> (recently added products), <strong>Catalog Category Link</strong> and <strong>Catalog Product Link</strong> (individual links), and <strong>Recently Viewed/Compared Products</strong>.</p>
<h3>Setting up a widget</h3>
<ol>
<li>Under <strong>Add Widget</strong>, first choose the <strong>Widget Type</strong>.</li>
<li>Select the <strong>Design Theme</strong> the widget should apply to.</li>
<li>Under <strong>Storefront Properties</strong>, set a display name and sort priority.</li>
<li>Under <strong>Widget Options</strong>, define the actual content (e.g. which CMS block or which products, including filter criteria like category or count).</li>
<li>Under <strong>Layout Updates</strong>, define WHERE the widget appears: on which page type (e.g. only category pages, only the homepage), optionally narrowed further to specific categories/products, and in which layout container (e.g. "Sidebar Additional" or "Content Top").</li>
</ol>
<img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/widget7kategorie.png}}" alt="Widget" />
<h3>Typical examples</h3>
<p>A "New in stock" product carousel on the homepage, an info banner only on certain category pages, or a CMS block with opening hours in the footer. Because widgets are configured through the backend UI, they're a good way to place content without needing developer access to the theme files – though the container/block name a widget hooks into is theme-dependent and can't be freely chosen.</p>
<h3>Inserting widgets directly into text</h3>
<p>Besides placement via <strong>Layout Updates</strong>, there's a second, often-overlooked way: in the WYSIWYG editor of a CMS page or CMS block, the <strong>Insert Widget</strong> button opens the same selection dialog used when creating a widget instance. The chosen widget is then inserted as a placeholder directive right at the cursor position in the content – useful when a widget shouldn't sit at a fixed layout position but appear in the middle of running text (e.g. a product carousel between two paragraphs on a landing page).</p>
<h3>Fine-grained page restriction</h3>
<p>In the <strong>Layout Updates</strong> section of a widget instance, the <strong>Display On</strong> selector controls, depending on the chosen widget type, how precisely the display is scoped – ranging from "All Pages" and "Specified Page" to more granular options such as only anchor category pages (with subcategories) or only non-anchor category pages. Below that, a multi-select lets you narrow it further to specific categories or products. Practical tip: after saving, always check both an affected and an unaffected page – a wrongly chosen Display On option is one of the most common reasons a widget "just doesn't show up".</p>
<h3>Ordering multiple widgets in the same spot</h3>
<p>When several widget instances land in the same layout container (e.g. two banners in "Content Top"), the <strong>Sort Order</strong> field under Storefront Properties determines the order they're rendered in – lower values appear first. Without a deliberately set sort order, the output order depends on internal creation order, which can quickly lead to unpredictable display once multiple editors are involved.</p></div>