BrandiCore stellt internen Plugins Konfigurations- und Sicherheits-APIs bereit. Laut Architektur sollen Sub-Plugins keine eigenen Datenbank-Zugangsdaten oder offenen Ports verwalten. Konfiguration und Berechtigungen werden über definierte Schnittstellen und den Manager kontrolliert.

Was du vor dem Start prüfen solltest

Warum abhängige Plugins Einstellungen nicht direkt besitzen. 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: Die betroffene Pluginfunktion und den Server bestimmen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
2. Schritt 2: Die aktuell angezeigte Einstellung im Manager lesen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
3. Schritt 3: Rolle und benötigte Berechtigung prüfen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
4. Schritt 4: Eine kleine, reversible Änderung über die vorgesehene Oberfläche ausführen. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
5. Schritt 5: Den Effekt im Spiel kontrollieren. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.
6. Schritt 6: Bei Abweichung Zeitpunkt, alten und neuen Wert dokumentieren. Lies die Bestätigung vollständig und notiere eine Kennung, falls die Oberfläche eine anzeigt.

Details und typische Anwendung

Eine lokale Dateiänderung an einem Sub-Plugin kann vom zentralen Zustand abweichen oder beim nächsten Abgleich überschrieben werden. Änderungen sollten eine klare Quelle haben. Für öffentliche Hilfe sind die Bedienung und die Sichtbarkeit wichtig; interne API-Schlüssel und Datenbankdetails gehören in die Betriebsdokumentation. Prüfe beim Rechtewechsel nicht nur den sichtbaren Button, sondern die tatsächliche Aktion.

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 fehlender Schaltfläche Projekt und Rolle prüfen. Bei angezeigter, aber verweigerter Aktion den exakten Permission-Hinweis notieren. Bei verzögerter Übernahme auf den nächsten Abgleich warten und nicht parallel mehrere Werte setzen.

Ä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.