JA, geh/rad ruhig mal an die Luft... Morgen ist ein neuer Tag und dann kannst du etwas weiter herumexperimentieren, denn entrypaging 1.72 ist unterwegs. ? Es wäre doch Schade um all die Mühe!
Beat Post author am |
V1.72 ohne Smarty crasht. Hier, wie auch auf www.beatsblog. ch. Das ist die Fehlermeldung, die angezeigt wird:
Warning: implode(): Invalid arguments passed in /home/sites/site100015826/web/styx-master/plugins/serendipity_event_entrypaging/serendipity_event_entrypaging.php: 303.
For more details set $serendipity['production'] = 'debug' in serendipity_config_local.inc.php to receive a full stack-trace.
Mit Smarty funktioniert das Plugin. Gemessene Ladezeit von https://www.beatsblog.ch/2633-Bleiben-Sie-zuhause!.html
ohne Plugin = 1,5 MB, 46 Requests, 989ms, davon 445 Wait
mit Plugin = 1,5 MB, 46 Requests, 2,18 sec, davon 1,54 Wait
habe deshalb das Plugin auf www.beatsblog.ch wieder deaktiviert.
Was es bzw sein Vorgänger macht, ist im Falle von Smarty AN einen doppelten Durchlauf der Datenbankanfragen zu vermeiden. Es hätte(?) ja sein können das es signifikanten Einfluß hat.
Wenn das durch Tests geklärt ist müssen wr weiter suchen, was diesen idle auslöst. Es gibt noch die Möglichkeit die erweiterten Plugin DB request zu überpüfen auf multilingual, categorytemplates und entryproperties. Oder abzuchecken ob mit der entrycat in relation zur entries Tabelle alles in Ordnung ist, bzw ob es überhaupt an der Schnelligkeit der einzelönen order erweiterten DB Abfragen liegt. Irgend etwas muss den entscheidenden Unterschied ausmachen der zu dieser Wartezeit führt. Wartezeit kann ja auch heißen, das etwas länger dauert, oder hakt, oder zuviel Arbeit hat... jedenfalls könnte es vielleicht interessant sein ob die time Synchronisation richtig läuft (siehe auch history hickups).
Jedenfalls darf das nicht sein und gehört herausgefunden was es auslöst!
Beat Post author am |
V1.73 läuft fehlerfrei. Habe nocheinmal Vergleichsmessungen gemacht (denen ich aber nicht so wirklich traue):
Getestet wurde immer dieser Beitrag: /2532-Abendstimmung.html
Da irritieren mich gleich zwei Dinge: 1. Wieso sollte die Steite auf blog.dokumenzi nur knapp halb so schwer sein? und 2. kein Unterschied auf beatsblog ob mit oder ohne Smarty? Getestet habe ich mit pingdom.com (Messtandort Frankfurt), vielleicht mache ich die gleichen Tests noch mit GTMetrix.com, ganz einfach zum Vergleich
Beat Post author am |
Also hier nochmasls die gleichen Seiten getestet mit GTMetrix.com (Serverstandort Vancouver, Canada):
Getestet wurde immer dieser Beitrag: /2532-Abendstimmung.html
Mal ganz abgesehen von den Loadtimes irritiert mich doch sehr, dass die Seitengrösse in KB oder MB fast Faktor 2 ist zwischen blog.dokumenzi und beatsblog. Ich teste da noch ein paar andere Seiten um herauszufinden, ob das ganz generell so ist. Das würde ja bedeuten, dass hier deutlich stärker komprimiert wird.
Beat Post author am |
Es bestätigt sich, dass hier viel besser/stärker komprimiert wird als auf beatsblog:
Diese Seiten habe ich ebenfalls mit GTMetrix.com getestet. Die Loadzeiten sind durch den Messstandort Vancouver natürlich deutlich höher, die Seitengrösse und die Requests sind jedoch nahezu identisch.
Ich glaube, dass das nicht aussagekräftig ist, denn es erlaubt keine Messung mit den Browser caches, also derjenigen Request Vorgänge, die nicht erneut geladen werden, weil sie 302 Not Modified etc sind.
Am besten sind Messungen mit Seiten im eigenen Browser - F12 - Netzwerkanalyse - Zeit der Abfrage ganz unten, a la UHR 42 Anfragen 1,20 MB / 157,48 KB übertragen Beendet: 2,07 s DOMContentLoaded: 708 ms load: 1,37 s
Wenn du Webmessungen wie die genannten durchführst, muss man sich nicht wundern, dass Saarland -> Vancouver länger dauert als Saarland -> Frankfurt und dann noch in diesen Zeiten. ?
Mit jeder Messung verändern sich auch beispielsweise die Seitenleistenbilder etc. die das Bild weiter verzerren.
Um zu verstehen, schaut man in die "Übertragen" Spalte und sieht was "Aus (dem) Cache" geladen wird. Für die (raced) Angaben siehe: "https://support.mozilla.org/en-US/questions/1267945". Das war mir auch neu! Also wieder was dazugelernt! ?
Beat Post author am |
Jedenfalls darf das nicht sein und gehört herausgefunden was es auslöst!
Ich will Deinen Tatendrang keinesfalls bremsen, doch aus meiner Sicht dürfte das ein ziemlich schwieriges Unterfangen werden. In dieser Installation verursacht das Plugin ja keinerlei (signifikante) Verzögerungen. Ich glaube eher, dass es auf Manitu-Seite eine irgendwie unglückliche Konstellation antrifft. Sei es PHP oder DB oder was sonst noch so mitspielt (Caching, Kompression, etc.).
Beat Post author am |
So zum Spass habe ich das ganze APCU-Zeugs wieder in die .htaccess von www.beatsblog.ch gekippt. Nun sind die Seitengrössen in KB vergleichbar mit hier (wo dieses APCU-Zeugs nicht vorhanden ist, jedoch nginx noch irgendwie mitspielt).
Die Seitenladezeiten sind nun hier wie dort etwas gleich schnell. Der Unterschied ist jedoch, dass hier das entrypaging-Plugin aktiv ist und auf www.beatsblog.ch nicht. Wenn ich das dort aktiviere, verlängert sich die Ladezeit einer Single-Entry-Page sofort um 1-2 Sekunden.
Kann sein..., aber es kann auch sein, dass es irgendeine Art von Abhängigkeit ist, die das auslöst. Ich hätte da möglicherweise in Verdacht etwaige Unstimmigkeiten in der Art wie du das Blog upgedated und mit den alten Datenn gefüttert hast, Vielleicht stimmen irgendwelche Verknüpfungen zwischen Datenbanktabellen (über die inkrementellen IDs) nicht mehr... und führen zu "nachdenklichen" Denkpausen ??? ?
Hört sich gut an! Und - Beat - 1-2s ist doch schon sehr viel besser als 4.5s, oder? Macht doch mal ein Beispiel dafür, vielleicht braucht jemand anderes auch so ein Spielzeug.
Apropos Spielzeug, Ich habe gestern und heute an der (Spartacus) Plugin Synchronsation geflickt und glaube, dass das dringend mal ausprobiert werden sollte! ?
Beat Post author am |
Ausprobieren klingt gut. Habe soeben die neusten Styx-Dateien aufgespielt (vollständig). Was kann ich denn jetzt ausprobieren?
Beat Post author am |
Ich hätte da möglicherweise in Verdacht etwaige Unstimmigkeiten in der Art wie du das Blog upgedated und mit den alten Datenn gefüttert hast, Vielleicht stimmen irgendwelche Verknüpfungen zwischen Datenbanktabellen (über die inkrementellen IDs) nicht mehr.
Mach mir keine Angst! Mein letzter SQL-Backup der usrprünglichen Original-S9Y-DB datiert vom 05.09.2019... Natürlich könnte ich immer noch die DB des noch bestehenden Blogs auf www.bbbeat.ch sichern, doch auch diese Daten enden am 16.01.2020....
Einmal auf "Seitenleisten-Plugins installieren" klicken (das reicht schon) und danach einmal nach "Plugins updaten" checken. Jetzt sollten alle locationtype = 'local' sidebar plugins korrekt als sidebar plugins ausgezeichnet sein und alle in version und upgrade_version gleichermaßen bestückt sein, wenn kein sidebar update in der Warteschlange vorliegt. PhpMyAdmin SQL Tab;
SELECT * FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local'
Es ist auch nur eine der Möglichkeiten um weiter im Nebel zu stochern. Wenn man ein älteres Blog hat, ist es in der Historie ja sicher durchaus öfter mal vorgekommen, dass man Einträge oder Bilder oder Kategorien oder dergleichen gelöscht hat. Das hinterläßt Löcher in der DB, da der inkrementelle Counter stur immer weiter zählt. Die Tabellen die davon abhängen sind darauf angewiesen etc. Je nachdem wie man nun die alte DB exportiert/importiert und/oder anderweitige Synchronisatiionen laufen (images, plugins beispielsweise), kann so eine andere (zu)Ordnung entstehen, als diejenge, auf denen sich ältere Tabellen berufen. Du verstehst? Ohne das exakt nachzustellen ist es natürlich nur eine ziemlich blinde Vermutung und vielleicht auch nur völliger Blödsinn.
Beat Post author am |
O.K.
Hier (bog.dokumenzi.ch) zeigt die SQL-Abfrage insgesamt 16 Einträge an. Davon 15 "sidebar" und 1 "event" (=spamblock_bee)
Auf www.beatsblog.ch zeigt die SQL-Abfrage insgesamt 21 Einträge an. Davon 20 "sidebar" und 1 "event" (sidebarlogo)
Also ich werde daraus nicht sonderlich schlau, doch vielleicht hilft es Dir ja.
Beat Post author am |
Hmmm.. Wenn ich mir die 21 Einträge auf www.beatsblog.ch genauer ansehe, erscheinen als "sidebar" ausgezeichnet z.B.:
serendipity_event_spamblock_bee
serendipity_event_staticpage
serendipity_event_statistics
serendipity_event_freetag
Kann ja sein, denn diese Plugins können auch in der Seitenleiste aktiv sein (soviel ich weiss). Komisch finde ich einfach die unterschiedliche Anzahl.
Beide 1ner, bzw insbesondere sidebarlogo mit 'event' sind falsch. Einmal über Spartacus löschen und Klickprozedur wiederholen. Danach der Gegencheck mit der SQL Anweisung.
Es geht um die 4 nebeneinanderliegenden Felder 7,8,9,10: version | upgrade_version | plugintype | pluginlocation.
Beispiel serendipity_plugin_archives | ..... | 1.4 | 1.4 | sidebar | local | ... |
Ich weiß nicht warum du da überhaupt die Biene zusätzlich als sidebar plugin hast, vielleicht mal ausprobiert und vergessen?? Oder versteckt? Die Biene gehört wie freetag, staticpage, statistics zu den gekoppelten Plugins, d.h. das sidebar Plugin liegt mit im event plugin Ordner. Ebenso gibt es noch Plugins die zwar einzelne Ordner haben, aber durch eine Abhängigkeit verbunden sind. Trotzdem sollte ein sidebar Plugin in plugintype auch als solches ausgewiesen werden. Insofern würde ich auch die Biene einmal komplett deinstallieren und dann neu installieren. Das sidebar Plugin ist Statistik und (eher) wertlos! (und hält den ganzen Laden auf!) Wir wollen ja die Biene als Schnellfeuerwaffe gegen Spambots.
Dein 2. Kommentar scheint einem Missverständnis aufgesessen zu sein. Feld 2, 3 und 4 (class_name, plugin_class, pluginPath) beschreiben die möglichen Konditionen des eben ausgeführten, sowie noch eine ungenannte weitere. Davon ist zur Erkennung ob es sich tatsächlich um ein Seitenleisten Plugin handelt eigentlich nur class_name wichtig. Zur Erkennung ob es 'local' vorhanden ist, siehe 1. Feld (plugin_file) und 10. Feld pluginlocation. Sehr wahrscheinlich sind die 4 also im class_name eben die Seitenleisten Plugins der gekoppelten event Plugins (in pluginPath) die du irgendwann einmal installiert hattest und "vielleicht" sogar aktiviert, oder versteckt sind, oder deaktiviert aber nicht physikalsch gelöscht sind (was ja angesichts ihres gekoppelten Zustandes auch völlig ok ist).
Beat Post author am |
Ich muss das in mehreren Schritten beantworten. Oder mit Fragen sicherstellen, dass ich keinen Mist baue.
Also:
Beide 1ner, bzw insbesondere sidebarlogo mit 'event' sind falsch. Einmal über Spartacus löschen und Klickprozedur wiederholen. Danach der Gegencheck mit der SQL Anweisung.
"Über Spartakus löschen" meint via Backend/Plugins anklicken und löschen. Richtig?
Sehr dubios ist, dass ich sidebarlogo nie installiert habe. Ich habe demzufolge im Backend keine entsprechende Anzeige des Plugins und kann so dieses nicht löschen. Es gibt auch kein entsprechendes Verzeichnis auf dem Server (per FTP kontrolliert). Da ist gar nichts...
Beat Post author am |
Davon ist zur Erkennung ob es sich tatsächlich um ein Seitenleisten Plugin handelt eigentlich nur class_name wichtig.
Ja, da steht immer serendipity_plugin_....
Bevor ich am Live-Blog herumschraube, lösche ich hier mal die SPAM_Biene und führe die SQL-Abfrage nach der oben beschriebenen Prozedur nocheinmal durch.
Resultat: Im Backend ist das Plugin nicht mehr sichtbar. Die DB-Abfrage zeigt das genau gleiche Resultat wie zuvor. Noch immer wird SPAM-Bee als "plugintype=event" aufgelistet.
Ich lösche jetzt mal noch den Ordner per FTP. -> Keine Änderung. Wird nach erneuter SQL-Abfrage noch immer angezeigt.
Doch, du hast sidebarlogo installiert und wieder gelöscht. Damit ist es local.
Das war als wir auf das Verhalten aufmerksam wurden und ich meinte, man müsse ein Plugin erst installieren (Vorschlag sidebarlogo) um eine Synchronisation auszulösen.
Beat Post author am |
?????
Ian Styx am |
JA, geh/rad ruhig mal an die Luft... Morgen ist ein neuer Tag und dann kannst du etwas weiter herumexperimentieren, denn entrypaging 1.72 ist unterwegs. ? Es wäre doch Schade um all die Mühe!
Beat Post author am |
V1.72 ohne Smarty crasht. Hier, wie auch auf www.beatsblog. ch. Das ist die Fehlermeldung, die angezeigt wird:
Mit Smarty funktioniert das Plugin. Gemessene Ladezeit von https://www.beatsblog.ch/2633-Bleiben-Sie-zuhause!.html
habe deshalb das Plugin auf www.beatsblog.ch wieder deaktiviert.
Ian Styx am |
Ops, entrypaging 1.73 ist online. ?
Was es bzw sein Vorgänger macht, ist im Falle von Smarty AN einen doppelten Durchlauf der Datenbankanfragen zu vermeiden. Es hätte(?) ja sein können das es signifikanten Einfluß hat.
Wenn das durch Tests geklärt ist müssen wr weiter suchen, was diesen idle auslöst. Es gibt noch die Möglichkeit die erweiterten Plugin DB request zu überpüfen auf multilingual, categorytemplates und entryproperties. Oder abzuchecken ob mit der entrycat in relation zur entries Tabelle alles in Ordnung ist, bzw ob es überhaupt an der Schnelligkeit der einzelönen order erweiterten DB Abfragen liegt. Irgend etwas muss den entscheidenden Unterschied ausmachen der zu dieser Wartezeit führt. Wartezeit kann ja auch heißen, das etwas länger dauert, oder hakt, oder zuviel Arbeit hat... jedenfalls könnte es vielleicht interessant sein ob die time Synchronisation richtig läuft (siehe auch history hickups).
Jedenfalls darf das nicht sein und gehört herausgefunden was es auslöst!
Beat Post author am |
V1.73 läuft fehlerfrei. Habe nocheinmal Vergleichsmessungen gemacht (denen ich aber nicht so wirklich traue):
Getestet wurde immer dieser Beitrag: /2532-Abendstimmung.html
Da irritieren mich gleich zwei Dinge: 1. Wieso sollte die Steite auf blog.dokumenzi nur knapp halb so schwer sein? und 2. kein Unterschied auf beatsblog ob mit oder ohne Smarty? Getestet habe ich mit pingdom.com (Messtandort Frankfurt), vielleicht mache ich die gleichen Tests noch mit GTMetrix.com, ganz einfach zum Vergleich
Beat Post author am |
Also hier nochmasls die gleichen Seiten getestet mit GTMetrix.com (Serverstandort Vancouver, Canada):
Getestet wurde immer dieser Beitrag: /2532-Abendstimmung.html
Mal ganz abgesehen von den Loadtimes irritiert mich doch sehr, dass die Seitengrösse in KB oder MB fast Faktor 2 ist zwischen blog.dokumenzi und beatsblog. Ich teste da noch ein paar andere Seiten um herauszufinden, ob das ganz generell so ist. Das würde ja bedeuten, dass hier deutlich stärker komprimiert wird.
Beat Post author am |
Es bestätigt sich, dass hier viel besser/stärker komprimiert wird als auf beatsblog:
Pingdom.com (Serverstandort Frankfurt)
Diese Seiten habe ich ebenfalls mit GTMetrix.com getestet. Die Loadzeiten sind durch den Messstandort Vancouver natürlich deutlich höher, die Seitengrösse und die Requests sind jedoch nahezu identisch.
Ian Styx am |
Ich glaube, dass das nicht aussagekräftig ist, denn es erlaubt keine Messung mit den Browser caches, also derjenigen Request Vorgänge, die nicht erneut geladen werden, weil sie 302 Not Modified etc sind.
Am besten sind Messungen mit Seiten im eigenen Browser - F12 - Netzwerkanalyse - Zeit der Abfrage ganz unten, a la UHR 42 Anfragen 1,20 MB / 157,48 KB übertragen Beendet: 2,07 s DOMContentLoaded: 708 ms load: 1,37 s
Wenn du Webmessungen wie die genannten durchführst, muss man sich nicht wundern, dass Saarland -> Vancouver länger dauert als Saarland -> Frankfurt und dann noch in diesen Zeiten. ?
Mit jeder Messung verändern sich auch beispielsweise die Seitenleistenbilder etc. die das Bild weiter verzerren.
Um zu verstehen, schaut man in die "Übertragen" Spalte und sieht was "Aus (dem) Cache" geladen wird. Für die (raced) Angaben siehe: "https://support.mozilla.org/en-US/questions/1267945". Das war mir auch neu! Also wieder was dazugelernt! ?
Beat Post author am |
Ich will Deinen Tatendrang keinesfalls bremsen, doch aus meiner Sicht dürfte das ein ziemlich schwieriges Unterfangen werden. In dieser Installation verursacht das Plugin ja keinerlei (signifikante) Verzögerungen. Ich glaube eher, dass es auf Manitu-Seite eine irgendwie unglückliche Konstellation antrifft. Sei es PHP oder DB oder was sonst noch so mitspielt (Caching, Kompression, etc.).
Beat Post author am |
So zum Spass habe ich das ganze APCU-Zeugs wieder in die .htaccess von www.beatsblog.ch gekippt. Nun sind die Seitengrössen in KB vergleichbar mit hier (wo dieses APCU-Zeugs nicht vorhanden ist, jedoch nginx noch irgendwie mitspielt).
Die Seitenladezeiten sind nun hier wie dort etwas gleich schnell. Der Unterschied ist jedoch, dass hier das entrypaging-Plugin aktiv ist und auf www.beatsblog.ch nicht. Wenn ich das dort aktiviere, verlängert sich die Ladezeit einer Single-Entry-Page sofort um 1-2 Sekunden.
Ian Styx am |
Kann sein..., aber es kann auch sein, dass es irgendeine Art von Abhängigkeit ist, die das auslöst. Ich hätte da möglicherweise in Verdacht etwaige Unstimmigkeiten in der Art wie du das Blog upgedated und mit den alten Datenn gefüttert hast, Vielleicht stimmen irgendwelche Verknüpfungen zwischen Datenbanktabellen (über die inkrementellen IDs) nicht mehr... und führen zu "nachdenklichen" Denkpausen ??? ?
Ian Styx am |
Hört sich gut an! Und - Beat - 1-2s ist doch schon sehr viel besser als 4.5s, oder?
Macht doch mal ein Beispiel dafür, vielleicht braucht jemand anderes auch so ein Spielzeug.
Apropos Spielzeug,
Ich habe gestern und heute an der (Spartacus) Plugin Synchronsation geflickt und glaube, dass das dringend mal ausprobiert werden sollte! ?
Beat Post author am |
Ausprobieren klingt gut. Habe soeben die neusten Styx-Dateien aufgespielt (vollständig). Was kann ich denn jetzt ausprobieren?
Beat Post author am |
Mach mir keine Angst! Mein letzter SQL-Backup der usrprünglichen Original-S9Y-DB datiert vom 05.09.2019... Natürlich könnte ich immer noch die DB des noch bestehenden Blogs auf www.bbbeat.ch sichern, doch auch diese Daten enden am 16.01.2020....
Ian Styx am |
Einmal auf "Seitenleisten-Plugins installieren" klicken (das reicht schon) und danach einmal nach "Plugins updaten" checken.
Jetzt sollten alle locationtype = 'local' sidebar plugins korrekt als sidebar plugins ausgezeichnet sein und alle in version und upgrade_version gleichermaßen bestückt sein, wenn kein sidebar update in der Warteschlange vorliegt.
PhpMyAdmin SQL Tab;
Ian Styx am |
Soll es auch nicht! ?
Es ist auch nur eine der Möglichkeiten um weiter im Nebel zu stochern. Wenn man ein älteres Blog hat, ist es in der Historie ja sicher durchaus öfter mal vorgekommen, dass man Einträge oder Bilder oder Kategorien oder dergleichen gelöscht hat. Das hinterläßt Löcher in der DB, da der inkrementelle Counter stur immer weiter zählt. Die Tabellen die davon abhängen sind darauf angewiesen etc. Je nachdem wie man nun die alte DB exportiert/importiert und/oder anderweitige Synchronisatiionen laufen (images, plugins beispielsweise), kann so eine andere (zu)Ordnung entstehen, als diejenge, auf denen sich ältere Tabellen berufen. Du verstehst? Ohne das exakt nachzustellen ist es natürlich nur eine ziemlich blinde Vermutung und vielleicht auch nur völliger Blödsinn.
Beat Post author am |
O.K.
Hier (bog.dokumenzi.ch) zeigt die SQL-Abfrage insgesamt 16 Einträge an. Davon 15 "sidebar" und 1 "event" (=spamblock_bee)
Auf www.beatsblog.ch zeigt die SQL-Abfrage insgesamt 21 Einträge an. Davon 20 "sidebar" und 1 "event" (sidebarlogo)
Also ich werde daraus nicht sonderlich schlau, doch vielleicht hilft es Dir ja.
Beat Post author am |
Hmmm.. Wenn ich mir die 21 Einträge auf www.beatsblog.ch genauer ansehe, erscheinen als "sidebar" ausgezeichnet z.B.:
Kann ja sein, denn diese Plugins können auch in der Seitenleiste aktiv sein (soviel ich weiss). Komisch finde ich einfach die unterschiedliche Anzahl.
Ian Styx am |
Beide 1ner, bzw insbesondere sidebarlogo mit 'event' sind falsch. Einmal über Spartacus löschen und Klickprozedur wiederholen. Danach der Gegencheck mit der SQL Anweisung.
Es geht um die 4 nebeneinanderliegenden Felder 7,8,9,10: version | upgrade_version | plugintype | pluginlocation.
Beispiel serendipity_plugin_archives | ..... | 1.4 | 1.4 | sidebar | local | ... |
Ich weiß nicht warum du da überhaupt die Biene zusätzlich als sidebar plugin hast, vielleicht mal ausprobiert und vergessen?? Oder versteckt? Die Biene gehört wie freetag, staticpage, statistics zu den gekoppelten Plugins, d.h. das sidebar Plugin liegt mit im event plugin Ordner. Ebenso gibt es noch Plugins die zwar einzelne Ordner haben, aber durch eine Abhängigkeit verbunden sind. Trotzdem sollte ein sidebar Plugin in plugintype auch als solches ausgewiesen werden. Insofern würde ich auch die Biene einmal komplett deinstallieren und dann neu installieren. Das sidebar Plugin ist Statistik und (eher) wertlos! (und hält den ganzen Laden auf!) Wir wollen ja die Biene als Schnellfeuerwaffe gegen Spambots.
Dein 2. Kommentar scheint einem Missverständnis aufgesessen zu sein. Feld 2, 3 und 4 (class_name, plugin_class, pluginPath) beschreiben die möglichen Konditionen des eben ausgeführten, sowie noch eine ungenannte weitere. Davon ist zur Erkennung ob es sich tatsächlich um ein Seitenleisten Plugin handelt eigentlich nur class_name wichtig. Zur Erkennung ob es 'local' vorhanden ist, siehe 1. Feld (plugin_file) und 10. Feld pluginlocation. Sehr wahrscheinlich sind die 4 also im class_name eben die Seitenleisten Plugins der gekoppelten event Plugins (in pluginPath) die du irgendwann einmal installiert hattest und "vielleicht" sogar aktiviert, oder versteckt sind, oder deaktiviert aber nicht physikalsch gelöscht sind (was ja angesichts ihres gekoppelten Zustandes auch völlig ok ist).
Beat Post author am |
Ich muss das in mehreren Schritten beantworten. Oder mit Fragen sicherstellen, dass ich keinen Mist baue.
Also:
"Über Spartakus löschen" meint via Backend/Plugins anklicken und löschen. Richtig?
Sehr dubios ist, dass ich sidebarlogo nie installiert habe. Ich habe demzufolge im Backend keine entsprechende Anzeige des Plugins und kann so dieses nicht löschen. Es gibt auch kein entsprechendes Verzeichnis auf dem Server (per FTP kontrolliert). Da ist gar nichts...
Beat Post author am |
Ja, da steht immer serendipity_plugin_....
Bevor ich am Live-Blog herumschraube, lösche ich hier mal die SPAM_Biene und führe die SQL-Abfrage nach der oben beschriebenen Prozedur nocheinmal durch.
Beat Post author am |
SPAM_Biene über Backend/Plugins/Ereignis-Plugins gelöscht. Backend-Refresh. Plugins/Seitenleisten-Plugins installieren klicken. Backend-Refresh. Plugins/Plugins updaten klicken. Backend-Refresh.
Resultat: Im Backend ist das Plugin nicht mehr sichtbar. Die DB-Abfrage zeigt das genau gleiche Resultat wie zuvor. Noch immer wird SPAM-Bee als "plugintype=event" aufgelistet.
Ich lösche jetzt mal noch den Ordner per FTP. -> Keine Änderung. Wird nach erneuter SQL-Abfrage noch immer angezeigt.
Ian Styx am |
?
Ian Styx am |
Doch, du hast sidebarlogo installiert und wieder gelöscht. Damit ist es local.
Das war als wir auf das Verhalten aufmerksam wurden und ich meinte, man müsse ein Plugin erst installieren (Vorschlag sidebarlogo) um eine Synchronisation auszulösen.