BrandiCore kann eine eingebettete MariaDB pro Sub-Plugin bereitstellen. Das Plugin erhält über die BrandiSql-API SQL-Funktionen, ohne Datenbank-Credentials oder Port selbst zu besitzen. Die Datenbank startet optional erst nach erfolgreichem Manager-Onboarding.

Was du vor dem Start prüfen solltest

Isolierte Plugin-Datenbanken für Betriebspersonal einordnen. Prüfe dabei zuerst den aktiven Server, deine Rolle und den tatsächlichen Ausgangszustand. Gerade bei Besitz, Geld oder Inventar kann ein Schritt Auswirkungen haben, die sich nicht durch erneutes Klicken rückgängig machen lassen. Arbeite an einer kleinen Testmenge oder einer Testfläche, wenn die Funktion neu für dich ist.

Schritt für Schritt

1. Schritt 1: Bei einem Datenproblem zuerst den betroffenen Pluginbereich bestimmen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
2. Schritt 2: Prüfen, ob der Core vollständig freigegeben und bereit ist. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
3. Schritt 3: Manager- und Pluginstatus vergleichen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
4. Schritt 4: Keine Datenbankdateien während laufendem Betrieb manuell ändern. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
5. Schritt 5: Eine kleine Lese- oder Testaktion über die freigegebene API durchführen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
6. Schritt 6: Erst mit sauberem Befund Backup oder Reparatur planen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.

Details und typische Anwendung

Plugin-Daten sind voneinander isoliert. Ein Shopfehler sollte daher nicht mit einer pauschalen Änderung an Bank- oder Landdaten beantwortet werden. SQL-Transaktionen und Constraints sind möglich, aber nur durch die dafür vorgesehenen Dienste. Ein Manager-only Gateway erlaubt Wartung, ohne Credentials an Browser oder Sub-Plugins zu verteilen.

Ein vollständiger Test hat drei sichtbare Zustände: den Anfang, die Aktion und das Ergebnis. Vergleiche die Anzeige nach dem Vorgang mit dem Anfang. Eine Chatmeldung allein reicht bei Geld, Rechten oder Lagerbeständen nicht immer aus; die zugehörige Übersicht sollte denselben Zustand zeigen. Bei gemeinsam genutzten Projekten hilft es, Änderungen mit Zeitpunkt und zuständiger Person kurz festzuhalten.

Fehlersuche

Bei Startfehler die Reihenfolge Onboarding, Freigabe, Datenbankstart prüfen. Bei einer einzelnen fehlenden Tabelle keine Live-Daten ohne Backup bearbeiten. Für Support nur Status und Fehlertyp teilen, keine Verbindungszeichenfolgen.

Ändere bei der Fehlersuche nur eine Sache pro Versuch. Prüfe zunächst die Eingabe, dann Berechtigung und Gebiet, anschließend den Serverzustand. Wenn eine Zahlung oder Buchung möglicherweise ausgeführt wurde, löse sie nicht erneut aus, bevor die Historie geklärt ist. Ein reproduzierbarer Fehler mit genauer Meldung ist für den Support viel hilfreicher als viele unklare Wiederholungen.

Abschlusskontrolle und Support

• Stimmt die angezeigte Objekt-ID, Position oder der Empfänger?
• Hat sich nur der erwartete Wert beziehungsweise Bestand geändert?
• Ist die Funktion für andere Beteiligte so sichtbar, wie beabsichtigt?
• Kannst du den Vorgang mit einem kleinen Beispiel erneut nachvollziehen?

Für eine Meldung gehören Server, Welt oder Panel-Seite, Uhrzeit, ausgeführter Befehl beziehungsweise Klickfolge, erwartetes Ergebnis und sichtbare Fehlermeldung zusammen. Bilder bitte auf den relevanten Ausschnitt beschränken. Zugangsdaten, Tokens und vollständige Zahlungsdaten niemals beilegen.