Suggest a feature
Suggest a feature
What would make raidboxes® more useful to you?
2
Mindestens eine Staging-Domain sollte fix sein
Improvement
Declined
14.01.2026
Früher gab es eine Staging-Funktion, die man an- und ausschalten konnte und - wenn aktiviert - die Domain der Live-Seite teilte. Davon ging raidboxes irgendwann weg und stellte eine eigene, fixe Subdomain für das Staging-Feature zur Verfügung. Nun mit der neuesten Staging-Variante ändert sich das erneut. Jetzt bekommt jede neue Staging einen Suffix zugeteilt (z.B. "-a" oder "-b"). Damit ist es nicht mehr möglich, die Staging-URL einmal als Browser-Lesezeichen zu speichern und dann langfristig damit zu arbeiten. Zudem: Einige kostenpflichtige Plugins erfordern eine Domainregistrierung, um Updates auf der Staging zu erhalten. Bitte sorgt dafür, dass es mindestens eine feste Staging-Subdomain gibt, die man nutzen kann, damit man die Plugin-Lizenzen für für Wartungszwecke lediglich einmal freischalten muss und jederzeit schnell auf die Staging via einmal angelegtem Lesezeichen zugreifen kann.
3 Comments
Jan
47 days, 23 hours ago
Status updated to 'Declined'
Reply
Jan
47 days, 23 hours ago
Guten Morgen aus Münster 👋
Wichtiger Hinweis, denn das technische Konzept von Staging hat sich entlang der Entwicklung des URL-Handlings, das du beschreibst, entwickelt. Zu Beginn hatten sich Live-Box und Staging noch dieselben Ressourcen geteilt. Die Staging Umgebung wurde damals über ein Cookie referenziert. Die URL war hier also fix. In Variante 2 haben wir diese Setup zugunsten dedizierter Ressourcen aufgegeben – daher auch die beiden individuellen URLs. In der neuesten Variante hat sich an diesem Grundsetup erst einmal nichts geändert, es ist aber eine weitere Beziehung dazugekommen: Die Parent-Child-Beziehung von Staging Umgebung zur ursprünglichen Box. Daher auch die -a, -b etc. Suffixe. Das aber nur als Kontext.
Die eigentlich Antwort auf die Frage: Die Änderung ist für den Fall des häufigen Aktivierens/Deaktivierens von Staging in jedem Fall relevant und ist als Anforderung mit aufgenommen. Ich gehe aber aktuell nicht davon aus, dass die Änderung kurz- oder mittelfristig umsetzbar ist – kläre das Ganze aber einmal mit unserem SRE Team.
Wichtiger Hinweis, denn das technische Konzept von Staging hat sich entlang der Entwicklung des URL-Handlings, das du beschreibst, entwickelt. Zu Beginn hatten sich Live-Box und Staging noch dieselben Ressourcen geteilt. Die Staging Umgebung wurde damals über ein Cookie referenziert. Die URL war hier also fix. In Variante 2 haben wir diese Setup zugunsten dedizierter Ressourcen aufgegeben – daher auch die beiden individuellen URLs. In der neuesten Variante hat sich an diesem Grundsetup erst einmal nichts geändert, es ist aber eine weitere Beziehung dazugekommen: Die Parent-Child-Beziehung von Staging Umgebung zur ursprünglichen Box. Daher auch die -a, -b etc. Suffixe. Das aber nur als Kontext.
Die eigentlich Antwort auf die Frage: Die Änderung ist für den Fall des häufigen Aktivierens/Deaktivierens von Staging in jedem Fall relevant und ist als Anforderung mit aufgenommen. Ich gehe aber aktuell nicht davon aus, dass die Änderung kurz- oder mittelfristig umsetzbar ist – kläre das Ganze aber einmal mit unserem SRE Team.
Reply
Amethyst
42 days, 14 hours ago
Das würde auch ein anderes Problem lösen: Derzeit muss man für jedes Staging die Konfigurationsdateien für Deployment-Pipelines und Automatisierungen anpassen. Wenn die erste Staging-Umgebung konstant eine Domain (z.B. parent-domain-a) auch über Löschungen und Neustarts hinweg halten würde, könnte man fixe Konfigurationen für die Staging-Umgebungen anlegen.
Alternativ würde auch dieses Feature das Problem lösen: https://forum.raidboxes.io/ideas/de/daten-aus-live-version-in-bestehende-staging-version-ubernehmen. Allerdings werden dann Staging-Umgebungen vermutlich nicht mehr gelöscht :)
Alternativ würde auch dieses Feature das Problem lösen: https://forum.raidboxes.io/ideas/de/daten-aus-live-version-in-bestehende-staging-version-ubernehmen. Allerdings werden dann Staging-Umgebungen vermutlich nicht mehr gelöscht :)
Reply
Jan
16 days, 17 hours ago
Jawoll, der Anwendungsfall macht so auf jeden Fall Sinn.
Wichtige Frage in dem Zusammenhang: Ist ein Löschen der Staging-Umgebung mit dem neuen Setup überhaupt noch nötig? Denn die Domains lassen sich zwar nicht fixieren, aber Inhalte können jetzt von Live auf Staging gepusht werden.
Zumindest in einem Setup in dem eine zweite Staging Umgebung existiert oder aber nur eine Staging Umgebung benötigt wird, gäbe es so (in vielen Fällen) keinen Grund mehr dafür die Staging-Umgebung komplett zu löschen.
Natürlich wird es immer wieder zu Situationen kommen, in denen es nötig sein wird Staging komplett zu löschen. In diesen würde nur eine statische Staging URL helfen.
Wichtige Frage in dem Zusammenhang: Ist ein Löschen der Staging-Umgebung mit dem neuen Setup überhaupt noch nötig? Denn die Domains lassen sich zwar nicht fixieren, aber Inhalte können jetzt von Live auf Staging gepusht werden.
Zumindest in einem Setup in dem eine zweite Staging Umgebung existiert oder aber nur eine Staging Umgebung benötigt wird, gäbe es so (in vielen Fällen) keinen Grund mehr dafür die Staging-Umgebung komplett zu löschen.
Natürlich wird es immer wieder zu Situationen kommen, in denen es nötig sein wird Staging komplett zu löschen. In diesen würde nur eine statische Staging URL helfen.
Thanks for your feedback