Ein intern genutztes Entwicklungswerkzeug enthält andere Ausgangsdaten als ein Produkt, das an weitere WordPress-Anbieter verkauft wird. Im internen CROPS-Einsatz sind konkrete Projekte, Slugs und teilweise bekannte Projektchat-Adressen sinnvoll. Eine neutrale Verkaufsversion darf diese Informationen dagegen nicht mitbringen. Der Bugtracker trennt deshalb Edition und Datenbestand klar voneinander.
Gemeinsamer Kern, unterschiedliche Ausgangslage
Beide Editionen verwenden denselben fachlichen Kern: strukturierte Bugreports, Produktzuordnung, Status, Prioritäten, Qualitätsbewertung, Anhänge, Historie, Dublettenprüfung, interne Notizen und Belohnungen. Auch die responsive Produktverwaltung und der kontrollierte Projektworkflow gehören zur gemeinsamen Grundlage.
Der Unterschied liegt nicht in einer künstlichen Beschränkung wichtiger Funktionen. Er betrifft die vorkonfigurierten Inhalte und die interne Arbeitsweise. Die Verkaufsversion soll unmittelbar für eigene Produkte nutzbar sein, ohne dass fremde Projektnamen entfernt werden müssen.
Die neutrale Version enthält keine internen Seed-Daten
Bei einer neuen Installation der Verkaufsversion wird keine Liste von CROPS-Plugins angelegt. Der Betreiber erstellt seine Produkte selbst. Dadurch bleiben Namen, Slugs und Projektverknüpfungen vollständig in seiner Verantwortung. Das Plugin wirkt neutral und eignet sich für Agenturen, Entwickler oder andere Anbieter.
Diese Entscheidung betrifft auch Updates. Eine spätere Version darf nicht plötzlich interne Produkte hinzufügen. Neutralität muss dauerhaft erhalten bleiben und darf nicht nur bei der Erstinstallation gelten.
Die interne Edition kennt die vorhandenen Projekte
Für den eigenen Einsatz kann eine definierte Projektliste hilfreich sein. Sie verkürzt die Einrichtung und sorgt für einheitliche Slugs. Dabei gilt jedoch eine wichtige Grenze: Es werden nur tatsächlich vorhandene Projekte aufgenommen. Projektchat-Adressen werden ausschließlich dort hinterlegt, wo eine verlässliche URL bekannt ist. Unbekannte Ziele bleiben leer.
Der Produktname orientiert sich am tatsächlichen Projektnamen und nicht an Datumsangaben oder Markierungen aus einer Projektübersicht. So entsteht eine saubere, verständliche Liste für den täglichen Einsatz.
Manuelle Änderungen haben Vorrang
Interne Produktnamen können im Laufe der Entwicklung angepasst werden. Ein Update darf solche Änderungen nicht wieder auf einen alten Standardwert zurücksetzen. Dasselbe gilt für Projektchat-Adressen, Einstellungen und andere gepflegte Daten.
Neue interne Ausgangsdaten dürfen nur ergänzend eingefügt werden, wenn ein Produkt noch nicht existiert. Bestehende Einträge bleiben erhalten. Dieses Prinzip schützt die Arbeit des Betreibers und verhindert, dass ein Release unbeabsichtigt die Zuordnung laufender Bugreports verändert.
Keine Vermischung bei Installation und Export
Die Trennung der Editionen betrifft auch Paketinhalte, Dokumentation und sichtbare Texte. Eine Verkaufsversion darf keine internen Projektnamen, Chatadressen oder Arbeitsnotizen enthalten. Umgekehrt darf die interne Edition ihre nützlichen Verknüpfungen behalten.
Für die Qualitätssicherung bedeutet das, beide Varianten getrennt zu prüfen. Eine Funktion kann technisch identisch sein und trotzdem unterschiedliche Datenrisiken besitzen. Besonders bei Produktlisten und Update-Routinen ist eine separate Kontrolle notwendig.
Einheitliche Bedienung erleichtert Wartung
Obwohl die Datenbestände getrennt sind, soll die Oberfläche gleich funktionieren. Produkte werden über denselben Editor angelegt und bearbeitet. Bugreports nutzen dieselben Felder und Statuswerte. Belohnungen folgen demselben manuellen Verfahren. Dadurch muss der Kern nicht doppelt entwickelt werden.
Änderungen an Bedienung, Sicherheit oder Performance können beiden Editionen zugutekommen. Nur dort, wo interne Projektdaten betroffen sind, greift eine editionsspezifische Logik.
Vertrauen durch saubere Produktgrenzen
Ein Käufer erwartet, dass ein installiertes Plugin keine fremden internen Daten mitbringt. Ein internes Team erwartet wiederum, dass seine gepflegten Verknüpfungen nicht bei jedem Update verschwinden. Die klare Trennung erfüllt beide Anforderungen.
Sie zeigt außerdem, dass White-Label-Fähigkeit nicht nur aus einem neutralen Logo besteht. Entscheidend sind Datenmodell, Startkonfiguration, Updateverhalten und Dokumentation.
Ein sinnvoller Schritt Richtung Veröffentlichung
Die neutrale Verkaufsversion wurde als eigener Release-Candidate-Zweig weiterentwickelt. Die interne Projektedition bleibt parallel bestehen. Damit kann der Bugtracker sowohl den konkreten CROPS-Workflow unterstützen als auch als eigenständiges WordPress-Produkt angeboten werden.
Diese Architektur schafft eine klare Grundlage für den weiteren Ausbau. Neue Funktionen können im gemeinsamen Kern entstehen, während interne Projektdaten und externe Installationen sauber getrennt bleiben. Für ein zuverlässiges Produkt ist diese Trennung ebenso wichtig wie die sichtbaren Bugtracking-Funktionen.
Zwei Pakete benötigen zwei klare Prüflisten
Vor einer Veröffentlichung sollte jede Edition mit einer eigenen Checkliste geprüft werden. Bei der neutralen Version steht im Mittelpunkt, dass keine internen Produkte, Projektadressen oder Arbeitsnotizen enthalten sind. Bei der internen Edition wird kontrolliert, ob die vorgesehenen Projekte vorhanden sind und bekannte Verknüpfungen stimmen. Beide Tests müssen außerdem Updates aus einer älteren Installation abbilden. So wird verhindert, dass eine Korrektur für die eine Variante unbemerkt Daten der anderen Variante beeinflusst. Die gemeinsame Codebasis bleibt ein Vorteil, solange editionsspezifische Ausgangsdaten konsequent getrennt und separat geprüft werden.
Auch Dateinamen, Paketmetadaten und sichtbare Hilfetexte gehören in diese Prüfung. Eine neutrale Oberfläche kann technisch korrekt sein und trotzdem interne Spuren enthalten, wenn nur die Datenbank betrachtet wird. Umgekehrt darf die interne Edition ihre projektspezifischen Hilfen behalten, solange sie nicht in das Verkaufspaket gelangen. Die saubere Trennung ist daher dauerhaft eine Aufgabe für Code, Daten und Auslieferung zugleich im Releaseprozess.
