System

<div class="prose prose-hyva max-w-none"><p>Wann und warum Sie den Magento-Cache leeren müssen, und welche Cache-Typen es gibt.</p><p>Magento cacht aus Performance-Gründen sehr viel — von Layout-Strukturen über Konfigurationswerte bis zu ganzen HTML-Seiten. Verwaltet wird das unter <em>System &gt; Cache Management</em>.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/cache10kategorie.png}}" alt="cache" /> <h3>Die wichtigsten Cache-Typen</h3> <ul> <li><strong>Configuration:</strong> alle Einstellungen aus Stores &gt; Configuration.</li> <li><strong>Layout:</strong> zusammengeführte Layout-XML-Strukturen.</li> <li><strong>Block HTML output:</strong> gerenderte Block-Fragmente.</li> <li><strong>Full Page Cache:</strong> komplette, fertig gerenderte Seiten — der wirkungsvollste, aber auch am häufigsten zu leerende Cache.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/configuration10kategorie.png}}" alt="configuration" /> <h3>Wann leeren?</h3> <p>Nach Änderungen an Konfiguration, Design, CMS-Inhalten oder Theme-Dateien ist der Cache oft nicht automatisch aktuell. Über <strong>Flush Magento Cache</strong> leeren Sie alle Typen auf einmal; über die Checkboxen daneben auch gezielt einzelne Typen. Steht der Status eines Typs auf "Invalidated" (statt "Enabled"), hat Magento selbst erkannt, dass er veraltet ist — ein Klick auf <strong>Flush Magento Cache</strong> genügt dann. In der Produktion sollten Sie NICHT den kompletten Ordner <code>var/cache</code> von Hand löschen, sondern immer die Backend-Funktion oder <code>bin/magento cache:flush</code> nutzen.</p> <h3>Weitere Cache-Typen im Überblick</h3> <p>Neben den bereits genannten Haupttypen listet <em>System &gt; Cache Management</em> weitere, seltener beachtete Cache-Typen auf: <strong>Compiled Config</strong> (die aus DI-Konfiguration zusammengeführte Dependency-Injection-Struktur), <strong>DB DDL operations</strong> (Tabellenstrukturen, die Magento zur Laufzeit abfragt), <strong>Web Services</strong> (Metadaten der REST/GraphQL-APIs), <strong>Translations</strong> (Übersetzungswerte aus i18n-CSV-Dateien und Backend-Übersetzungen) sowie <strong>Collections Data</strong> und <strong>Reflection Data</strong> (interne PHP-Reflection-Informationen für Performance-Optimierungen). Diese Typen müssen Sie im Alltag praktisch nie manuell leeren — sie werden fast ausschließlich nach Deployments oder Code-Änderungen relevant.</p> <h3>Zusätzliche Buttons unter "Additional Cache Management"</h3> <p>Unterhalb der Cache-Typ-Tabelle finden Sie den Bereich <strong>Additional Cache Management</strong> mit zwei eigenständigen Buttons: <strong>Flush Catalog Images Cache</strong> löscht die im Dateisystem zwischengespeicherten, in verschiedenen Größen generierten Produktbilder — hilfreich, wenn nach einem Bildaustausch noch alte Thumbnails angezeigt werden. <strong>Flush JavaScript/CSS Cache</strong> entfernt die zusammengeführten und minifizierten CSS/JS-Dateien aus <code>pub/static</code>. Beide Buttons wirken unabhängig vom Haupt-Cache und sind bei Theme- oder Bild-Problemen oft der schnellere Weg als ein kompletter Flush.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/additional10kategorie.png}}" alt="additional" /> <h3>cache:clean vs. cache:flush</h3> <p>Auf der Kommandozeile stehen zwei ähnlich klingende, aber unterschiedlich wirkende Befehle zur Verfügung: <code>bin/magento cache:clean</code> entfernt nur die eigentlichen Cache-Einträge (per Tag), lässt aber die Cache-Infrastruktur selbst intakt. <code>bin/magento cache:flush</code> leert dagegen den kompletten zugrunde liegenden Speicher (z. B. das komplette Redis-DB-Segment) — was bei gemeinsam genutzten Cache-Backends auch Daten anderer Anwendungen betreffen kann. Praxis-Tipp: Im Regelbetrieb reicht <code>cache:clean</code> fast immer aus; <code>cache:flush</code> ist eher für "harte Resets" reserviert.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/flush10kategorie.png}}" alt="flush" /> <h3>Cache-Backend und Full-Page-Cache-Modus</h3> <p>Ob Magento den eingebauten Dateisystem-/Redis-Cache oder Varnish für den Full Page Cache nutzt, wird nicht in <em>System &gt; Cache Management</em> selbst festgelegt, sondern unter <em>Stores &gt; Configuration &gt; Advanced &gt; System &gt; Full Page Cache</em> über das Feld <strong>Caching Application</strong> (Built-in Application oder Varnish Caching). Welches Speicher-Backend (Dateisystem, Redis) für die einzelnen Cache-Typen selbst verwendet wird, ist dagegen keine Backend-Einstellung, sondern wird in der Datei <code>app/etc/env.php</code> unter dem Schlüssel <code>cache</code> konfiguriert und erfordert einen Deploy, keinen Admin-Login.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/fullpage10kategorie.png}}" alt="fullpage" /> </div>

<div class="prose prose-hyva max-w-none"><p>Was Indexer im Hintergrund tun, warum Preise oder Bestand manchmal verzögert erscheinen, und wie Sie neu indexieren.</p><p>Magento speichert Produktdaten normalisiert in vielen Tabellen. Damit die Anzeige im Shop trotzdem schnell bleibt, werden diese Daten regelmäßig in vorberechnete, schlanke "Index"-Tabellen umgewandelt — diesen Vorgang übernehmen die Indexer, verwaltet unter <em>System &gt; Index Management</em> bzw. <code>bin/magento indexer:status</code>.</p> <img loading="lazy"src="{{media url=wysiwyg/handbuch/1kapitel/index10kategorie.png}}" alt="index" /> <h3>Die wichtigsten Indexer</h3> <ul> <li><strong>Product Price:</strong> berechnet finale Preise inkl. Preisregeln, Steuern und Kundengruppen vor.</li> <li><strong>Catalog Search:</strong> baut den Suchindex (bei diesem Projekt: OpenSearch).</li> <li><strong>Category Products / Product Categories:</strong> Zuordnung zwischen Produkten und Kategorien.</li> <li><strong>Stock:</strong> Bestand pro Produkt und Quelle.</li> </ul> <h3>Update-Modi</h3> <p>Jeder Indexer läuft entweder im Modus <strong>Update on Save</strong> (sofort bei jeder Änderung — gut für kleine Kataloge) oder <strong>Update by Schedule</strong> (per Cron-Job im Hintergrund — nötig bei größeren Katalogen, da sonst das Speichern eines Produkts im Backend spürbar langsam würde). Wenn eine Preis- oder Bestandsänderung im Shop nicht ankommt, ist meist ein Indexer der Übeltäter: Status unter <em>System &gt; Index Management</em> prüfen, bei Bedarf <code>bin/magento indexer:reindex</code> ausführen oder in der Konfiguration nachsehen, ob der Cron-Job überhaupt läuft.</p> <h3>Weitere Indexer im Überblick</h3> <p>Neben den bereits genannten gibt es unter anderem den Indexer <strong>Product EAV</strong> (baut flache, attributbasierte Tabellen für schnelle Produktabfragen auf), <strong>Customer Grid</strong> (versorgt das Kundenraster im Backend mit einer performanten, denormalisierten Datenbasis) und <strong>Design Config Grid</strong> (indiziert individuelle Theme-Zuweisungen pro Store View). Auch diese Indexer erscheinen in der Tabelle unter <em>System &gt; Index Management</em> und lassen sich dort genauso überwachen und steuern wie die häufig genannten Kern-Indexer.</p> <h3>Status-Spalten richtig lesen</h3> <p>Die Tabelle unter <em>System &gt; Index Management</em> zeigt zu jedem Indexer zwei getrennte Informationen: die Spalte <strong>Status</strong> (Ready / Reindex Required / Processing) gibt an, ob der Index aktuell konsistent ist, während <strong>Update Required</strong> (bei "Update by Schedule"-Indexern) zusätzlich anzeigt, ob noch offene Änderungen auf den nächsten Cron-Durchlauf warten. Steht ein Indexer dauerhaft auf "Reindex Required", obwohl der Cron-Job läuft, deutet das meist auf einen Fehler im letzten Indexierungslauf hin — einen Blick in <code>bin/log system.log</code> bzw. <code>exception.log</code> lohnt sich dann.</p> <img loading="lazy"src=" src="{{media url=wysiwyg/handbuch/1kapitel/update10kategorie.png}}" alt="update" /> <h3>Modus direkt im Backend umschalten</h3> <p>Der Wechsel zwischen <strong>Update on Save</strong> und <strong>Update by Schedule</strong> muss nicht zwingend über die Kommandozeile erfolgen: In der Tabelle unter <em>System &gt; Index Management</em> lassen sich einzelne oder mehrere Indexer per Checkbox markieren und über das Dropdown <strong>Actions</strong> direkt auf den jeweils anderen Modus umstellen — praktisch, wenn ein Shop-Betreiber ohne SSH-Zugriff kurzfristig reagieren muss.</p> <h3>Gezielt neu indexieren und zurücksetzen</h3> <p>Statt immer alle Indexer auf einmal neu aufzubauen, lässt sich mit <code>bin/magento indexer:reindex &lt;indexer_id&gt;</code> gezielt ein einzelner Indexer aktualisieren (die verfügbaren IDs listet <code>bin/magento indexer:info</code> auf). Der Befehl <code>bin/magento indexer:reset</code> setzt einen Indexer explizit auf "invalid" zurück, ohne ihn neu zu berechnen — nützlich, um vor einem geplanten, vollständigen Neuaufbau (z. B. nach einem großen Datenimport) einen sauberen Ausgangszustand zu erzwingen.</p></div>

<div class="prose prose-hyva max-w-none"><p>Die generische Import/Export-Funktion für Produkte, Kunden und weitere Datentypen im Backend.</p><p>Das generische Import/Export-Werkzeug unter <em>System &gt; Data Transfer</em> ist nicht nur für Produkte gedacht (siehe Kapitel "Produktimport und -export"), sondern für mehrere Entitätstypen nutzbar:</p> <ul> <li><strong>Products</strong>, <strong>Advanced Pricing</strong>: Produktdaten bzw. reine Preis-/Sonderpreis-Updates.</li> <li><strong>Customers Main File</strong>, <strong>Customer Addresses</strong>: Kundenstammdaten und Adressen.</li> </ul> <h3>Empfohlener Ablauf</h3> <ol> <li>Immer zuerst unter <em>System &gt; Export</em> einen Export des betroffenen Datentyps machen — das liefert die exakte Spaltenstruktur als Vorlage.</li> <li>Änderungen in der CSV-Datei außerhalb von Magento vornehmen (z. B. in einer Tabellenkalkulation), dabei die Spalte mit dem eindeutigen Schlüssel (z. B. <code>sku</code> bei Produkten, <code>email</code> bei Kunden) nicht verändern, wenn bestehende Datensätze aktualisiert werden sollen.</li> <li>Unter <em>System &gt; Import</em> Entity Type und Import Behavior wählen und mit <strong>Check Data</strong> zunächst nur prüfen.</li> <li>Erst nach fehlerfreier Prüfung mit <strong>Import</strong> tatsächlich importieren.</li> </ol> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/export10kategorie.png}}" alt="export" /> <p>Bei sehr großen Dateien (mehrere zehntausend Zeilen) kann der Import über die Weboberfläche an Zeitlimits stoßen — in solchen Fällen ist ein serverseitiger Import per <code>bin/magento</code>-Kommandozeile oder ein individuell entwickelter Data-Patch (wie z. B. bei diesem Handbuch selbst) die robustere Alternative.</p> <h3>Import Behavior verstehen</h3> <p>Auf der Import-Seite entscheidet das Feld <strong>Import Behavior</strong> darüber, wie die Datei mit vorhandenen Daten zusammenspielt: <strong>Add/Update</strong> legt neue Datensätze an und aktualisiert bestehende anhand des Schlüsselwerts (z. B. <code>sku</code>), ohne nicht erwähnte Felder zu löschen. <strong>Replace</strong> ersetzt komplette Datensätze — Felder, die in der CSV-Datei fehlen, werden dabei auf ihren Standardwert zurückgesetzt, was bei unvollständigen Exporten schnell zu Datenverlust führen kann. <strong>Delete</strong> löscht ausschließlich anhand der angegebenen Schlüsselspalte, alle übrigen Spalten werden ignoriert. Praxis-Tipp: Für laufende Preis- oder Bestandspflege ist fast immer <strong>Add/Update</strong> die richtige Wahl.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/importbehavior10kategorie.png}}" alt="behavior" /> <h3>Fehlerbehandlung beim Import steuern</h3> <p>Über das Feld <strong>Validation Strategy</strong> legen Sie fest, wie Magento auf fehlerhafte Zeilen reagiert: <strong>Stop on Error</strong> bricht die Prüfung beim ersten Fehler ab, <strong>Skip error entries</strong> überspringt fehlerhafte Zeilen und importiert den Rest trotzdem. Das danebenliegende Feld <strong>Allowed Errors Count</strong> definiert bei "Skip error entries", wie viele fehlerhafte Zeilen insgesamt toleriert werden, bevor der komplette Import doch abgebrochen wird — bei sehr großen Dateien mit bekannten Ausreißern empfiehlt es sich, diesen Wert bewusst hochzusetzen statt auf 0 zu belassen.</p> <h3>Produktbilder beim Import mitliefern</h3> <p>Sollen beim Produktimport auch neue Bilder gesetzt werden, genügt die CSV-Datei allein nicht: Die Bilddateien müssen zusätzlich in einem Verzeichnis unterhalb von <code>pub/media/import</code> liegen (Standardname z. B. <code>product_images</code>), und der relative Pfad wird über das Feld <strong>Images File Directory</strong> auf der Import-Seite angegeben. In den CSV-Spalten wie <code>base_image</code> oder <code>additional_images</code> reicht dann jeweils nur der Dateiname. Alternativ lässt sich beim Upload direkt eine ZIP-Datei mit CSV und Bildordner gemeinsam hochladen.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/file10kategorie.png}}" alt="file" /> <h3>Import History – vergangene Importe nachvollziehen</h3> <p>Unter <em>System &gt; Import History</em> protokolliert Magento jeden durchgeführten Import mit Zeitstempel, ausführendem Benutzer, Entity Type und Import Behavior. Über den Link <strong>Import Log</strong> in der jeweiligen Zeile lässt sich das vollständige Protokoll inklusive aller gemeldeten Fehler und Warnungen als Datei herunterladen — hilfreich, wenn im Nachhinein geklärt werden muss, welcher Import bestimmte Produktänderungen verursacht hat. Ein automatisches Rückgängigmachen eines Imports bietet Magento allerdings nicht; im Zweifel hilft nur ein erneuter Import mit korrigierten Daten oder ein Restore aus einem Datenbank-Backup.</p></div>

<div class="prose prose-hyva max-w-none"><p>Weitere Admin-Benutzer anlegen und über Rollen genau festlegen, was sie im Backend dürfen.</p><p>Backend-Benutzer und ihre Rechte verwalten Sie unter <em>System &gt; Permissions</em> in zwei zusammenhängenden Bereichen:</p> <h3>User Roles</h3> <p>Eine Rolle definiert, WELCHE Bereiche des Backends zugänglich sind — unter <em>Role Resources</em> wählen Sie per Baumstruktur genau die Menüpunkte aus, die für diese Rolle sichtbar sein sollen (z. B. eine Rolle "Support" nur mit Zugriff auf Bestellungen und Kunden, ohne Zugriff auf Systemeinstellungen oder Zahlungsdaten). Zusätzlich lässt sich unter <em>Role Resources &gt; Advanced</em> beschränken, auf welche Websites/Stores sich die Rolle bezieht.</p> <h3>All Users</h3> <p>Hier legen Sie die eigentlichen Benutzerkonten an (<strong>Add New User</strong>) und weisen jedem eine der zuvor definierten Rollen zu. Ein neuer Benutzer benötigt mindestens Benutzername, E-Mail, Passwort sowie Ihr eigenes aktuelles Passwort zur Bestätigung.</p> <p><strong>Grundregel:</strong> Vergeben Sie nie mehr Rechte als für die jeweilige Aufgabe nötig — ein Mitarbeiter, der nur Bestellungen bearbeitet, braucht keinen Zugriff auf Systemkonfiguration oder Zahlungseinstellungen. Das begrenzt den möglichen Schaden bei einem kompromittierten Konto erheblich.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/newrole10kategorie.png}}" alt="new" /> <h3>Zwei-Faktor-Authentifizierung (2FA)</h3> <p>Seit Magento 2.4 ist das Modul für die Zwei-Faktor-Authentifizierung standardmäßig aktiv und verlangt beim ersten Login jedes Admin-Benutzers die Einrichtung eines zweiten Faktors, üblicherweise per Authenticator-App (z. B. Google Authenticator). Konfiguriert wird das unter <em>Stores &gt; Configuration &gt; Security &gt; 2FA</em>, wo sich einzelne Anbieter aktivieren oder deaktivieren lassen. Praxis-Tipp: In produktiven Umgebungen sollte 2FA grundsätzlich nicht deaktiviert werden, auch wenn das während der Entwicklung verlockend ist — es ist eine der wirksamsten Maßnahmen gegen kompromittierte Admin-Zugänge.</p> <h3>Konto-Sperre nach Fehlversuchen</h3> <p>Unter <em>Stores &gt; Configuration &gt; Advanced &gt; Admin &gt; Security</em> legen Sie mit dem Feld <strong>Maximum Login Failures to Lockout Account</strong> fest, nach wie vielen falschen Passworteingaben ein Benutzerkonto automatisch gesperrt wird, und mit <strong>Lockout Time (minutes)</strong>, wie lange die Sperre andauert. Ist ein Konto gesperrt, erscheint auf der Bearbeitungsseite des Benutzers unter <em>System &gt; Permissions &gt; All Users</em> ein Hinweis sowie ein <strong>Unlock</strong>-Button, mit dem ein anderer Administrator die Sperre vorzeitig aufheben kann.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/security10kategorie.png}}" alt="security" /> <h3>Sitzungsdauer und Passwort-Ablauf</h3> <p>Ebenfalls unter <em>Stores &gt; Configuration &gt; Advanced &gt; Admin &gt; Security</em> steuert <strong>Admin Session Lifetime (seconds)</strong>, nach welcher Inaktivität ein Backend-Benutzer automatisch ausgeloggt wird, und <strong>Password Lifetime (days)</strong> erzwingt nach Ablauf der angegebenen Tage eine Passwortänderung beim nächsten Login. Für Konten mit weitreichenden Rechten (z. B. Administratoren-Rolle) empfiehlt es sich, diese Werte deutlich strenger zu setzen als für reine Redakteurs- oder Support-Zugänge.</p> <h3>Eigenes Profil verwalten</h3> <p>Jeder eingeloggte Backend-Benutzer kann unabhängig von seiner Rolle über <em>System &gt; My Account</em> die eigenen Stammdaten pflegen — Benutzername, E-Mail, Passwort sowie die bevorzugte Oberflächensprache (<strong>Interface Locale</strong>). Änderungen erfordern auch hier zur Bestätigung das aktuelle eigene Passwort. Statt ein nicht mehr benötigtes Konto zu löschen, kann es unter <em>All Users</em> über das Feld <strong>This account is</strong> einfach auf <strong>Inactive</strong> gesetzt werden — die Historie (z. B. "zuletzt geändert von") bleibt dadurch nachvollziehbar erhalten.</p></div>