SPAM-Biene wieder installiert und Klick-Prozedur durchgeführt. Das Ergebnis der SQL-Abfrage bleibt sich gleich. Und ja: Ich habe kontrolliert, ob ich wirklich die richtige DB betrachte. ?
Eher so ... Plugin event Biene einmal über Spartacus bzw Plugin Backend löschen. Dann einmal woandershin, zb auf die Backend Startseite, klicken und dann das event Plugin wieder installieren und einrichten. [Das kann man jetzt auch weglassen da du es ja schon einmal gemacht hast!]
Dann wieder auf die Backend Startseite und zurück zur Plugin Liste - auf Sidebar umstellen. Dann sidebar Biene installieren. Dann Start, dann sidebar Biene wieder deinstallieren.
Per SQL kontrollieren.
Nur falls du dir Sorgen machst: Die gekoppelten sidebar Plugins können eigentlich auch als event stehenbleben, denn für das Update spielt es keine wesentliche Rolle. Wir haben schon immer darauf geachtet, im Falle eines gekoppelten Sidebar Plugin Updates das elterliche Event Plugin eine Versionsnummer hoch zu setzen, auch wenn sich darin nicht geändert hat, so dass immer ein Spartacus event Plugin Update getriggert wurde.
Beat Post author am |
Ich nehme alles zurück und behaupte das Gegenteil! DOCH: falsche DB!
Nach der ganzen Aktion sieht es nun so aus: 21 Einträge - ALLE als plugintype = sidebar
Komisch finde ich einfach die unterschiedliche Anzahl.
Die ergibt sich aus den physisch vorhandenen lokalen (local) Daten. Allso praktisch alles was du jemals da installiert hast und nicht physikalisch gelöscht hast.
BTW die hidden Biene Kommentar Anzeige wird hier gezeigt, da hast du irgendetwas noch nicht wieder richtig eingestellt.
So wie beschrieben. 1x in Sidebar Plugins installieren hineinschauen und danach SQL check. Wenn das nicht reicht nochmal zusätzlich in Plugins updaten vorbei schauen (vielleicht darauf achten, dass die sidebar List Anzeige aktiv ist).
Beat Post author am |
So: sidebarlogo-Plugin erstmal installiert, Klick-Prozedur, dann wieder deinstalliert, Klick-Prozedur, dann Plugins updaten "Nichts". Dann per FTP-Verzeichnis löschen. Dann auf DB gucken und SQL-Abfrage.
Das sidebarlogo-Plugin wird immer noch aufgelistet. Nun jedoch auch als plugintype = sidebar.
Beat Post author am |
Wer macht sich denn Sorgen, wenn Gott auf der Rückbank sitzt? ?
Aha, damit muss ich mich wohl präzisieren: In der Liste werden alle Plugins ausgewiesen die jemals installiert wurden, selbst wenn sie komplett deinstalliert wurden. ?
Das macht aber keinen Sinn (und ich sehe gerade das ist bei mir auch so!) ... Und es macht immer noch keinen Sinn! . . . . denk denk ... ahhh ich glaube auch zu wissen warum - also da fehlt noch was gefixt...
Das stellt sich als unerwartet schwierig heraus. Denn es gibt auf die Schnelle keinen Weg das korrekt gegeneinander zu eruieren, außer man löscht alles zuerst und trägt es dann neu wieder ein. So macht es die event Liste. Das wollte ich aber gerade vermeiden...
OK - ist erledigt. Braucht nur include/admin/plugins.inc.php update, wenn der Rest schon drauf war. und einen LOOK into Sidebar Plugins installieren.
Beat Post author am |
Nach dem heutigen Styx-Update habe ich die Klick-Prozedur und danach die DB-Abfrage nochmals durchgeführt. Hier das Ergebnis:
Resultat= 20 Einträge (-1 templatechooser)
davon 15 sidebar- und 5 event-plugins. Nachfolgend die 5 event-Plugins:
serendipity_event_freetag
serendipity_plugin_imagesidebar
serendipity_event_spamblock_bee
serendipity_event_staticpage
serendipity_event_statistics
Nach meiner bescheidenen Meinung ist das beim imagesidebar-Plugin falsch. Die Anderen sind sowohl-als-auch. Bei den als event-plugins ausgezeichneten Einträgen ist das Feld "upgrade-version" leer (ist vermutlich so gewollt).
Nachtrag: Das Resultat auf www.beatsblog.ch ist identisch mit hier.
Sehr strange.... Ich erinnere mich, dass ich an ziemlich genau der Stelle auch schon einmal war (und es wurden zusätzlich sogar bestimmte dependency (creativecommons, multilingual, templatedropdown, ...) Plugins ebenfalls so ausgezeichnet... aber ... mit dem letzten Stand sollte das nicht vorkommen... (außer vielleicht sie stünden eventuell so in der Datenbank).
Was mich irritiert ist, dass da serendipity_event_xyz steht. Das dürfte nicht sein wenn du explizit mit der bereits genannten query nachfragst. (
SELECT * FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local'
)
Probiere mal mit der übersichtlicheren:
SELECT class_name, version, upgrade_version, plugintype FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local'
----
Zum zweitgenannten Problem, dass bestimmte event Plugins möglicherweise noch keine upgrade_version haben, kann man geteilter Meinung sein ... entweder sie befüllt sich später mal von selbst, wenn dann eine neue upgrade_version vorliegt, oder man trägt jetzt die aktuelle Version noch nach, damit alles seine Ordnung hat und niemand dauernd überlegen muss, ob leer oder befüllt der eigentliche Standard ist und ob dies generell oder nur für bestimmte Plugins gilt. Ich habe das mit einem der letzten Commits für event Plugins gerade verhindert, aber unter der Prämisse, dass bereits alles richtig bzw überhaupt eingetragen war. Denn je nachdem läuft die Pluginlisten Synchronisation ab; sie ist nicht einfach nur das immerwährende Eintragen der XML Spartacus fetch Daten.
OK, die serendipity_event_xyz Irritation ist damit schon mal weg. ? Verbleiben die falschen event Einträge in plugintype, insbesondere auch für imagesidebar..., und die fehlenden UV Einträge. Bitte noch einmal den letzten SQL run jetzt.
Dabei fiel mir ein Weiteres auf: Bitte zusätzlich einmal
SELECT class_name,version,upgrade_version,plugintype,pluginlocation FROM `styx_pluginlist` WHERE class_name LIKE '%entrypaging'
ausgeben, bevor ich mich an eine Korrektur wage.
Beat Post author am |
OK. Here we go! Abfrageresultat von blog.dokumenzi.ch:
class_name version upgrade_version plugintype pluginlocation
serendipity_event_entrypaging 1.73 event Spartacus
serendipity_event_entrypaging 1.73 event local
Abfrageresultat von beatsblog.ch:
class_name version upgrade_version plugintype pluginlocation
serendipity_event_entrypaging 1.73 event Spartacus
serendipity_event_entrypaging 1.73 1.73 event local
Beat Post author am |
SELECT class_name, version, upgrade_version, plugintype FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local'
zeigt jetzt folgendes Resultat auf der DB von blog.dokumenzi.ch:
Das sieht jetzt gut aus! Komisch allerdings ist, dass ich ja nicht irgendwie remote herumgespielt hätte, sondern nur hier auf blog.doku einmal Event Plugins installieren getriggert habe. Das war es schon. Warum das praktisch gleich zu beatblog ist kann eben nur sein wenn du dort ebenso schon tätig gewesen bist. Die Reihenfolge ist etwas merkwürdig, aber vielleicht ist dort doch nicht alles haargenau so wie hier. Warum stehen bei beiden eigentlich eventwrapper und bee sidebar? Hattest du sie nach der Blog Installation ausprobiert und aus der Liste wieder gelöscht? Oder ist das eine Folge der Übernahme der db Daten?
Bei den entrypaging Ausgaben wundert mich eben folgendes. Hier auf doku wird unter Wartung - Plugin Zombies das entrypaging event und das Biene event Plugin angezeigt, obwohl beide ja valide installiert sind. Das darf eigentlich nicht sein, so dass ich annehme, dass beide eine falsche bzw keine Einstellung im upgrade Feld haben. Da das auf beatsblog anders aussieht, würde ich dich bitten dort einmal auf Plugins Zombies zu checken.
Beat Post author am |
www.beatsblog.ch - Suche nach Plugin-Zombies - Nothing to do!
Alles Weitere morgen. (ähh... heute, nach dem Schlafen) ?
Ian Styx am |
So soll das sein. Genau!
Also fehlt hier nur der Nachtrag der upgrade_version in der local Variante. Die Frage ist, warum es dort nicht drinnen ist. Ich nehme aber stark an, dass es aufgrund der developer Versionen und der lokalen dev Updates über FTP passiert ist, also nichts, was in einem normalen System geschehen kann. Bitte check auch noch mal
SELECT class_name,version,upgrade_version,plugintype,pluginlocation FROM `styx_pluginlist` WHERE class_name LIKE '%spamblock_bee'
auf beiden Blogs. Es müsste ähnlich aussehen wie bei entrypaging.
Beat Post author am |
spamblock_bee auf www.beatsblog.ch
class_name version upgrade_version plugintype pluginlocation
serendipity_event_spamblock_bee 1.3.7 event Spartacus
serendipity_event_spamblock_bee 1.3.7 1.3.7 event local
serendipity_plugin_spamblock_bee 1.3.7 sidebar Spartacus
serendipity_plugin_spamblock_bee 1.3.7 1.3.7 sidebar local
und hier, auf blog.dokumenzi.ch
class_name version upgrade_version plugintype pluginlocation
serendipity_plugin_spamblock_bee 1.3.7 sidebar Spartacus
serendipity_event_spamblock_bee 1.3.7 event Spartacus
serendipity_event_spamblock_bee 1.3.7 event local
serendipity_plugin_spamblock_bee 1.3.7 1.3.7 sidebar local
Beat Post author am |
Warum stehen bei beiden eigentlich eventwrapper und bee sidebar? Hattest du sie nach der Blog Installation ausprobiert und aus der Liste wieder gelöscht? Oder ist das eine Folge der Übernahme der db Daten?
So aus dem Gedächtnis heraus würde ich sagen, ausprobiert: Nein. Beim eventwrapper weiss ich nicht mal was der macht. Aber: Ich habe 14 Jahre Blog-Basteln hinter mir. Es ist gut möglich, dass ich diese Plugins vor Jahren mal installiert und wieder deinstalliert habe. Deshalb würde ich darauf tippen, das diese Einträge von "früher" kommen.
Dem widerspricht jedoch mein Vorgehen beim Erstellen von www.blog.dokumenzi.ch und auch von www.beatsblog.ch. Weil STYX, habe ich hier alle Plugins neu und einzeln installiert und dazu keine DB-Daten aus dem alten Blog übernommen.
Aber: Ich klicke so oft irgendwo rum, ohne genau zu wissen was ich mache... da ist alles möglich. Du siehst also: Ich kann Deine Fragen nicht adäquat beantworten. ?
Beat Post author am |
SPAM-Biene wieder installiert und Klick-Prozedur durchgeführt. Das Ergebnis der SQL-Abfrage bleibt sich gleich. Und ja: Ich habe kontrolliert, ob ich wirklich die richtige DB betrachte. ?
Ian Styx am |
Eher so ... Plugin event Biene einmal über Spartacus bzw Plugin Backend löschen. Dann einmal woandershin, zb auf die Backend Startseite, klicken und dann das event Plugin wieder installieren und einrichten. [Das kann man jetzt auch weglassen da du es ja schon einmal gemacht hast!]
Dann wieder auf die Backend Startseite und zurück zur Plugin Liste - auf Sidebar umstellen. Dann sidebar Biene installieren. Dann Start, dann sidebar Biene wieder deinstallieren.
Per SQL kontrollieren.
Nur falls du dir Sorgen machst: Die gekoppelten sidebar Plugins können eigentlich auch als event stehenbleben, denn für das Update spielt es keine wesentliche Rolle. Wir haben schon immer darauf geachtet, im Falle eines gekoppelten Sidebar Plugin Updates das elterliche Event Plugin eine Versionsnummer hoch zu setzen, auch wenn sich darin nicht geändert hat, so dass immer ein Spartacus event Plugin Update getriggert wurde.
Beat Post author am |
Ich nehme alles zurück und behaupte das Gegenteil! DOCH: falsche DB!
Nach der ganzen Aktion sieht es nun so aus: 21 Einträge - ALLE als plugintype = sidebar
SORRY ! ?
Ian Styx am |
Prust!!!! ?
Beat Post author am |
? Ja, der Brüller des Tages! ?
Bleibt ja jetzt nur noch die Frage, wie ich das "sidebarlogo" Dingens aus der DB von www.beatsblog.ch kriege.
Ian Styx am |
Die ergibt sich aus den physisch vorhandenen lokalen (local) Daten. Allso praktisch alles was du jemals da installiert hast und nicht physikalisch gelöscht hast.
BTW die hidden Biene Kommentar Anzeige wird hier gezeigt, da hast du irgendetwas noch nicht wieder richtig eingestellt.
Ian Styx am |
So wie beschrieben. 1x in Sidebar Plugins installieren hineinschauen und danach SQL check. Wenn das nicht reicht nochmal zusätzlich in Plugins updaten vorbei schauen (vielleicht darauf achten, dass die sidebar List Anzeige aktiv ist).
Beat Post author am |
So: sidebarlogo-Plugin erstmal installiert, Klick-Prozedur, dann wieder deinstalliert, Klick-Prozedur, dann Plugins updaten "Nichts". Dann per FTP-Verzeichnis löschen. Dann auf DB gucken und SQL-Abfrage.
Das sidebarlogo-Plugin wird immer noch aufgelistet. Nun jedoch auch als plugintype = sidebar.
Beat Post author am |
Wer macht sich denn Sorgen, wenn Gott auf der Rückbank sitzt? ?
Ian Styx am |
Aha, damit muss ich mich wohl präzisieren: In der Liste werden alle Plugins ausgewiesen die jemals installiert wurden, selbst wenn sie komplett deinstalliert wurden. ?
Das macht aber keinen Sinn (und ich sehe gerade das ist bei mir auch so!) ... Und es macht immer noch keinen Sinn! . . . . denk denk ... ahhh ich glaube auch zu wissen warum - also da fehlt noch was gefixt...
Commentbiene wieder OK
Ian Styx am |
? der zum Bleistift! ?
Ian Styx am |
Das stellt sich als unerwartet schwierig heraus. Denn es gibt auf die Schnelle keinen Weg das korrekt gegeneinander zu eruieren, außer man löscht alles zuerst und trägt es dann neu wieder ein. So macht es die event Liste. Das wollte ich aber gerade vermeiden...
Ian Styx am |
OK - ist erledigt. Braucht nur include/admin/plugins.inc.php update, wenn der Rest schon drauf war.
und einen LOOK into Sidebar Plugins installieren.
Beat Post author am |
Nach dem heutigen Styx-Update habe ich die Klick-Prozedur und danach die DB-Abfrage nochmals durchgeführt. Hier das Ergebnis:
Resultat= 20 Einträge (-1 templatechooser)
davon 15 sidebar- und 5 event-plugins. Nachfolgend die 5 event-Plugins:
Nach meiner bescheidenen Meinung ist das beim imagesidebar-Plugin falsch. Die Anderen sind sowohl-als-auch. Bei den als event-plugins ausgezeichneten Einträgen ist das Feld "upgrade-version" leer (ist vermutlich so gewollt).
Nachtrag: Das Resultat auf www.beatsblog.ch ist identisch mit hier.
Ian Styx am |
Sehr strange.... Ich erinnere mich, dass ich an ziemlich genau der Stelle auch schon einmal war (und es wurden zusätzlich sogar bestimmte dependency (creativecommons, multilingual, templatedropdown, ...) Plugins ebenfalls so ausgezeichnet... aber ... mit dem letzten Stand sollte das nicht vorkommen... (außer vielleicht sie stünden eventuell so in der Datenbank).
Was mich irritiert ist, dass da serendipity_event_xyz steht. Das dürfte nicht sein wenn du explizit mit der bereits genannten query nachfragst. (
)
Probiere mal mit der übersichtlicheren:
----
Zum zweitgenannten Problem, dass bestimmte event Plugins möglicherweise noch keine upgrade_version haben, kann man geteilter Meinung sein ... entweder sie befüllt sich später mal von selbst, wenn dann eine neue upgrade_version vorliegt, oder man trägt jetzt die aktuelle Version noch nach, damit alles seine Ordnung hat und niemand dauernd überlegen muss, ob leer oder befüllt der eigentliche Standard ist und ob dies generell oder nur für bestimmte Plugins gilt. Ich habe das mit einem der letzten Commits für event Plugins gerade verhindert, aber unter der Prämisse, dass bereits alles richtig bzw überhaupt eingetragen war. Denn je nachdem läuft die Pluginlisten Synchronisation ab; sie ist nicht einfach nur das immerwährende Eintragen der XML Spartacus fetch Daten.
Beat Post author am |
Neue SQL-Abfrage
Ian Styx am |
OK, die serendipity_event_xyz Irritation ist damit schon mal weg. ?
Verbleiben die falschen event Einträge in plugintype, insbesondere auch für imagesidebar..., und die fehlenden UV Einträge. Bitte noch einmal den letzten SQL run jetzt.
Dabei fiel mir ein Weiteres auf: Bitte zusätzlich einmal
ausgeben, bevor ich mich an eine Korrektur wage.
Beat Post author am |
OK. Here we go! Abfrageresultat von blog.dokumenzi.ch:
Abfrageresultat von beatsblog.ch:
Beat Post author am |
zeigt jetzt folgendes Resultat auf der DB von blog.dokumenzi.ch:
zeigt jetzt folgendes Resultat auf der DB von beatsblog.ch:
Ian Styx am |
Das sieht jetzt gut aus! Komisch allerdings ist, dass ich ja nicht irgendwie remote herumgespielt hätte, sondern nur hier auf blog.doku einmal Event Plugins installieren getriggert habe. Das war es schon. Warum das praktisch gleich zu beatblog ist kann eben nur sein wenn du dort ebenso schon tätig gewesen bist. Die Reihenfolge ist etwas merkwürdig, aber vielleicht ist dort doch nicht alles haargenau so wie hier. Warum stehen bei beiden eigentlich eventwrapper und bee sidebar? Hattest du sie nach der Blog Installation ausprobiert und aus der Liste wieder gelöscht? Oder ist das eine Folge der Übernahme der db Daten?
Bei den entrypaging Ausgaben wundert mich eben folgendes. Hier auf doku wird unter Wartung - Plugin Zombies das entrypaging event und das Biene event Plugin angezeigt, obwohl beide ja valide installiert sind. Das darf eigentlich nicht sein, so dass ich annehme, dass beide eine falsche bzw keine Einstellung im upgrade Feld haben. Da das auf beatsblog anders aussieht, würde ich dich bitten dort einmal auf Plugins Zombies zu checken.
Beat Post author am |
www.beatsblog.ch - Suche nach Plugin-Zombies - Nothing to do!
Alles Weitere morgen. (ähh... heute, nach dem Schlafen) ?
Ian Styx am |
So soll das sein. Genau!
Also fehlt hier nur der Nachtrag der upgrade_version in der local Variante. Die Frage ist, warum es dort nicht drinnen ist. Ich nehme aber stark an, dass es aufgrund der developer Versionen und der lokalen dev Updates über FTP passiert ist, also nichts, was in einem normalen System geschehen kann. Bitte check auch noch mal
auf beiden Blogs. Es müsste ähnlich aussehen wie bei entrypaging.
Beat Post author am |
spamblock_bee auf www.beatsblog.ch
und hier, auf blog.dokumenzi.ch
Beat Post author am |
So aus dem Gedächtnis heraus würde ich sagen, ausprobiert: Nein. Beim eventwrapper weiss ich nicht mal was der macht. Aber: Ich habe 14 Jahre Blog-Basteln hinter mir. Es ist gut möglich, dass ich diese Plugins vor Jahren mal installiert und wieder deinstalliert habe. Deshalb würde ich darauf tippen, das diese Einträge von "früher" kommen.
Dem widerspricht jedoch mein Vorgehen beim Erstellen von www.blog.dokumenzi.ch und auch von www.beatsblog.ch. Weil STYX, habe ich hier alle Plugins neu und einzeln installiert und dazu keine DB-Daten aus dem alten Blog übernommen.
Aber: Ich klicke so oft irgendwo rum, ohne genau zu wissen was ich mache... da ist alles möglich. Du siehst also: Ich kann Deine Fragen nicht adäquat beantworten. ?