unable to find class 'wcf\system\option\user\group\UserGroupOptionType'

  • Das Plugin liest das WSC Installations log aus und sucht dort alle foreign keys herraus und gleicht diese dann mit deiner Datenbank ab.

    Bedeutet dass jedes Plugin das eigene foreign keys anlegt auch aufgeliostet werden sollte.

    Und nein, aktuell gibts das Paket nur 3-4 mal in verschiedenen themen verstreut hier zum download^^

  • Dieses haben wir ebenfalls im Gebrauch seit längerer Zeit.

    Hier mal die Übersicht.



    Betriebssystem - Linux (Debian) // Burning Board® Version - 4.1.8
    PHP Version - 5.6.14-0+deb8u1 // MySQL-Version - 5.5.5-10.0.22-MariaDB-1~jessie-log
    Webserver - Hiawatha v10.0


    :!: www.miui-ger.de :!:

  • Ist das dein tatsächlicher Status ?

    Wenn ja: das schaut aber nicht gut aus, da fehlen ja gut 20% der Foreign Keys...

    Du solltest mal in der DB genau nachschauen ob die Keys tatsächlich fehlen oder es sich um einen Bug im Plugin handelt der eine fehlerhafte Anzeige erzeugt.

  • Ist das dein tatsächlicher Status ?

    Wenn ja: das schaut aber nicht gut aus, da fehlen ja gut 20% der Foreign Keys...

    Du solltest mal in der DB genau nachschauen ob die Keys tatsächlich fehlen oder es sich um einen Bug im Plugin handelt der eine fehlerhafte Anzeige erzeugt.

    Die keys fehlen wirklich, hab mit adminer nachgeschaut.

    Betriebssystem - Linux (Debian) // Burning Board® Version - 4.1.8
    PHP Version - 5.6.14-0+deb8u1 // MySQL-Version - 5.5.5-10.0.22-MariaDB-1~jessie-log
    Webserver - Hiawatha v10.0


    :!: www.miui-ger.de :!:

  • Naja, das erklärt dann auch wiso du so Probleme hast.

    Wenn z.B. ein user gelöscht wurde, auf der post Tabelle aber der Key fehlt dort die UserID auf Null zu setzen, dann hast du plötzlich bei jedem Aufruf einer Seite mit einem entsprechenden Post des Users eine Fehlermeldung.

    Bedeutet am Ende viel Handarbeit das manuell grade zu biegen, da du zuerst alle veralteten Daten bereinigen musst um anschließend den key neu anzulegen.

  • Ja, wobei ich nicht weiß wie gut der Importer überhaupt mit inkonsistenten Daten umgehen kann, hab ich ehrlich gesagt nie getestet^^

  • Ich hätte da mal eine technische Frage... das Plugin ist ja schön und gut. Aber es prüft nicht alle Fremdschlüssel einer WSC-Installation. Einfach weil nicht alle Fremdschlüssel in der Tabelle wcf1_package_installation_sql_log vermerkt sind. Es ist zwar ein guter Hinweis, ob ggf. einige Fremdschlüssel fehlen, aber es prüft eben nicht auf alle auf Vollständigkeit.


    Zumindest wenn ich die Ausgabe des SQLs aus dem Tool und beispielhaft ein paar SHOW CREATE TABLE vergleiche, dann sind da deutliche Lücken was die CONSTRAINTS angeht.

  • Daher wäre eine neue installation plus import wohl beste Lösung.

    Da die Anzahl der fehlenden FKs wohl überschaubar ist, kann man die auch händisch korrigieren. Selbst schon gemacht.

    'Einfach' bei den betroffenen Tabellen die FKs ergänzen. Gibt es fehlerhafte Einträge, was z.B. phpMyAdmin monieren wird, diese löschen und dann den FK setzen.


    Grundsätzlich bietet es sich an, ein Testsystem zu nutzen, bei dem sämtliche Anwendungen / Erweiterungen korrekt installiert sind. Dann die FKs des Testsystem mit dem Live-System vergleichen und im Letzteren ergänzen.

    Gruß, Udo

  • Zumindest wenn ich die Ausgabe des SQLs aus dem Tool und beispielhaft ein paar SHOW CREATE TABLE vergleiche, dann sind da deutliche Lücken was die CONSTRAINTS angeht.

    Ich lese nur das install log aus und dort sollten eigentlich alle vermerkt sein.

    Hast du konkrete Beispiele in welchen Tabellen es lücken gibt ?

  • Daher wäre eine neue installation plus import wohl beste Lösung.

    Nun.. das ist ja unser Problem bereits aus der Vergangenheit... der Fehler wurde bereits über verschiedene Instanzen mitgezogen. Wahrscheinlich seit WBB 4.x ! Wie schaut das eigentlich nun mit einem aktuellen Importer aus, im WBB 5 ist ja kein aktueller Importer hinterlegt von WBB 5.x zu WBB 5.x !?

    Betriebssystem - Linux (Debian) // Burning Board® Version - 4.1.8
    PHP Version - 5.6.14-0+deb8u1 // MySQL-Version - 5.5.5-10.0.22-MariaDB-1~jessie-log
    Webserver - Hiawatha v10.0


    :!: www.miui-ger.de :!:

  • Ich lese nur das install log aus und dort sollten eigentlich alle vermerkt sein.

    Hast du konkrete Beispiele in welchen Tabellen es lücken gibt ?


    Okay... Euer SQL liefert auf meinem Test-System 99 Treffer... also 99 vermeintliche Fremdschlüssel.


    Ich habe nun mittels eines Scripts das folgende gemacht:

    • ein SHOW TABLES ermittelt 190 Tabellen
    • die 190 Tabellennamen habe ich anschließend in einer Schleife durch ein SHOW CREATE TABLE <tablename>; gejagt
    • anschließend habe ich auf den Output ein grep CONSTRAINT | sort | uniq | wc -l gemacht, das ergab 224 Treffer

    Ergo... das Plugin prüft überhaupt nur auf 99 von 224 Fremdschlüsseln, wenn laut dem Plugin alles okay ist, dann weiß ich lediglich, dass ca. 44% der Fremdschlüssel da sind... damit sind 56% gar nicht geprüft worden!


    ich denke mit dem Vorgehen kannst Du selbst ermitteln, ich wollte jetzt hier keine 125 Beispiele nennen... aber schnell fündig wirst Du z.B. in der wcf1_user oder der wcf1_application ...


    P.S.: Leider musste ich "Euer SQL" entfernen, das gab einen Fehler von Cloudflare, wenn ich das posten wollte. Ich meine das SQL aus der PHP-Datei in Zeile 36-41, das habe ich manuell ausgeführt um die 99 Treffer zu erhalten.

    Edited once, last by Barungar: SQL Error beim Posten ().

  • Du hast Recht, leider werden die WSC eigenen während der Installation angelegten Keys nicht mit geloggt.

    Die kann ich aber manuell ins Plugin einpflegen, aber wenn du die reinen WSC-Tabellen mal außer Acht lässt, fehlt sonst etwas auf den ersten Blick ?

  • War auch mein erster Gedanke, dass es ausschließlich Fremdschlüssel des Core sind, die wären der initialen Installation eingerichtet werden, die in der SQL_LOG-Tabelle fehlen. Dann allerdings frage ich mich, wieso von der Tabelle wcf1_application einer der beiden Fremdschlüssel in der LOG-Tabelle steht und der andere nicht... ich hätte jetzt vermutet, dass die beide bei der Core-Installation angelegt werden. :/

  • Okay, die wcf1_package_installation_sql_log dokumentiert also somit sozusagen alle Änderungen an den Tabellen. Grundsätzlich gibt es nämlich alle 190 Tabellen meines Test-Systems auch in der wcf1_package_installation_sql_log. Es wird somit durch den Core selbst, die Anlage jeder Tabelle zumindest geloggt.


    Wenn mal also eine Zeile in der Tabelle findet mit packageID > 0, sqlTable <>"" und sqlColumn=="" sowie sqlIndex=="", dann hat man eine "unmodifizierte Standard-Tabelle" vor der Nase. Damit weiß man zwar noch nicht, welche Fremdschlüssel und Felder die enthalten soll, aber sie ist sozusagen im Orginalzustand.


    Folglich müsste man die Fremdschlüssel der "Standard-Tabellen" des Core vorher kennen, weil das wcf1_package_installation_sql_log eben nur das Delta benennt, sowohl was Tabellen, Felder als auch Indices/Fremdschlüssel angeht.

    Edited once, last by Barungar ().

  • Was genau das ist was ich umsetzen werde wenn ich am WE mal bissi Zeit habe.

    Die Indices kann man ja einfach aus der install.sql ziehen und muss dann nur bissi mit der Versionierung aufpassen (die ändern sich ja auch mal bei Versionssprüngen).