Problem mit spamblock_bayes-Administration

[mitch]

Moin!

Mit dem Update auf Debian 12 kam PHP 8, was dazu führte, dass ich
einmal rundum meine s9y-Plugins aktualisieren musste. Die Updates
waren auch schon lange überfällig, was funktioniert das auch alles
einfach so stabil ohne Händchenhalten

Ich habe nach dem Update von serendipity_event_spamblock_bayes von
0.5.5 auf 1.1.5 jetzt ein Problem in der Admin-Oberfläche
festgestellt:

Wenn ich in der Admin-Oberfläche auf Aktivität -> Kommentare gehe,
werden mir die zu bewilligenden Kommentare angezeigt (momentan
haufenweise Trackback-Spam). Dort gibt es an jedem Kommentar
weiterhin die beiden Buttons Spamschutz (Bayes): Valid und
Spamschutz (Bayes): Spam, um den Bayes-Filter zu trainieren. Wenn
ich draufklicke, passiert aber nichts mehr…

Die Buttons haben als onClick-Event return spam(KOMMENTARID)
bzw. return ham(KOMMENTARID) hinterlegt. Die Browserkonsole zeigt
als Fehler, dass die Funktionen spam() und ham() nicht bekannt
sind. Das scheint auch zu stimmen - aber warum?

Ich habe etwas in den Code geguckt:

• Die beiden vermissten Funktionen werden in bayes_commentlist.js
  definiert.
• Die JS-Datei wird dann in serendipity_event_spamblock_bayes.php
  Zeile 299 gelesen und als Teil des HTMLs ausgegeben.

Letzteres passiert aber nicht, vermutlich weil $event nicht auf
'js_backend' steht. An der Stelle bin ich dann aber raus…


Kann jemand dieses Problem bei sich bestätigen oder nachvollziehen?
Oder gibt's Ideen, was man tun könnte?

Danke und Gruß
Christian

[onli]

Hm. Bei mir im Blog geht es. Aber im Dev-Blog ging es eben auch nicht, bis ich die /s9y_dev/index.php?/serendipity_admin.js&v=1687090081 aufgerufen und mit STRG+F5 nochmal neu geladen habe. Vorher war die leer, dann tauchte der Code auf, er scheint jetzt auch bestehen zu bleiben und die Buttons auf der Kommentarseite gehen.

Ich vermute: Ein Bug, der einmalig den Javascript-Code verschluckt, was danach gecached wird und daher durch ein Neuladen der Datei im Browser gelöst werden kann?

[mitch]

Einen Reload hatte ich schon versucht, der hatte nichts gebracht.

Nach Deinem Hinweis habe ich nochmal einen energischeren Reload versucht: "Disable Cache" in den Entwicklertoos vom Firefox
Jetzt tat sich was und die Browserkonsole bemängelte folgendes:

Code: Select all

Blocked loading mixed active content “http://.../index.php”
The resource from “https://.../serendipity_admin.js?v=1587322240” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

Dass kann ich beides in Ansätzen verstehen:

1. Das ganze Blog läuft über https://, die Admin-Ansicht will aber aus irgendeinem Grund die index.php über http:// einbinden. Moderner Browser sagt "so nicht".
2. serendipity_admin.js wird mit Mime-Type HTML ausgeliefert - das passt auch nicht.

Zum nosniff muss ich mich nochmal schlaulesen. Vielleicht habe ich da mit den X-Content-Type-Options etwas abgesichert und mit dem aktuellen PHP oder den aktuellen Plugins ist das nicht mehr ganz kompatibel.

Danke für den Stupps, ich bin einen Schritt weiter!
Christian

[mitch]

Also, ich bin schon mal nicht ganz unschuldig...
Meine .htaccess hat unter anderem Einträge drin, um den DirectoryIndex und das ErrorDocument auf die index.php umzubiegen. Nach dem Motto: wenn hier irgendjemand eine komische URL aufruft, dann kriegt er die Blog-Startseite zu sehen.

Da habe ich leider vor Jahren vergessen, die absoluten Ziel-URLs auf https:// umzustellen, als ich das gesamte Blog auf https:// umgestellt habe.

Ich habe dann testweise mal die Umleitung von Fehlern auf die index.php rausgenommen.
Jetzt ist a) der komische Aufruf der index.php auf der Adminseite verschwunden und b) sehe ich einen HTTP 404, der nicht mehr heimlich durch die Blog-Startseite ausgetauscht wird.

Ich verstehe noch nicht, wo der 404 herkommt. Muss ich den Cache irgendwie reinitialisieren, gibt es die serendipity_admin.js?v=1587322240 gar nicht?

Auf jeden Fall erklärt das den Mismatch des Content-Types: Der Server liefert die
serendipity_admin.js nicht aus, der Browser versucht dann wohl die lokal gecachte Seite und das ist die frühere index.php aus dem ErrorDocument und die hat tatsächlich den falschen MIME-Type, das war ja HTML und kein JavaScript.

Ich bin aktuell auf der Suche, warum die serendipity_admin.js nicht ausgeliefert wird.

Immerhin habe ich schon diese Stelle gefunden:
https://github.com/s9y/Serendipity/blob ... c.php#L157
und weiß damit, wo das "js_backend" herkommt, das in
https://github.com/s9y/additional_plugi ... s.php#L297
abgefragt wird.

Ein wenig Angst habe ich aber ob der beiden FIXFIX- und HOTFIX-Kommentare in der Routing-Funktion schon

Bin gespannt, ob ich das noch gelöst kriege.

[mitch]

Aua, alles selbstverschuldet...

2008 habe ich – aus für mich aktuell nicht nachvollziehbaren Gründen – 22 RewriteRules angelegt. Vermutlich für "Pretty URLs" oder sowas.

Eine der Regeln war:

Code: Select all

RewriteRule ^(serendipity\.css|serendipity_admin\.css) index.php?url=/$1 [L,QSA]

Irgendwann in den letzten 15 Jahren ist dann halt die serendipity_admin.js dazugekommen, die wird von der Regel nicht erfasst.

Mit dieser neuen Regel

Code: Select all

RewriteRule ^(serendipity|serendipity_admin)\.(css|js) index.php?url=/$1.$2 [L,QSA]

scheint es jetzt zu funktionieren.

Ich habe Angst, was mir noch alles fehlt, aber ich weiß jetzt, wie ich es finde und korrigiere

Danke an onli für den entscheidenden Anschubs!

[onli]

Alte Blogs sammeln Problemchen an ;) Freut mich, dass du es gelöst bekommen hast.

[mitch]

Nachdem die Buttons wieder liefen, habe ich festgestellt, dass sich manche Kommentare nicht als Ham oder Spam lernen lassen wollten. Im Error-Log habe ich gesehen, dass es Duplicate-Key-Verletzungen beim Schreiben von Tokens in die Bayes-Wortliste gibt.

Ich habe jetzt folgendes festgestellt:

1. Irgendwann hat das Plugin den Tabellennamen der Wortliste von serendipity_spamblock_bayes auf b8_wordlist gewechselt. Meine alte, gut trainierte Wortliste mit ~32000 Einträgen liegt jetzt ungenutzt rum und die neue hat gerade mal 300 Einträge, was wohl der Grund für die momentan sehr schlechten Erkennungsraten ist.
   • Hätte diese Änderung im Changelog erwähnt werden sollen? man muss komplett neu trainieren und die alte Tabelle kann gelöscht werden, die nimmt ja nur ggf. viel Platz weg (ich hab sie zum Testen erstmal nur umbenannt, aber niemand scheint sie zu vermissen)
   • Der Tabelle b8_wordlist fehlt der {$serendipity['dbPrefix']} – ist das ein behebenswerter Fehler? Das wäre ja gleich wieder ein Wechsel des Tabellennamens…
2. Die Duplicate Keys rühren daher, dass die Datenbank case-insensitive läuft und z.B. "auf" und "Auf" nicht unterscheidet, der PHP-Code dagegen case-sensitive arbeitet. Wenn nur das Token "auf" schon vorhanden ist, dann läuft das Token "Auf" in den PHP-Codepfad für ein neues Token ("auf" != "Auf") und versucht einen INSERT, den die Datenbank mit einer Primärschlüsselverletzung quittiert (weil "auf" == "Auf" und bereits vorhanden ist).
   • Dieses Problem habe ich behoben, indem ich die Token-Spalte einzeln auf eine case-sensitive Collation umgestellt habe:

     Code: Select all

     alter table b8_wordlist modify column token varchar(255) collate 'utf8mb4_bin';

     Seitdem scheint alles zu funktionieren.
   • Sollte das im Plugin in der Tabellendeklaration korrigiert werden?
   • Oder sollte lieber der PHP-Code so angepasst werden, dass er nur mit Kleinbuchstaben arbeitet? Dafür müssten vermutlich am Anfang alle Tokens des Kommantartextes lowercased werden und anschließend auch alle aus der Datenbank gelesenen Tokens.

Mich wundert, dass das noch niemand drüber gestolpert ist, das Plugin wird doch vermutlich öfter eingesetzt. Liegt es daran, dass ich mit MySQL (bzw. MariaDB) unterwegs bin? Verhält sich SQLite da anders und ist per Default case-sensitive?

[onli]

Hey,
Das Bayes-Plugin hab ich vor einer Weile massiv überarbeitet, da kommen die Probleme her. Vorher hatten es einen umfangreichen Backendbereich, den am Laufen zu halten ein Problem wurde, und es benutzte einen eigenen Bayes-Filter, geforkt von einer sehr frühen b8-Version, was unseren zu wartenden Code aufblähte. Das Update 1.0 hat es auf die damals aktuelle Version von b8 umgestellt und den Backendbereich vereinfacht. Bei mir funktioniert das gut, aber bei mir läuft SQLite.

Jetzt weiß ich nicht, ob die Duplicate-Key-Verletzungen mit unterschiedlichen Standardeinstellungen zusammenhängen oder ob sich einfach nur kein MySQL-Nutzer bisher darüber beschwert hat.

Der Reihe nach:

Hätte diese Änderung im Changelog erwähnt werden sollen? man muss komplett neu trainieren und die alte Tabelle kann gelöscht werden, die nimmt ja nur ggf. viel Platz weg (ich hab sie zum Testen erstmal nur umbenannt, aber niemand scheint sie zu vermissen)

Ja, auf jeden Fall. Das hätte ins Changelog gehört. Und eigentlich hätte die alte Tabelle in die neue eingelernt werden sollen, zumindest optional. Ich habe den Bruch nichtmal prominent in meinem Blogartikel erwähnt, https://www.onli-blogging.de/1960/Spamb ... rsion.html, nur als letzten Satz. Das überrascht mich selbst und tut mir jetzt leid.

Ich wollte das Plugin damals so simpel wie möglich halten, das weiß ich noch, aber es hätte zumindest erwähnt gehört. Wenn ich mich richtig erinnere habe ich es aber auch nicht groß als Problem gesehen, weil in meinen Tests mit ein paar eingelernten Kommentaren die Spamerkennung sehr schnell wieder gut wurde, eigentlich besser als vorher.

Der Tabelle b8_wordlist fehlt der {$serendipity['dbPrefix']} – ist das ein behebenswerter Fehler? Das wäre ja gleich wieder ein Wechsel des Tabellennamens…

Ist der fehlende Prefix in deinem Setup ein Problem? Mein Eindruck ist, dass mittlerweile der Datenbankname selbst für die Unterscheidung zwischen Projekten benutzt wird und der Prefix so nicht mehr notwendig ist. Es würde uns die Migration der Daten sparen, der vom Plugin genutzte b8-Tabellenname ist konfigurierbar. Was meinst du?

• Sollte das im Plugin in der Tabellendeklaration korrigiert werden?
• Oder sollte lieber der PHP-Code so angepasst werden, dass er nur mit Kleinbuchstaben arbeitet? Dafür müssten vermutlich am Anfang alle Tokens des Kommantartextes lowercased werden und anschließend auch alle aus der Datenbank gelesenen Tokens.

Da ich das Problem auf SQLite nicht beobachtet habe - ich geh jetzt einfach mal davon aus, dass es nicht am unterschiedlichen Error-Reporting der Datenbankfunktionen liegt - scheint mit die Lösung über die Datenbankebene geschickter. Das ist wohl auch, was das b8-Projekt mittlerweile gemacht hat, in https://gitlab.com/l3u/b8/-/commit/137d ... affc1e239f, wenn ich das richtig sehe

Wir könnten wahrscheinlich deinen ALTER-Befehl zu https://github.com/s9y/additional_plugi ... es.php#L88 hinzufügen. Könntest du in https://github.com/s9y/additional_plugins/ einen PR aufmachen?

Wobei das lowercasen der Kommentare vor dem Einlernen und vor dem Bewerten durchaus auch eine gute Lösung wäre und für uns einfach. Ich wunder mich, dass b8 das nicht sowieso macht, das ist eigentlich in diesem Bereich eine Standardoptimierung. Ich frage mich, ob das vergessen wurde oder ob es im Test einen Unterschied machte.

[mitch]

Hätte diese Änderung im Changelog erwähnt werden sollen? man muss komplett neu trainieren und die alte Tabelle kann gelöscht werden, die nimmt ja nur ggf. viel Platz weg (ich hab sie zum Testen erstmal nur umbenannt, aber niemand scheint sie zu vermissen)

Ja, auf jeden Fall. Das hätte ins Changelog gehört. Und eigentlich hätte die alte Tabelle in die neue eingelernt werden sollen, zumindest optional. Ich habe den Bruch nichtmal prominent in meinem Blogartikel erwähnt, https://www.onli-blogging.de/1960/Spamb ... rsion.html, nur als letzten Satz. Das überrascht mich selbst und tut mir jetzt leid.

Ist nicht wild, ich hatte Spaß an der Fehlersuche
Muss ich halt ein paar Mal klicken jetzt, bis sich der Bayes-Filter wieder eingeschwungen hat. Und ohne die 20 Moderations-Mails pro Tag hätte ich ja auch gar nicht gemerkt, dass ich irgendwelche Probleme im Blog habe. Von daher war's gut

Der Tabelle b8_wordlist fehlt der {$serendipity['dbPrefix']} – ist das ein behebenswerter Fehler? Das wäre ja gleich wieder ein Wechsel des Tabellennamens…

Ist der fehlende Prefix in deinem Setup ein Problem? Mein Eindruck ist, dass mittlerweile der Datenbankname selbst für die Unterscheidung zwischen Projekten benutzt wird und der Prefix so nicht mehr notwendig ist. Es würde uns die Migration der Daten sparen, der vom Plugin genutzte b8-Tabellenname ist konfigurierbar. Was meinst du?

Mich stört der fehlende Prefix nicht wirklich, ich habe eine eigene Datenbank für das Blog angelegt.

Mein Verständnis war immer, dass es Hosting-Angebote gibt, die z.B. nur eine Database zur Verfügung stellen und dann müssen sich ggf. Blog, Forum und Mailserver die gleiche Datenbank teilen. Damit das funktioniert, hat sich dann jemand gedacht "wenn jede Anwendung einen Präfix vor ihre Tabellen, Indizies usw. schreibt, kommt sich ja niemand ins Gehege".
Wenn das jemand in dem Kontext benutzt, wird ihn der fehlende Präfix vermutlich stören.

Bei mir mit einer eigenen Database pro Anwendung (ich bin root, ich kann so viele anlegen, bis die Platte voll ist) oder bei Dir mit sqlite (da gibt's dann auch eine Datei bzw. einen Ordner pro Anwendung vermute ich mal?) dagegen ist das eher egal.

• Sollte das im Plugin in der Tabellendeklaration korrigiert werden?
• Oder sollte lieber der PHP-Code so angepasst werden, dass er nur mit Kleinbuchstaben arbeitet? Dafür müssten vermutlich am Anfang alle Tokens des Kommantartextes lowercased werden und anschließend auch alle aus der Datenbank gelesenen Tokens.

Da ich das Problem auf SQLite nicht beobachtet habe - ich geh jetzt einfach mal davon aus, dass es nicht am unterschiedlichen Error-Reporting der Datenbankfunktionen liegt - scheint mit die Lösung über die Datenbankebene geschickter. Das ist wohl auch, was das b8-Projekt mittlerweile gemacht hat, in https://gitlab.com/l3u/b8/-/commit/137d ... affc1e239f, wenn ich das richtig sehe

Wir könnten wahrscheinlich deinen ALTER-Befehl zu https://github.com/s9y/additional_plugi ... es.php#L88 hinzufügen.

Davor hätte ich etwas Angst: serendipity_event_spamblock_bayes.php ist der datenbankunabhängige Teil, es gibt in b8/storage spezifische Klassen abhängig vom ausgewählten Backend. Ich kann nicht einschätzen, ob dieses Collate-Zeugs MySQL-spezifisch ist oder mit SQLite auch funktioniert. Vermutlich müsste man dann die Tabellen-Erzeugung mit den die DB-Backends verlagern. (Ah - das stimmt wohl, denn der Commit aus b8 bezieht sich explizit nur auf MySQL.)
Wie man eine Migration mit dem Alter-Statement baut, weiß ich auch nicht (man will das ja nicht bei jedem Aufruf wiederholen). Anders als bei s9y selbst gibt's für die Plugins kein Standardvorgehen für DB-Änderungen, oder?
Außerdem habe ich keine Chance, das zu testen (also ich kann live auf meinem Blog was machen, aber ich kann weder die anderen Backends testen noch wiederholte Neuinstallationen oder Updates durchführen).
Ich fürchte, das ist eine Nummer zu groß für mich :-/

Von daher ist es vielleicht doch einfacher, im PHP an allen Ecken und Enden lowercase-Aufrufe einzustreuen, dann muss man an die DB nicht ran (aber wenn man die DB nicht migriert, muss man nach jedem Lesen aus der DB erst einmal jedes Token lowercasen, hmmm…).

[onli]

Wir haben doch in der setupDB() den Part für mysql:

Code: Select all

switch ($serendipity['dbType']) {
    case 'mysql':
    case 'mysqli':
        $sql = "INSERT IGNORE INTO b8_wordlist (token, count_ham) VALUES ('b8*dbversion', 3);";
        serendipity_db_query($sql);
        $sql = "INSERT IGNORE INTO b8_wordlist (token, count_ham, count_spam) VALUES ('b8*texts', 0, 0);";
        serendipity_db_query($sql);
                
        # our recycler bin needs to copy the comments table
        $sql = "CREATE TABLE IF NOT EXISTS
                   {$serendipity['dbPrefix']}spamblock_bayes_recycler
                   LIKE
                   {$serendipity['dbPrefix']}comments";
        serendipity_db_schema_import($sql);
        break;

Vor dem SQL-Statement für spamblock_bayes_recycler, da würde ich das reinsetzen.

Aber ja, gehört getestet. Ich habe könnte das in meinem uberspace-Testblog ausprobieren, vll hast du auch eine passende Testumgebung?

... mit sqlite (da gibt's dann auch eine Datei bzw. einen Ordner pro Anwendung vermute ich mal?)

Eine Datei, genau.

Anders als bei s9y selbst gibt's für die Plugins kein Standardvorgehen für DB-Änderungen, oder?

Standard wäre schon, diese setupDB-Funktion zu erweitern. Soll es nicht jedes mal laufen, mit einer Pluginkonfigurationsvariable für die Versionierung des Datenbankschema. Ich vermute aber, das ALTER TABLE mehrfach auszuführen wäre hier kein Problem, ein Umstellen auf die gleiche collation macht doch wahrscheinlich nichts?

Aber stimmt, anders als der Kern haben die Plugins kein eingebautes System für Datenbankmigrationsdateien.

[mitch]

Wir haben doch in der setupDB() den Part für mysql:

Code: Select all

switch ($serendipity['dbType']) {
    case 'mysql':
    case 'mysqli':
        $sql = "INSERT IGNORE INTO b8_wordlist (token, count_ham) VALUES ('b8*dbversion', 3);";
        serendipity_db_query($sql);
        $sql = "INSERT IGNORE INTO b8_wordlist (token, count_ham, count_spam) VALUES ('b8*texts', 0, 0);";
        serendipity_db_query($sql);
                
        # our recycler bin needs to copy the comments table
        $sql = "CREATE TABLE IF NOT EXISTS
                   {$serendipity['dbPrefix']}spamblock_bayes_recycler
                   LIKE
                   {$serendipity['dbPrefix']}comments";
        serendipity_db_schema_import($sql);
        break;

Vor dem SQL-Statement für spamblock_bayes_recycler, da würde ich das reinsetzen.

Ah, nicht weit genug runtergescrollt

Wann genau wird das Setup denn ausgeführt? Jedes Mal beim Zugriff? Nur beim Start eines neuen PHP-Threads?
Ich werde das mal loggen und beobachten.)

(Hintergrund: Rechtetrennung. Der DB-User meiner Mediawiki-Instanz hat keine Rechte für CREATE TABLE usw., der darf nur SELECT/INSERT/UPDATE/DELETE. Wenn ich ein Update einspiele, ändere ich temporär die DB-Credentials auf einen User mit mehr Rechten. Bei s9y ginge das für das eigentliche Blog wohl auch, bei den Plugins bin ich mir unsicher. Ausprobiert habe ich es bisher nicht, aber deshalb frage ich mich, wann das ausgeführt wird.)

Aber ja, gehört getestet. Ich habe könnte das in meinem uberspace-Testblog ausprobieren, vll hast du auch eine passende Testumgebung?

Leider nein. Ich mache sogar meine eigenen PHP- und CSS-Änderungen im Live-System… Pfui -_-;

Anders als bei s9y selbst gibt's für die Plugins kein Standardvorgehen für DB-Änderungen, oder?

Standard wäre schon, diese setupDB-Funktion zu erweitern. Soll es nicht jedes mal laufen, mit einer Pluginkonfigurationsvariable für die Versionierung des Datenbankschema. Ich vermute aber, das ALTER TABLE mehrfach auszuführen wäre hier kein Problem, ein Umstellen auf die gleiche collation macht doch wahrscheinlich nichts?

Schlimmes machen wird das nichts, aber die Anwendung muss halt dauerhaft mit DB-Adminrechten laufen.
Wenn das der Standard ist, dann ist das schon ok, ich will ja hier nicht die Architektur des ganzen Projektes ummodeln

Wenn das doch nur die Stelle ist, bereite ich einen PR vor, kann ggf. etwas dauern.

Danke!

[onli]

Hm, ja. Plugins können alles machen und da gibt es ein paar, die nachträglich Tabellen anlegen. Deswegen würde die Rechtetrennung da nicht gut funktionieren.

Die Funktion sollte immer aufgerufen werden wenn b8 nicht initialisiert ist und der Plugincode läuft, bei jedem Bewerten bzw Markieren eines Kommentars.

[mitch]

Schön, die Plugin-Updates sind verfügbar

Ich habe noch eine weitere Frage: Wo kann ich in der Admin-Oberfläche zwischen "moderieren" und "blocken" umstellen?

Aktuell bekomme ich den ganzen Spam in die Moderation, auch wenn die Spamizität bei über 90% liegt. Da muss ich viel klicken

Ich habe in serendipity_event_spamblock_bayes.php geguckt. Dort wird ab 80% Spamizität auf die Konfigurationseinstellung 'method' geguckt, was getan werden soll. Das steht bei mir wohl auf 'moderate' und ich hätte lieber 'block'.

Aber wo in der Adminoberfläche ist der Schalter versteckt?

Auch die Config-Einstellung 'recycler' müsste doch irgendwo in der Adminoberfläche auftauchen. Ich weiß, dass ich das vermutlich direkt in der s9y-Datenbank umstellen kann (oder den PHP-Code umbauen), aber ich möchte nach der langen Konfigurationspause im Blog wieder lernen, wo die Knöpfe sind

Kann es sein, dass die Einstellmöglichkeit irgendwie verlorgengegangen ist?

Umgekehrt habe ich beim greppen noch den übersetzten Text PLUGIN_EVENT_SPAMBLOCK_BAYES_METHOD_CUSTOM gefunden, der im Code nicht mehr benutzt zu werden scheint. (Die 80% waren wohl mal konfigurierbar.)

[onli]

Die Konfiguration des Plugins wurde reduziert, stimmt. Aber zwischen moderieren und blocken kannst du umschalten - geh dafür auf den Menüpunkt Plugins, wechsel auf das Tab für Ereignisplugins, und gehe dann dort in die Konfiguration des Bayes-Plugins.

Dort könntest du ebenfalls den Papierkorb deaktiveren. Ich würde aber empfehlen, ihn aktiviert zu lassen. Zumindest eine Weile.

[mitch]

Aber zwischen moderieren und blocken kannst du umschalten - geh dafür auf den Menüpunkt Plugins, wechsel auf das Tab für Ereignisplugins, und gehe dann dort in die Konfiguration des Bayes-Plugins.

Danke, das war's! Jetzt klappt's wieder prima.
Der Papierkorb war schon an, aber da war halt nur das drin, was ich manuell gelöscht habe.

Meine Verwirrung rührte wohl daher, dass das Plugin "spamblock" seine Konfigurationsseite links im Menü unter "Aktivitäten" zur Verfügung stellt (die gleiche Seite, die auch über die Ereignisplugins erreichbar ist).
Weil "spamblock_bayes" auch unter "Aktivitäten" aufrufbar ist, dachte ich, das wäre genauso – da ist dann allerdings nur der Papierkorb zu erreichen und hab ich die den Einstieg über die Ereignisplugins komplett aus den Augen verloren.

Danke!
Mitch