System

<div class="prose prose-hyva max-w-none"><p>When and why you need to clear the Magento cache, and which cache types exist.</p><p>For performance reasons Magento caches a great deal — from layout structures to configuration values to entire rendered HTML pages. This is managed under <em>System &gt; Cache Management</em>.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/cache10kategorie.png}}" alt="cache" /> <h3>The most important cache types</h3> <ul> <li><strong>Configuration:</strong> every setting from Stores &gt; Configuration.</li> <li><strong>Layout:</strong> merged layout XML structures.</li> <li><strong>Block HTML output:</strong> rendered block fragments.</li> <li><strong>Full Page Cache:</strong> complete, fully rendered pages — the most impactful cache, but also the one you'll clear most often.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/configuration10kategorie.png}}" alt="configuration" /> <h3>When to clear it</h3> <p>After changes to configuration, design, CMS content or theme files, the cache is often not automatically up to date. Use <strong>Flush Magento Cache</strong> to clear every type at once; the checkboxes next to each type let you target individual ones. If a type's status shows "Invalidated" (instead of "Enabled"), Magento has already detected it's stale — a click on <strong>Flush Magento Cache</strong> is then enough. In production, don't manually delete the entire <code>var/cache</code> folder — always use the backend function or <code>bin/magento cache:flush</code> instead.</p> <h3>Additional cache types at a glance</h3> <p>Beyond the main types mentioned above, <em>System &gt; Cache Management</em> lists further, less frequently noticed cache types: <strong>Compiled Config</strong> (the merged dependency-injection structure built from DI configuration), <strong>DB DDL operations</strong> (table structures Magento queries at runtime), <strong>Web Services</strong> (metadata for the REST/GraphQL APIs), <strong>Translations</strong> (translation values from i18n CSV files and backend translations), and <strong>Collections Data</strong> and <strong>Reflection Data</strong> (internal PHP reflection information used for performance optimizations). In everyday operation you'll practically never need to clear these manually — they become relevant almost exclusively after deployments or code changes.</p> <h3>Additional buttons under "Additional Cache Management"</h3> <p>Below the cache type table you'll find the <strong>Additional Cache Management</strong> section with two standalone buttons: <strong>Flush Catalog Images Cache</strong> deletes the product images that have been resized and cached on the filesystem — useful when old thumbnails still show up after replacing an image. <strong>Flush JavaScript/CSS Cache</strong> removes the merged and minified CSS/JS files from <code>pub/static</code>. Both buttons act independently of the main cache and are often the faster fix for theme or image problems than a full flush.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/additional10kategorie.png}}" alt="additional" /> <h3>cache:clean vs. cache:flush</h3> <p>On the command line, two similarly named but differently behaving commands exist: <code>bin/magento cache:clean</code> only removes the actual cache entries (by tag), leaving the cache infrastructure itself intact. <code>bin/magento cache:flush</code>, on the other hand, empties the entire underlying storage (e.g. the whole Redis DB segment) — which, on shared cache backends, can also affect other applications' data. Practical tip: for routine use, <code>cache:clean</code> is almost always sufficient; reserve <code>cache:flush</code> for "hard resets".</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/flush10kategorie.png}}" alt="flush" /> <h3>Cache backend and Full Page Cache mode</h3> <p>Whether Magento uses the built-in filesystem/Redis cache or Varnish for the Full Page Cache is not set within <em>System &gt; Cache Management</em> itself, but under <em>Stores &gt; Configuration &gt; Advanced &gt; System &gt; Full Page Cache</em> via the <strong>Caching Application</strong> field (Built-in Application or Varnish Caching). Which storage backend (filesystem, Redis) is used for the individual cache types, however, isn't a backend setting at all — it's configured in the <code>app/etc/env.php</code> file under the <code>cache</code> key and requires a deploy rather than an admin login.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/fullpage10kategorie.png}}" alt="fullpage" /> </div> </div>

<div class="prose prose-hyva max-w-none"><p>What indexers do in the background, why prices or stock sometimes appear delayed, and how to reindex.</p><p>Magento stores product data normalized across many tables. To keep storefront display fast despite that, this data is regularly transformed into pre-calculated, lean "index" tables — this job is done by the indexers, managed under <em>System &gt; Index Management</em> or via <code>bin/magento indexer:status</code>.</p> <h3>The most important indexers</h3> <img loading="lazy"src="{{media url=wysiwyg/handbuch/1kapitel/index10kategorie.png}}" alt="index" /> <ul> <li><strong>Product Price:</strong> pre-calculates final prices including price rules, taxes and customer groups.</li> <li><strong>Catalog Search:</strong> builds the search index (on this project: OpenSearch).</li> <li><strong>Category Products / Product Categories:</strong> the mapping between products and categories.</li> <li><strong>Stock:</strong> stock per product and source.</li> </ul> <h3>Update modes</h3> <p>Every indexer runs in either <strong>Update on Save</strong> mode (instantly on every change — fine for small catalogs) or <strong>Update by Schedule</strong> mode (via a background cron job — needed for larger catalogs, since otherwise saving a product in the backend would become noticeably slow). If a price or stock change isn't showing up in the store, an indexer is usually the culprit: check the status under <em>System &gt; Index Management</em>, run <code>bin/magento indexer:reindex</code> if needed, or verify the cron job is actually running.</p> <h3>Additional indexers at a glance</h3> <p>Beyond the ones already mentioned, there is, among others, the <strong>Product EAV</strong> indexer (builds flat, attribute-based tables for fast product queries), <strong>Customer Grid</strong> (feeds the backend customer grid with a fast, denormalized data source), and <strong>Design Config Grid</strong> (indexes per-store-view custom theme assignments). These indexers also appear in the table under <em>System &gt; Index Management</em> and can be monitored and controlled there just like the commonly cited core indexers.</p> <h3>Reading the status columns correctly</h3> <p>The table under <em>System &gt; Index Management</em> shows two separate pieces of information for each indexer: the <strong>Status</strong> column (Ready / Reindex Required / Processing) indicates whether the index is currently consistent, while <strong>Update Required</strong> (for "Update by Schedule" indexers) additionally shows whether pending changes are still waiting for the next cron run. If an indexer permanently sits at "Reindex Required" even though the cron job is running, that usually points to an error during the last indexing run — it's worth checking <code>bin/log system.log</code> or <code>exception.log</code> in that case.</p> <img loading="lazy"src=" src="{{media url=wysiwyg/handbuch/1kapitel/update10kategorie.png}}" alt="update" /> <h3>Switching modes directly in the backend</h3> <p>Switching between <strong>Update on Save</strong> and <strong>Update by Schedule</strong> doesn't have to go through the command line: in the table under <em>System &gt; Index Management</em>, you can select one or several indexers via checkbox and switch them to the other mode directly using the <strong>Actions</strong> dropdown — handy when a shop operator without SSH access needs to react quickly.</p> <h3>Targeted reindexing and resetting</h3> <p>Instead of always rebuilding every indexer at once, <code>bin/magento indexer:reindex &lt;indexer_id&gt;</code> lets you refresh a single indexer specifically (the available IDs are listed by <code>bin/magento indexer:info</code>). The <code>bin/magento indexer:reset</code> command explicitly marks an indexer as "invalid" without recalculating it — useful for forcing a clean starting state before a planned, full rebuild (e.g. after a large data import).</p></div>

<div class="prose prose-hyva max-w-none"><p>The generic import/export function for products, customers and other data types in the backend.</p><p>The generic import/export tool under <em>System &gt; Data Transfer</em> isn't just for products (see the "Product Import and Export" chapter) — it works for several entity types:</p> <ul> <li><strong>Products</strong>, <strong>Advanced Pricing</strong>: product data, or pure price/special-price updates.</li> <li><strong>Customers Main File</strong>, <strong>Customer Addresses</strong>: customer master data and addresses.</li> </ul> <h3>Recommended workflow</h3> <ol> <li>Always start with an export of the affected data type under <em>System &gt; Export</em> — it gives you the exact column structure as a template.</li> <li>Make changes to the CSV file outside of Magento (e.g. in a spreadsheet), without altering the column holding the unique key (e.g. <code>sku</code> for products, <code>email</code> for customers) if you intend to update existing records.</li> <li>Under <em>System &gt; Import</em>, choose the entity type and import behavior, and first only validate with <strong>Check Data</strong>.</li> <li>Only run the actual import with <strong>Import</strong> once the validation comes back error-free.</li> </ol> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/export10kategorie.png}}" alt="export" /> <p>For very large files (tens of thousands of rows), importing via the web UI can run into time limits — in those cases, a server-side import via the <code>bin/magento</code> command line, or a custom-built data patch (like the one behind this very manual), is the more robust option.</p> <h3>Understanding Import Behavior</h3> <p>On the import page, the <strong>Import Behavior</strong> field determines how the file interacts with existing data: <strong>Add/Update</strong> creates new records and updates existing ones based on the key value (e.g. <code>sku</code>), without clearing fields that aren't mentioned. <strong>Replace</strong> replaces entire records — fields missing from the CSV file get reset to their default value, which can quickly cause data loss with incomplete exports. <strong>Delete</strong> deletes solely based on the specified key column; all other columns are ignored. Practical tip: for ongoing price or stock maintenance, <strong>Add/Update</strong> is almost always the right choice.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/importbehavior10kategorie.png}}" alt="behavior" /> <h3>Controlling error handling during import</h3> <p>The <strong>Validation Strategy</strong> field determines how Magento reacts to faulty rows: <strong>Stop on Error</strong> aborts validation on the first error, while <strong>Skip error entries</strong> skips faulty rows and imports the rest anyway. The adjacent <strong>Allowed Errors Count</strong> field defines, for "Skip error entries", how many faulty rows are tolerated in total before the entire import is aborted after all — for very large files with known outliers, it's worth deliberately raising this value instead of leaving it at 0.</p> <h3>Including product images with an import</h3> <p>If a product import should also set new images, the CSV file alone isn't enough: the image files also need to sit in a directory under <code>pub/media/import</code> (default name e.g. <code>product_images</code>), and the relative path is specified via the <strong>Images File Directory</strong> field on the import page. In CSV columns like <code>base_image</code> or <code>additional_images</code>, only the file name itself is then needed. Alternatively, you can upload a ZIP file containing both the CSV and the image folder together.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/file10kategorie.png}}" alt="file" /> <h3>Import History – tracing past imports</h3> <p>Under <em>System &gt; Import History</em>, Magento logs every import that was run, with a timestamp, the executing user, entity type, and import behavior. The <strong>Import Log</strong> link in each row lets you download the full log, including every reported error and warning, as a file — useful when you later need to figure out which import caused certain product changes. Magento doesn't offer an automatic way to undo an import, though; if in doubt, the only options are re-importing with corrected data or restoring from a database backup.</p></div>

<div class="prose prose-hyva max-w-none"><p>Create additional admin users and use roles to define exactly what they may do in the backend.</p><p>Manage backend users and their permissions under <em>System &gt; Permissions</em>, in two related sections:</p> <h3>User Roles</h3> <p>A role defines WHICH areas of the backend are accessible — under <em>Role Resources</em> you use a tree structure to select exactly the menu items that should be visible for this role (e.g. a "Support" role with access only to orders and customers, no access to system settings or payment data). Additionally, under <em>Role Resources &gt; Advanced</em> you can restrict which websites/stores the role applies to.</p> <h3>All Users</h3> <p>Here you create the actual user accounts (<strong>Add New User</strong>) and assign each one a previously defined role. A new user needs at minimum a username, email, password, and your own current password for confirmation.</p> <p><strong>Golden rule:</strong> never grant more rights than a given task actually needs — an employee who only handles orders doesn't need access to system configuration or payment settings. That significantly limits the potential damage if an account is ever compromised.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/newrole10kategorie.png}}" alt="new" /> <h3>Two-factor authentication (2FA)</h3> <p>Since Magento 2.4, the two-factor authentication module is enabled by default and requires every admin user to set up a second factor on first login, typically via an authenticator app (e.g. Google Authenticator). This is configured under <em>Stores &gt; Configuration &gt; Security &gt; 2FA</em>, where individual providers can be enabled or disabled. Practical tip: on production environments, 2FA generally should not be disabled, even though that can be tempting during development — it's one of the most effective safeguards against compromised admin accounts.</p> <h3>Account lockout after failed attempts</h3> <p>Under <em>Stores &gt; Configuration &gt; Advanced &gt; Admin &gt; Security</em>, the <strong>Maximum Login Failures to Lockout Account</strong> field determines after how many incorrect password attempts a user account is locked automatically, and <strong>Lockout Time (minutes)</strong> sets how long that lock lasts. When an account is locked, its edit page under <em>System &gt; Permissions &gt; All Users</em> shows a notice along with an <strong>Unlock</strong> button, letting another administrator lift the lock early.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/security10kategorie.png}}" alt="security" /> <h3>Session lifetime and password expiry</h3> <p>Also under <em>Stores &gt; Configuration &gt; Advanced &gt; Admin &gt; Security</em>, <strong>Admin Session Lifetime (seconds)</strong> controls after how much inactivity a backend user gets logged out automatically, and <strong>Password Lifetime (days)</strong> forces a password change on next login once the specified number of days has elapsed. For accounts with far-reaching rights (e.g. an Administrator role), it's advisable to set these values noticeably stricter than for pure editorial or support accounts.</p> <h3>Managing your own profile</h3> <p>Regardless of their role, every logged-in backend user can maintain their own account details via <em>System &gt; My Account</em> — username, email, password, and the preferred interface language (<strong>Interface Locale</strong>). Changes here also require the user's current password for confirmation. Instead of deleting an account that's no longer needed, it can simply be set to <strong>Inactive</strong> under <em>All Users</em> via the <strong>This account is</strong> field — that way the history (e.g. "last modified by") remains traceable.</p></div>