Vor dem ersten funktionsfähigen Build ist die Versuchung groß, bereits jede denkbare Komfortfunktion einzuplanen. Für einen stabilen Download Manager wäre das der falsche Weg. Entscheidend ist zunächst eine durchgängige Kette, die sich testen und nachvollziehen lässt.
Die erste Entwicklungsstufe des CROPS Plugins Donate Download Managers wurde deshalb auf wenige tragende Module reduziert. Sie bilden gemeinsam den Weg von der bestätigten Zahlung bis zur ausgelieferten Plugin-Datei.
Produktverwaltung als gemeinsame Grundlage
Das System muss wissen, welche CROPS-Plugins angeboten werden. Ein Produkt benötigt einen Namen, einen eindeutigen Slug, den Bezug zur Zahlung und mindestens ein freigegebenes Release.
Ohne diese Zuordnung könnte ein Webhook zwar eine Zahlung erkennen, aber keinen passenden Code und keine richtige Datei bestimmen.
Webhook-Modul für bestätigte Vorgänge
Der Webhook nimmt die serverseitige Zahlungsbestätigung entgegen. Er prüft die Nachricht und liest nur die Daten aus, die für den Downloadzugang erforderlich sind.
Das Modul darf keine Benutzeroberfläche ersetzen. Seine Aufgabe ist die verlässliche technische Verarbeitung, auch wenn der Nutzer die Danke-Seite nicht mehr öffnet.
Code-Generator mit eindeutiger Zuordnung
Nach erfolgreicher Prüfung erzeugt der Code-Generator einen individuellen Zugang. Der Datensatz verbindet Code, Produkt, Zahlung, Erstellungsdatum, Status und Regeln.
Eine klare Datenstruktur ist dabei wichtiger als ein auffälliges Codeformat. Intern muss jederzeit erkennbar sein, warum ein Code existiert und wozu er berechtigt.
Downloadformular für das Frontend
Der Nutzer benötigt ein einfaches Formular, das sich per Shortcode in eine WordPress-Seite einfügen lässt. Dort wird der Code geprüft und anschließend das passende Release angezeigt.
Die Shortcode-Lösung hält die Seitengestaltung flexibel. Betreiber können den Downloadbereich in eine bestehende CROPS-Seite integrieren, ohne ein festes Theme-Template zu verwenden.
Mailversand über die WordPress-Infrastruktur
Nach der Code-Erzeugung soll eine Bestätigung versendet werden. Das Plugin nutzt dafür die zentrale WordPress-Funktion wp_mail(). Eine eigene SMTP-Verwaltung gehört nicht zum Umfang.
Diese Entscheidung vermeidet doppelte Zugangsdaten und lässt den Betreiber seine vorhandene Mailkonfiguration weiterverwenden.
Danke-Seite als unmittelbare Rückmeldung
Neben der E-Mail wird ein eigener Shortcode für die Danke-Seite benötigt. Er zeigt den erzeugten Code im richtigen Zahlungskontext an, sofern der Vorgang bereits verarbeitet wurde.
Falls die Webhook-Verarbeitung wenige Sekunden benötigt, sollte die Seite eine verständliche Zwischenmeldung statt eines leeren Bereichs zeigen.
Codeverwaltung und Download-Logs
Administratoren müssen Codes suchen, prüfen und bei Bedarf sperren können. Eine einfache Liste mit Filtern ist dafür hilfreicher als verstreute Einzelansichten.
Das Downloadprotokoll ergänzt diese Verwaltung. Es zeigt, welcher Code welche Version wann abgerufen hat und ob der Vorgang erfolgreich war.
Erst der Kern, dann der Komfort
Funktionen wie mehrere Laufzeiten, Code-Wiederherstellung oder ein umfangreicher Release-Verlauf sind wichtige Ausbaustufen. Sie sollten jedoch auf einer getesteten Kernlogik aufsetzen.
Die erste Entwicklungsstufe verfolgt deshalb ein klares Ziel: Ein bestätigter Zahlungsvorgang führt genau einmal zu einem gültigen Code, und dieser Code liefert ausschließlich das zugeordnete Produkt aus.
Datenbanktabellen mit klarer Verantwortung
Für Codes und Downloadvorgänge sind getrennte Tabellen sinnvoll. Die Code-Tabelle hält die langfristige Berechtigung fest, während die Log-Tabelle einzelne Abrufe dokumentiert. Dadurch wird ein Code-Datensatz nicht mit immer mehr Ereignisfeldern überladen.
Die geplanten Tabellen wp_cddm_codes und wp_cddm_download_logs spiegeln diese Aufteilung wider. Sie schaffen eine belastbare Grundlage für Filter, Kontingentberechnung und spätere Auswertungen.
Technische Namen bleiben hinter der Oberfläche
Der REST-Endpunkt /wp-json/cddm/v1/stripe-webhook und die Shortcodes [crops_download_form] sowie [crops_thankyou_code] sind wichtige Integrationspunkte. Für normale Nutzer müssen diese Bezeichnungen jedoch nicht sichtbar sein.
Administratoren erhalten klare Anleitungen, wo der Webhook eingetragen und welcher Shortcode auf welcher Seite verwendet wird. Im Frontend erscheinen stattdessen verständliche Formulare und Statusmeldungen.
Testfälle vor dem ersten echten Einsatz
Die Kernkette sollte mit mehreren Szenarien geprüft werden: erfolgreiche Zahlung, doppelt zugestellter Webhook, unbekanntes Produkt, ungültiger Code, gesperrter Code, ausgeschöpftes Kontingent und fehlende Release-Datei. Erst diese Kombination zeigt, ob die Module sauber zusammenspielen.
Ein Systemtest im Adminbereich kann später zentrale Voraussetzungen sichtbar machen. Er ersetzt keine vollständige Prüfung, hilft aber dabei, Konfigurationsfehler vor dem ersten echten Download zu erkennen.
Konfiguration und Betrieb voneinander trennen
Die Einrichtungsansicht enthält Webhook-Daten, Seitenzuordnung und grundlegende Produktparameter. Der tägliche Betrieb konzentriert sich dagegen auf Codes, Releases und Logs. Werden beide Bereiche vermischt, steigt das Risiko, dass eine Routineaufgabe versehentlich zentrale Einstellungen verändert.
Eine klare Navigation unterstützt deshalb unterschiedliche Arbeitsphasen: zuerst konfigurieren und testen, danach überwiegend verwalten.
Fehlende Voraussetzungen sichtbar machen
Vor dem produktiven Einsatz muss der Download Manager erkennen können, ob eine Danke-Seite und ein Downloadformular eingerichtet sind, ob mindestens ein Produkt aktiv ist und ob eine Release-Datei hinterlegt wurde. Solche Hinweise sollten konkrete nächste Schritte nennen.
Ein roter Status ohne Erklärung hilft wenig. Besser ist eine verständliche Meldung, die beschreibt, welches Feld oder welche Seite noch fehlt und was nach der Korrektur geprüft werden kann.
Eine belastbare Basis für die nächsten Schritte
Sind diese Kernbausteine klar getrennt und gemeinsam getestet, können weitere Module ergänzt werden, ohne den Zahlungs- und Downloadweg neu aufzubauen. Genau diese Stabilität ist das eigentliche Ziel der ersten Entwicklungsstufe.
