Anfang Juli hatte der CROPS Plugins Donate Download Manager die reine Konzept- und Prototypphase verlassen. Der dokumentierte Stand 1.0.34-rc24 konzentrierte sich nicht mehr auf ständig neue Grundideen, sondern auf Bereinigung, Konsistenz und die Vorbereitung einer belastbaren Verkaufsversion.
Eine Release-Candidate-Phase ist dabei mehr als eine höhere Versionsnummer. Sie prüft, ob Funktionen, Benutzeroberfläche, Dokumentation und Paketstruktur als Ganzes zusammenpassen. Gerade bei einem Download- und Zugangssystem müssen technische Details und sichtbare Texte dieselben Regeln vermitteln.
Funktionsumfang stabilisieren statt ausweiten
In einer frühen Entwicklungsphase darf sich die Architektur noch verändern. Im Release Candidate sollten dagegen nur Funktionen enthalten sein, die tatsächlich geprüft und verständlich bedienbar sind. Unfertige Platzhalter oder funktionslose Menüpunkte schwächen den Gesamteindruck.
Der Schwerpunkt lag deshalb auf dem vorhandenen Kern: Produkte und Releases verwalten, Stripe-Zahlungen verarbeiten, Codes erzeugen, E-Mails auslösen und Downloads kontrolliert bereitstellen.
Kundenorientierte Texte ohne interne Spuren
Dokumentation, Changelog, Admin-Hilfen und Paketdateien wurden auf externe Vergleichsnamen, interne Notizen und Entwicklungsreste geprüft. Solche Hinweise gehören nicht in eine veröffentlichte Version, weil sie Nutzer verwirren und keinen Beitrag zur Bedienung leisten.
Erhalten bleiben sollen nur Informationen, die für Installation, Konfiguration und Nutzung relevant sind. Technische Namen werden dort erklärt, wo Administratoren sie wirklich benötigen.
Premium-Design als Teil der Bedienbarkeit
Eine hochwertige Oberfläche besteht nicht nur aus Farben und Karten. Sie muss Informationshierarchie schaffen. Wichtige Statuswerte gehören in gut erkennbare Bereiche, während selten benötigte technische Details in Hilfen oder Detailansichten wandern.
Tabellen, Formulare und Schaltflächen wurden deshalb auf Lesbarkeit und konsistente Abstände ausgerichtet. Das Ziel ist eine professionelle, aber nicht überladene WordPress-Administration.
Hilfetexte an den entscheidenden Stellen
Webhook-URL, Produktzuordnung, Release-Datei und Shortcodes sind für Einsteiger nicht selbsterklärend. Kurze Hilfetexte sollen direkt beim jeweiligen Feld erklären, was eingetragen wird und was beim Speichern oder Testen passiert.
Solche Hinweise reduzieren Fehlkonfigurationen stärker als eine lange allgemeine Anleitung, die erst gesucht werden muss. Die ausführliche Dokumentation bleibt dennoch als Ergänzung verfügbar.
Paketstruktur und Versionsangaben abgleichen
Die Plugin-Hauptdatei, interne Konstanten, Readme und ZIP-Dateiname müssen dieselbe Version ausweisen. Abweichungen führen dazu, dass WordPress oder Administratoren einen falschen Stand anzeigen.
Vor dem Release wird deshalb nicht nur der PHP-Code geprüft. Auch Ordnerstruktur, Dateinamen und Metadaten gehören zur Qualitätskontrolle.
Keine fremden Abhängigkeiten in der öffentlichen Darstellung
Der Download Manager ist als eigenständiges CROPS-Produkt positioniert. Frühere Vergleichs- oder Referenznamen haben in der öffentlichen Dokumentation keinen Platz. Die Funktionen werden neutral und anhand des tatsächlichen Nutzens beschrieben.
Diese Bereinigung betrifft nicht die notwendige Stripe-Anbindung oder WordPress-Schnittstellen. Sie entfernt lediglich Hinweise, die keinen funktionalen Zweck erfüllen.
Sicherheit und Berechtigungen erneut prüfen
Vor einer Veröffentlichung müssen alle Adminaktionen auf Capability, Nonce und Datenbereinigung geprüft werden. Besonders sensibel sind Produktdateien, Webhook-Secrets, Code-Sperren und Exporte.
Maskierte Zugangsdaten, geschützte Logs und verständliche öffentliche Fehlermeldungen gehören deshalb ebenso zur Release-Prüfung wie der erfolgreiche Download.
Ein Release Candidate bleibt eine Prüfversion
Die Bezeichnung rc24 macht deutlich, dass der Stand nahe an einer Veröffentlichung liegt, aber weiterhin getestet wird. Sie ist keine Behauptung, dass keine Fehler mehr möglich sind.
Rückmeldungen aus realistischen Testabläufen helfen jetzt mehr als weitere Funktionsideen. Entscheidend sind Zahlungssimulation, Code-Ausgabe, Mailweg, verschiedene Statusfälle und Release-Downloads.
Der Schritt zur belastbaren Produktversion
Die RC-Phase schafft einen festen Prüfpunkt. Statt ständig wechselnder Teilstände wird ein klar benanntes Paket vollständig getestet. Korrekturen fließen kontrolliert in den nächsten Candidate ein.
Dadurch wird die Entwicklung nachvollziehbarer und das spätere Update für Nutzer sicherer. Der Download Manager nähert sich nicht durch Werbeaussagen, sondern durch überprüfbare Konsistenz seiner ersten stabilen Produktversion.
Prüfung der sichtbaren Nutzerwege
Zur RC-Qualität gehört ein vollständiger Durchgang aus Sicht eines neuen Nutzers. Zahlungsseite, Danke-Seite, Code-E-Mail, Downloadformular, Fehlermeldungen und Release-Informationen werden in derselben Reihenfolge geprüft, in der sie später tatsächlich auftreten.
Gerade Übergänge zeigen oft kleine Brüche: unterschiedliche Produktnamen, ein fehlender Link oder eine Version, die im Changelog anders bezeichnet ist. Solche Details werden vor der Veröffentlichung vereinheitlicht.
Upgrade-Tests schützen vorhandene Zugänge
Eine neue Plugin-Version darf bestehende Codes und Logs nicht verlieren. Deshalb gehört neben der Neuinstallation auch die Aktualisierung über einen früheren Stand zum Testplan. Datenbankänderungen müssen vorhandene Datensätze erhalten und nur notwendige Felder ergänzen.
Der Download Manager verwaltet langfristige Berechtigungen. Ein Updatefehler wäre daher schwerwiegender als eine rein optische Abweichung.
Hilfedateien und Changelog ohne Entwicklersprache
Öffentliche Texte sollen erklären, was sich für Betreiber oder Nutzer geändert hat. Interne Dateinamen, provisorische Notizen und technische Diskussionen werden entfernt. Der Changelog bleibt sachlich und beschreibt nur tatsächlich enthaltene Änderungen.
Diese redaktionelle Bereinigung ist Teil der Produktqualität. Sie sorgt dafür, dass die Veröffentlichung wie ein gepflegtes Werkzeug wirkt und nicht wie ein offener Entwicklungsordner.
Ein definierter Abschluss für jeden Candidate
Jeder Candidate endet mit einer dokumentierten Prüfung von Syntax, Paketstruktur, Datenbankupdate, Mailweg und Download. Erst danach wird entschieden, ob ein weiterer Korrekturstand nötig ist oder die stabile Ausgabe vorbereitet werden kann.
