Design & Hyvä-Einstellungen

<div class="prose prose-hyva max-w-none"><p>Wie Sie das aktive Theme wechseln und grundlegende Design-Einstellungen im Backend vornehmen.</p><p>Das aktive Theme stellen Sie unter <em>Content &gt; Design &gt; Configuration</em> ein — pro Store View lässt sich ein eigenes Theme zuweisen, falls Sie z. B. für einen bestimmten Markt ein abweichendes Design nutzen möchten.</p> <h3>Was hier sonst noch konfiguriert wird</h3> <ul> <li><strong>Applied Theme:</strong> das aktive Theme auswählen (z. B. das Mironsoft-Hyvä-Theme in diesem Projekt).</li> <li><strong>Other Settings &gt; Pagination:</strong> wie viele Produkte pro Seite standardmäßig angezeigt werden.</li> <li><strong>Watermark:</strong> automatische Wasserzeichen auf Produktbildern (klassisches Luma-Feature, bei Hyvä-Themes oft ungenutzt).</li> <li><strong>HTML Head:</strong> Standard-Meta-Tags, Favicon und Standard-Titel, die als Fallback gelten, wenn eine einzelne Seite keine eigenen SEO-Felder gesetzt hat.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/applied12kategorie.png}}" alt="applied" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/pagination12kategorie.png}}" alt="pagination" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/html12kategorie.png}}" alt="html" /> <h3>Was NICHT im Backend passiert</h3> <p>Bei einem Hyvä-Theme wie in diesem Projekt liegt der Großteil der eigentlichen Design-Arbeit NICHT im Backend, sondern im Theme-Code selbst (Tailwind CSS, .phtml-Templates, Alpine.js-Komponenten) — das Backend steuert primär, WELCHES Theme aktiv ist und ein paar globale Verhaltensoptionen, nicht das visuelle Feintuning selbst. Änderungen an Farben, Abständen, Schriftarten oder dem grundsätzlichen Seitenaufbau erfordern immer einen Eingriff im Theme-Code und einen anschließenden Deploy (siehe die Deploy-Sequenz in der Projektdokumentation), nicht nur eine Backend-Konfiguration.</p> <h3>Design-Konfiguration pro Kategorie/Produkt/CMS-Seite</h3> <p>Zusätzlich zur globalen Theme-Einstellung lässt sich für einzelne Kategorien, Produkte und CMS-Seiten im jeweiligen Formular unter dem Tab "Design" ein abweichendes Layout (z. B. ohne Sidebar) auswählen – das überschreibt die globale Einstellung nur für diese eine Seite.</p> <h3>Pagination und Sortierung im Detail</h3> <p>Unter <em>Content &gt; Design &gt; Configuration</em>, Abschnitt <strong>Other Settings</strong>, lässt sich die Produktlisten-Pagination feiner steuern als nur über die Standardanzahl: Das Feld <strong>Grid per Page Values</strong> definiert, welche Werte Kunden in der Kachelansicht zur Auswahl bekommen (z. B. "12,24,36"), <strong>List per Page Values</strong> das Gegenstück für die Listenansicht. Mit <strong>Default Grid per Page Value</strong> und <strong>Default List per Page Value</strong> legen Sie fest, welcher dieser Werte beim ersten Aufruf vorausgewählt ist, und <strong>Default List Mode</strong> bestimmt, ob Kategorieseiten standardmäßig als Kachel- oder Listenansicht starten.</p> <p>Praxis-Tipp: Das Feld <strong>Allow All Products per Page</strong> aktiviert eine "Alle anzeigen"-Option in der Pagination — bei großen Kategorien mit mehreren hundert Produkten sollte das eher deaktiviert bleiben, da sonst eine einzelne Seitenanfrage sehr viele Produkte gleichzeitig laden und rendern muss.</p> <h3>Suchmaschinen-Robots-Einstellungen</h3> <p>Ebenfalls unter <em>Content &gt; Design &gt; Configuration</em> findet sich der Abschnitt <strong>Search Engine Robots</strong>. Das Feld <strong>Default Robots</strong> steuert den Standard-Meta-Robots-Wert (z. B. "INDEX, FOLLOW" oder "NOINDEX, NOFOLLOW"), der für alle Seiten gilt, sofern nicht eine einzelne Seite eigene Robots-Angaben überschreibt. Über <strong>Edit custom instruction of robots.txt File</strong> lässt sich der Inhalt der ausgelieferten robots.txt direkt im Backend anpassen, ohne die Datei per FTP hochladen zu müssen.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/robots12kategorie.png}}" alt="robots" /> <p>Praxis-Tipp: Auf einer Staging- oder Testumgebung sollte <strong>Default Robots</strong> immer auf "NOINDEX, NOFOLLOW" stehen, damit Suchmaschinen keine Testinhalte indexieren — ein häufiger Fehler ist, diese Einstellung nach dem Go-Live zu vergessen zurückzusetzen.</p> <h3>Design-Änderungen zeitlich planen</h3> <p>Über <em>Content &gt; Design &gt; Schedule</em> lassen sich zeitlich begrenzte Design-Änderungen anlegen, etwa ein Sonder-Layout für eine Kampagne oder einen Feiertag. Ein neuer Eintrag benötigt einen <strong>Store View</strong>, einen Zeitraum über <strong>Date From</strong> und <strong>Date To</strong> sowie entweder ein abweichendes <strong>Custom Design</strong> (Theme) oder ein <strong>Custom Layout Update XML</strong>, das nur innerhalb dieses Zeitraums aktiv ist.</p> <p>Nach Ablauf des Datums schaltet Magento automatisch wieder auf die reguläre Konfiguration zurück, ohne dass manuell etwas zurückgesetzt werden muss — praktisch für saisonale Aktionen, bei denen niemand daran denken muss, das Design am Tag danach wieder umzustellen.</p></div>

<div class="prose prose-hyva max-w-none"><p>Logo, Kontaktdaten und Links in Header und Footer über das Backend anpassen, ohne Code zu schreiben.</p><p>Einige Header-/Footer-Inhalte lassen sich direkt im Backend anpassen, ohne Entwicklerzugriff:</p> <ul> <li><strong>Logo:</strong> unter <em>Content &gt; Design &gt; Configuration</em>, Tab <strong>Header</strong>, ein neues Logo hochladen und dessen Alt-Text sowie Breite/Höhe hinterlegen.</li> <li><strong>Copyright-Text im Footer:</strong> ebenfalls über <em>Content &gt; Design &gt; Configuration</em>, Tab <strong>Footer</strong>.</li> <li><strong>Footer-Links und Kontaktinfos:</strong> in vielen Hyvä-Themes (auch in diesem Projekt) als CMS-Blöcke umgesetzt (siehe Kapitel "CMS-Blöcke verwenden") — dort direkt im Backend editierbar, ohne dass eine Deployment nötig ist.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/header12kategorie.png}}" alt="header" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/footer12kategorie.png}}" alt="footer" /> <p>Strukturelle Änderungen (z. B. neue Spalten im Footer, ein komplett neues Header-Layout) erfordern dagegen Anpassungen am Theme-Code selbst und damit einen Deploy — diese sind über das Backend allein nicht möglich. Für alles, was reiner Text, ein Bild oder ein einfacher Link ist, lohnt sich aber immer zuerst der Blick, ob es nicht schon als CMS-Block oder Konfigurationsfeld im Backend editierbar ist.</p> <h3>Kontaktdaten aus den Store-Informationen</h3> <p>Viele Hyvä-Footer- und Header-Templates greifen nicht auf einen CMS-Block, sondern direkt auf die Store-Stammdaten unter <em>Stores &gt; Configuration &gt; General &gt; General</em>, Abschnitt <strong>Store Information</strong>, zu — hier lassen sich <strong>Store Name</strong>, <strong>Store Phone Number</strong>, <strong>Country</strong> und <strong>VAT Number</strong> hinterlegen. Diese Felder werden häufig für Schema.org-Markup (z. B. Organization- oder LocalBusiness-Daten) sowie für Telefonnummern-Links im Header genutzt.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeinformationen12kategorie.png}}" alt="store" /> <p>Praxis-Tipp: Ändert sich die Telefonnummer oder Adresse, lohnt sich zusätzlich zur Store-Information-Prüfung immer ein Blick in den Theme-Code bzw. die zugehörigen CMS-Blöcke, da manche Hyvä-Themes diese Werte fest im Footer-Template statt aus der Konfiguration beziehen.</p> <h3>Store-View-spezifische Anpassungen (Scope)</h3> <p>Logo, Copyright-Text und viele andere Design-Konfigurationsfelder lassen sich pro Scope setzen: Über den Store-View-Umschalter oben links im jeweiligen Konfigurationsformular wählen Sie zwischen <strong>Default Config</strong>, einer einzelnen Website oder einem einzelnen Store View. Ein auf Store-View-Ebene gesetzter Wert überschreibt den darüberliegenden Website- bzw. Default-Wert nur für diesen einen Store View — praktisch, wenn z. B. ein anderssprachiger Shop-Ableger ein eigenes Logo oder einen eigenen Footer-Text benötigt.</p> <p>Praxis-Tipp: Ein grünes Häkchen neben dem Feld zeigt an, dass hier bereits ein spezifischer Wert für den aktuellen Scope gesetzt wurde (nicht geerbt) — über <strong>Use Default Value</strong> lässt sich diese Überschreibung wieder entfernen, sodass der Wert wieder vom übergeordneten Scope übernommen wird.</p> <h3>CMS-Blöcke für Footer und Header finden und bearbeiten</h3> <p>Um herauszufinden, welcher CMS-Block für einen bestimmten Footer- oder Header-Bereich zuständig ist, navigieren Sie zu <em>Content &gt; Elements &gt; Blocks</em> und nutzen die Suchfunktion nach Titel oder <strong>Block ID</strong> (Identifier), z. B. mit dem Suchbegriff "footer" oder "header". In der Grid-Ansicht zeigt die Spalte <strong>Status</strong> zudem, ob ein Block aktuell aktiv (Enable Block = Yes) ist — ein deaktivierter Block wird im Frontend schlicht nicht ausgegeben, auch wenn das Template ihn referenziert.</p> <p>Praxis-Tipp: Nicht jeder sichtbare Footer- oder Header-Bereich ist zwingend ein CMS-Block — manche Inhalte sind hartcodiert im .phtml-Template. Erscheint ein Bereich nicht in der Blocks-Übersicht, ist eine Code-Anpassung durch die Entwicklung nötig, um ihn überhaupt backend-editierbar zu machen.</p></div>