> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dreizack-medien.de/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Häufige Fragen zu DZM Reloadify

> [accordion] Meine Kunden bekommen zwei Bestätigungsmails für den Newsletter
>
> Meldet sich jemand im JTL-Formular an, verschickt JTL seine Mail „Newsletter-Anmeldebestätigung“. Hast du in Reloadify einen Double-Opt-in-Flow, schickt Reloadify zusätzlich eine eigene. Entscheide dich für einen Weg:
>
> * **Reloadify-Flow nutzen:** Im JTL-Backend die E-Mail-Vorlage „Newsletter-Anmeldebestätigung“ deaktivieren. Die Einstellung zum Double-Opt-in in JTL bleibt dabei unverändert.
> * **JTL-Bestätigung nutzen:** Den Double-Opt-in-Flow in Reloadify ausschalten.
>
> Bestätigt jemand über den JTL-Link, meldet das Plugin die Bestätigung an Reloadify. Bestätigt er bei Reloadify, schaltet das Plugin die Anmeldung in JTL im nächsten Takt frei, sofern unter Einstellungen die **Übernahme von Anmeldungen aus Reloadify** an ist.

> [accordion] Werden Bestelldatum und Anmeldedatum korrekt übertragen?
>
> Ja. `ordered_at` ist das Bestelldatum aus JTL, `subscribed_to_newsletter_at` das Datum der Newsletter-Anmeldung, nicht das Datum des Abgleichs. Reloadify übernimmt beide unverändert, auch wenn die Daten Wochen später übertragen werden. Bei Anmeldungen über das Reloadify-Popup gilt der Zeitpunkt, den Reloadify selbst gespeichert hat.

> [accordion] Die Übersicht zeigt „Mengenbremse“ – was muss ich tun?
>
> Die Mengenbremse hält große Mengen aus dem **Altbestand** an, also Daten, die älter als 30 Tage sind. Sie schützt vor einem versehentlichen Massenversand, etwa wenn ein Wawi-Abgleich alle Kunden als geändert markiert. Laufende Bestellungen, Warenkörbe und Profile gehen trotzdem weiter raus.
>
> Ist die Menge gewollt, zum Beispiel weil du den Stichtag zurückgesetzt hast, gibst du sie mit **„n freigeben“** frei. Ist sie nicht gewollt, lässt du sie stehen und klärst die Ursache. Details unter [Einstellungen](https://docs.dreizack-medien.de/Reloadify/einstellungen.md#mengenbremse).

> [accordion] Warum kommen nicht alle Warenkörbe bei Reloadify an?
>
> Das Plugin überträgt nur Warenkörbe **angemeldeter Kunden**: Bei einem Gast kennt der Shop keine E-Mail-Adresse. Ein Warenkorb gilt als abgebrochen, wenn er die eingestellte Zeit ohne neue Position liegt (Standard 15 Minuten), und geht nur raus, wenn seine letzte Position höchstens 27 Stunden alt ist.

> [accordion] Gelöschte Artikel tauchen in Reloadify noch auf
>
> Löschst du einen Artikel in JTL, setzt das Plugin ihn nach 60 Minuten bei Reloadify auf `visible: false`. Reloadify empfiehlt ihn dann nicht mehr. Die 60 Minuten Wartezeit gibt es, weil die Wawi Artikel beim Abgleich kurz löscht und neu anlegt. Gelöschte Varianten bekommen nach 24 Stunden den Bestand 0.

> [accordion] In den Läufen steht „Pause bis zur nächsten Minute“
>
> Das ist Normalbetrieb. Reloadify erlaubt 240 Anfragen je Minute, das Plugin hält davon 80 frei, damit Backend und Explorer weiter antworten. Ist das Kontingent der Minute aufgebraucht, macht der nächste Takt weiter. Orange wird es erst, wenn Reloadify selbst bremst.

> [accordion] Der JTL-Newsletter ist bei mir ausgeschaltet – funktionieren Anmeldungen trotzdem?
>
> Die Option „Newsletter aktivieren“ in JTL steuert nur, ob das Newsletter-System von JTL läuft. Das Anmeldeformular und die Abmeldung funktionieren trotzdem, und das Plugin überträgt An- und Abmeldungen wie gewohnt.

> [accordion] Kontolöschungen kommen bei Reloadify nicht an (JTL-Shop 5.8 mit MySQL)
>
> In JTL-Shop 5.8 scheitert das Löschen von Kunden auf MySQL-Datenbanken an einem Fehler im Shop selbst (MySQL-Fehler 1137 „Can't reopen table“). Der Kunde bleibt dann in JTL bestehen, und das Plugin hat nichts weiterzugeben. Shops auf MariaDB sind nicht betroffen. Das ist ein Fehler im JTL-Shop, nicht im Plugin.

> [accordion] Entstehen bei Reloadify doppelte Profile oder Bestellungen?
>
> Nein. Jede E-Mail-Adresse hat genau ein Profil, jede Bestellung ihre feste ID aus JTL. Ein erneutes Senden aktualisiert den vorhandenen Datensatz. Das gilt auch für Daten, die schon eine ältere Plugin-Version übertragen hat.

> [accordion] Wie oft sollte der Cron laufen?
>
> Alle 1–2 Minuten über einen Cron beim Hoster, der `/includes/cron_inc.php` aufruft. Jeder Aufruf ist ein Takt mit 20 Sekunden Budget. Kategorie-Zuordnungen gehen einzeln raus, nach einem großen Katalog laufen sie deshalb eine Weile nach.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.