Kommentare von

beats TEST blog

Weblog Kommentare

DER Zeitfresser

Ian Styx am |

Ich ahnte sowas... ? Aber damit bist du bestimmt nicht alleine!
Mir war auch so das dein Migrationsvorgehen das schon berücksichtigt hatte, wollte das aber nur noch mal bestätigt haben. (Eventwrapper ist ja auch ein core Plugin)

Ian Styx am |

Genau. Gut ich werde also zur Sicherheit noch einen Gegencheck einbauen ob das Plugin nicht doch bereits installiert ist. Und erst dann musst du nur noch die upgrade_version von Hand einmal nachtragen. Wobei mir noch nicht klar ist warum die Biene nicht ordentlich eingetragen ist. Hast du die auch mal per Hand upgedated? Oder nach der Migration mal installiert und deinstalliert .. ja ich weiß schon ... ein mildes Lächeln reicht ;-) .. Und warum ist die Ordnung so unterschiedlich .. , (wahrscheinlich weil es nicht synchronisiert wurde), also du siehst: Fragen über Fragen...

Beat Post author am |

Wobei mir noch nicht klar ist warum die Biene nicht ordentlich eingetragen ist. Hast du die auch mal per Hand upgedated? Oder nach der Migration mal installiert und deinstalliert ..

Das ist zum Glück noch nicht lange her, so dass ich mich wirklich noch erinnern kann. ?

Am letzten Dienstag, 24.03., habe ich nach diesem Kommentar (https://www.blog.dokumenzi.ch/2634-DER-Zeitfresser.html#c6645) die Biene zuerst via Spartacus und dann auch per FTP glöscht und danach neu installiert.

Ein Update der Biene gab es (meines Wissens) seit dem Blogaufbau (06.12.2019) noch nie.

Auf www.beatsblog.ch ist das Biene-Plugin-Verzeichnis vom 24.01.2020, also von der Neuerstellung des Blogs. Deshalb behaupte ich jetzt einfach mal, dass ich dort nie geupdatet oder gelöscht und neu installiert habe.

Ian Styx am |

Nun denn - ich hätte selbst drauf kommen können. ?

Maintenance hat gerade ein Update mit dem Sicherheitscheck bekommen. Wenn du das upgedated hast, lass uns mal sehen was der Zombie Plugin Manager jetzt hier ausgibt.

Beat Post author am |

Habe nun alle Styx-Installationen upgedatet. Auf www.blog.dokumenzi.ch sagt der Plugin-Altlastenmanager: Nothing to do

Diese Abfrage

SELECT class_name,version,upgrade_version,plugintype,pluginlocation FROM `styx_pluginlist` WHERE class_name LIKE '%spamblock_bee'

zeigt nun:

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

und diese Abfrage

SELECT class_name, version, upgrade_version, plugintype FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local'

zeigt nun:

class_name	version	upgrade_version	plugintype 	
serendipity_plugin_authors 	2.4 	2.4 	sidebar
serendipity_plugin_calendar 	1.4 	1.4 	sidebar
serendipity_plugin_entrylinks 	1.04 	1.04 	sidebar
serendipity_plugin_history 	1.23 	1.23 	sidebar
serendipity_plugin_html_nugget 	1.4 	1.4 	sidebar
serendipity_plugin_imagesidebar 	1.20 	1.20 	sidebar
serendipity_plugin_plug 	1.4 	1.4 	sidebar
serendipity_plugin_quicksearch 	1.3 	1.3 	sidebar
serendipity_plugin_remoterss 	1.26 	1.26 	sidebar
serendipity_plugin_spamblock_bee 	1.3.7 	1.3.7 	sidebar
serendipity_plugin_staticpage 	1.31 	1.31 	sidebar
serendipity_plugin_superuser 	1.1 	1.1 	sidebar
serendipity_plugin_freetag 	3.12 	3.12 	sidebar
serendipity_plugin_statistics 	1.7 	1.7 	sidebar
serendipity_plugin_archives 	1.4 	1.4 	sidebar
serendipity_plugin_categories 	2.15 	2.15 	sidebar
serendipity_plugin_comments 	1.19 	1.19 	sidebar
serendipity_plugin_eventwrapper 	1.1 	1.1 	sidebar
serendipity_plugin_recententries 	2.6 	2.6 	sidebar
serendipity_plugin_syndication 	2.7 	2.7 	sidebar

auch auf www.beatsblog.ch sagt nach dem Datenupdate und Plugin-Klick-Rundkurs der Plugin-Altlastenmanager: Nothing to do.

Hier noch die SQL-Abfrage-Resultate von 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
class_name	version	upgrade_version	plugintype 	
serendipity_plugin_archives 	1.4 	1.4 	sidebar
serendipity_plugin_authors 	2.4 	2.4 	sidebar
serendipity_plugin_calendar 	1.4 	1.4 	sidebar
serendipity_plugin_categories 	2.15 	2.15 	sidebar
serendipity_plugin_comments 	1.19 	1.19 	sidebar
serendipity_plugin_entrylinks 	1.04 	1.04 	sidebar
serendipity_plugin_eventwrapper 	1.1 	1.1 	sidebar
serendipity_plugin_freetag 	3.12 	3.12 	sidebar
serendipity_plugin_history 	1.23 	1.23 	sidebar
serendipity_plugin_html_nugget 	1.4 	1.4 	sidebar
serendipity_plugin_plug 	1.4 	1.4 	sidebar
serendipity_plugin_quicksearch 	1.3 	1.3 	sidebar
serendipity_plugin_recententries 	2.6 	2.6 	sidebar
serendipity_plugin_remoterss 	1.26 	1.26 	sidebar
serendipity_plugin_spamblock_bee 	1.3.7 	1.3.7 	sidebar
serendipity_plugin_staticpage 	1.31 	1.31 	sidebar
serendipity_plugin_statistics 	1.7 	1.7 	sidebar
serendipity_plugin_superuser 	1.1 	1.1 	sidebar
serendipity_plugin_syndication 	2.7 	2.7 	sidebar
serendipity_plugin_imagesidebar 	1.20 	1.20 	sidebar

Vermutlich ist das nicht das Ergebnis, welches Du Dir vorgestellt hast...

Ian Styx am |

Doch genau! Wie kommst du darauf?

Es ging ja nur um den Altlastenmanager und um blog.doku.
( Siehe: https://www.blog.dokumenzi.ch/2634-DER-Zeitfresser.html#c6682 )

Beat Post author am |

O.K. Wenn Du zufrieden bist, dann bin ich es auch. ?

Ian Styx am |

Die Frage war ja eher, ob du darin irgend etwas siehst was jetzt anders wäre, außer das "Nothing to do"?

Jertzt musst du nur noch per Hand den 2. richtigen Satz aus #c6682 in die upgrade_version eintragen.

1.73 bei event_entrypaging local
1.3.7 bei event_spamblock_bee local

 Und NICHT verwechseln und NUR hier! ?

Ian Styx am |

Eben gerade habe ich nochmal ein wenig über entrypaging gebrütet und da kam mir eine wage Idee. Was ist, wenn dieses Verhalten (irgendwie) mit der fehlenden Category ID zusammenhängen könnte...?! Ich glaube so irgendwie gar nicht daran, dass es etwas speziell geisterhaft Manitu-haftes geben kann was das auslöst.

Beat Post author am |

Wir müssen aufpassen, dass wir nicht aneinander vorbei reden. Respektive, ich habe schon länger den Anschluss verloren, weshalb und wozu das alles gut ist. Ich versuche Deine Anweisungen einfach möglichst genau umzusetzen. Leider kann ich einzelne Datensätze aus der DB-Tabelle "Styx_pluginlist" nicht bearbeiten. Ich erhalte in phpMyAdmin folgende Mitteilung, wenn ich auf die Tabelle klicke:

Die aktuelle Markierung enthält keine eindeutige („unique“) Spalte. Gitter-Bearbeitungsfunktion, Kontrollkästchen, Bearbeiten, Kopieren und Löschen von Links sind nicht verfügbar.

 

Beat Post author am |

Könnte sein, ABER: Die fehlenden category-IDs sind hier wie dort gleich. Es könnte gemäss dieser Logik auch daran liegen, dass ich aus der Permalink-Struktur für die Artikel-URLs das /archives gelöscht habe und das Plugin danach sucht...

Ian Styx am |

Ja leider ein "Sicherheitsfeature" ab PhpMyAdmin 4.5, siehe
https://github.com/ophian/styx/blob/83df7f5956330449576eb68452555504a67302af/docs/NEWS#L2996

Wenn du die Einstellung nicht selber setzen kannst, dann hillft nur noch eine handgefertigte Query

UPDATE `styx_pluginlist` SET upgrade_version = '1.3.7' WHERE class_name = 'serendipity_event_spamblock_bee' AND pluginlocation = 'local'
UPDATE `styx_pluginlist` SET upgrade_version = '1.73' WHERE class_name = 'serendipity_event_entrypaging' AND pluginlocation = 'local'

 

Ian Styx am |

Ja, so meinte ich das ... wie man das wirklich aussagekräftig evaluieren kann ist halt ne Frage.

Beat Post author am |

Das Problem ist halt, dass ich das nicht so einfach rückgängig und in den Originalzustand versetzen kann. Alle Links in Beiträgen müssten überprüft und entsprechend umgeschrieben werden... ?

Beat Post author am |

? Habe die zwei Befehle abgesetzt und danach mittels einer Abfrage überprüft. Passt! "local"- upgrade_version ist jetzt überall gesetzt.

Nun sieht es hier und auf www.beatsblog.ch identisch aus.

Ian Styx am |

Prima! Ich hatte schon Sorge dass ich mich vielleicht verwirrt hätte.. ?

Ian Styx am |

Ich musste nochmals nachbessern, da unter Umständen bereits gesetzte Pluginlist Einträge wieder überschrieben wurden und ich dies ein paar Tage beobachten musste. Jetzt aber klappt es. Poch Poch! ?
Ich habe das dann gleich zum Anlass genommen ein Bugifix release für den Styx 2.9 branch herauszugeben.

Beat Post author am |

:wave: Habe die neusten Daten auf allen 4 Installationen aufgespielt. Danke für den Update-Hinweis! ?

Im Styx-Blog ist mir eine Kleinigkeit aufgefallen. Die neuste Mitteilung solltest Du 2020/2 nennen, weil 2020/1 bereits an Serendipity Styx 2.9.3 release vergeben wurde.

Und a propos 4 Installationen: Braucht es www.styx.dokumenzi.ch noch? Ausser updaten mache ich da schon länger gar nichts mehr. Wenn Du mir Dein o.k. gibst, würde ich diese Installation und die Sub-Domaine löschen.

Ian Styx am |

Oh wie wahr. Danke! Gefixt. ?

Ja, kann wechhhh! Danke für die live Ansichten.

Ian Styx am |

Nochmal zum "Zeitfresser" ...  Blogs mit wenig bzw keinen zugeschalteten Extras wie Sidebar Comment, Mediatheks und History Abfragen usw. und keinen bis sehr reduziert ablaufenden event hooks usw. sind natürlich an sich schon schnell genug und können sich locker im 30-50 ms Bereich der Content-Zusammenstellung bewegen.

Hier - bei einem anderen Anbieter - ist, finde ich, schön und nachvollziehbar erklärt, warum der, dem Apachen vorgeschaltete, Nginx cache auf hostech so schön schnell ausliefern kann. Laut Chrome sind es auf Eintrags-Einzelseiten unter ~500ms gegenüber ~2,0s auf Manitu, also nur ein Viertel. Er reduziert die Warteschleife der Zusammenstellung durch einen vorgehaltenen Cache. Vielleicht kann man ja Manitu dafür begeistern lernen. (Und damit ist, nur zu Feststellung, nicht der Varnish Cache gemeint, der viele Probleme mitbringt und m.E. nicht zu empfehlen ist.)

https://www.hosteurope.de/faq/webserver-dedicated/allgemeines-webserver/nginx-cache/

Need for Speed

Beat Post author am |

Muss mir echt überlegen, wie ich da sinnvoll vorgehe um den "Zeitfresser" zu finden.

Beat Post author am |

Habe soeben festgestellt, dass bei der Testinstallation die Indexseiten über 4 Sekunden zum Aufbau brauchen. Komisch. Das Verhalten ist auf www.styx.beatsblog.ch genau umgekehrt wie auf www.beatsblog.ch

Wobei... das liegt wohl daran, dass keine Bilder gefunden werden. Als nächstes kopiere ich mal den /uploads/2020-Ordner und teste erneut.

Ja, es waren die fehlenden Bilder. Nun baut die Indexseite in ca. 0,5sec. auf.

Ian Styx am |

Wahnsinn! Sehr gute Idee!
Du kannst also entweder auf dem realen Blog alles einzeln abschalten (insbesondere die Plugins) und dann jeweils en Detail überprüfen oder auf dem testblog alles einzeln dazuschalten, so wie du es jetzt mit den Bildern gemacht hast, und dann en Detail überprüfen. Bis jetzt sieht das ja echt gut aus, bis darauf, dass dir nl2br irgendwie hinein funkt..

Tja, wer steht da wohl auf der Bremse...!?!?

Beat Post author am |

Ich schraube nur sehr, sehr ungern am Live-Blog herum. Dafür baue ich ja Test-Installationen auf.? Deshalb werde ich also die neue styx.beatsblog.ch-Installation erweitern und immer wieder testen (Fortschritte siehe Erweiterter Beitrag).

Ganz ehrlich: Ich hoffte, dass der Fehler bei Manitu liegt und nicht bei mir (eigentlich wollte ich ihn reproduzieren). Nun muss ich X Stunden investieren um "dem Fehler" auf die Schliche zu kommen. Und wie es Murphy so will, werde ich vermutlich erst ganz zum Schluss die Lösung des Rätsels finden... und wie schon öfters erwähnt: Ich mag keine Rätsel und Knobeleien... ?