Kommentare von

beats TEST blog

+1 Std. Zeitversatz

Ian Styx am |

Aber id 2580 ist am 16. Januar 2020, war das nicht eher im Herbst irgendwann? Oder lag das an den wiederholten Versuchen mit mb4?
Schon kapiert, du hast Recht, wir haben ja noch auf styx.dokumenzi (vorher) verhandelt... ?

Bin ja mal gespannt was das für eine Einfluss auf das History Problem, oder vielleicht sogar entrypaging hat oder nimmt.

Beat Post author am |

Der DB-Import bei www.beatsblog.ch erfolgte zwischen dem 22. und 28. Januar 2020. Auf den Tag genau weiss ich das nicht mehr. Ich weiss aber, dass #2580 (vom 16.01.2020) der letzte exportierte Beitrag war. Weil auf www.bbeat.ch wurde später nur noch der "Dieses Weblog ist umgezogen!"-Beitrag geschrieben. Und von dort stammen die Daten.

Übrigens: Ich habe nur die DB von www.beatsblog.ch verändert. Hier (www.blog.dokumenzi.ch) lasse ich es so wie es ist.

Ian Styx am |

Gibt es dafür einen wesentlichen Grund?

Beat Post author am |

Wofür? Dass ich die DB hier nicht ändere? -> Ist mir zuwenig wichtig.

Falls Du denkst, dass es für weitere Tests hier von Belang ist, dann kann ich das schon noch durchführen. Es ist halt einfach so, dass ich auf www.beatsblog.ch auch sonst noch Beitragsänderungen durchgeführt habe, die sich hier nicht widerspiegeln.

alle Blog-Bilder des Jahres 2019

Ian Styx am |

Huch... ist denn schon Neujahr..?

Sie sind ein Witzbold, mein Herr ⛄

Hmmm... Die Galeriefunktion scheint auf 48 Bilder pro Galerie beschränkt zu sein.

Das scheint nicht nur so ... sondern ist auch so!  Steht groß in der zugehörigen Erklärbox.
Warum, kannst du dir nun sicher denken..! ☺

Aber wie man sieht, man kann für jede Restriktion eine entsprechende Umgehung finden. Man muss das aber ja nicht nur einmal im Jahr machen und damit vielleicht alle überfordern, sondern kann das ja in Themen aufteilen, oder vierteljählich rückblicken, oder oder. Nicht wahr?!

Beat Post author am |

Du bist zu früh mit kommentieren. ? Bin noch in der Findungsphase... ?

Beat Post author am |

Warum, kannst du dir nun sicher denken..! ☺

Nein, kann ich nicht. Also: Warum?

Ian Styx am |

Ja, ..habe ich schon gemerkt...! ?

Rein technisch kannst du also zwei 48iger Galerien auch miteinander verknüpfen, in dem du im Qellcode das letzte end-div aus der ersten Galerie entfernst und das startende div der zweiten ebenso. Und schwupps hast du 96. etc.

Nur muss man die Kapazitäten des eigenen Servers und die der Besucher PCs/Geräte nicht überschätzen. Schon deshalb hielt ich es für eine geeignete Idee so eine Begrenzung einzuführen. Selbst mit den optimierten webp Dateien. Für mehrere tausend ist das sowieso nicht geeignet und sollte vielleicht besser in eine dafür optimierte Galerie verlinkt werden.

Ian Styx am |

Pro Bild ca 50Kb x 48 mit ein bisschen Spirenzchen macht locker 2,5 Megabyte, Und das nur in einem Artikel unabhängig vom Load der ganzen Seite.

Beat Post author am |

Ich verstehe, was Du meinst. Wenn ich diesen Beitrag hier (mit 113 Bildern) via pingdom.com teste, sieht das im Moment so aus:

  • Performance grade: C 79
  • Page size: 4.4 MB
  • Load time: 982 ms
  • Requests: 148

Find ich jetzt nicht erschreckend... Aber Du hast schon recht. Vielleicht sollte ich die Idee besser mit einer JAlbum-Galerie lösen. Ich fands halt einfach schön, dass man sofort alle Bilder sieht. Ich fühle mich davon auch nicht überfordert.

(Phua! Ist diese Server-Umgebung SCHNELL! Auf www.beatsblog.ch braucht ein einzelner Beitrag immer noch so um die 2 Sekunden).

Aber ja, ich überlege noch weiter...

Ian Styx am |

Ja das ist durchaus mal zumutbar, vor allem wenn man sich dabei auf den erweiterten Entrag beschränkt und die entrypaging Geschichte mal außen vor läßt.

Ich muss als Entwickler eben nur mehr Fälle bedenken und zu vermeiden suchen, den Eindruck zu erwecken, man könne hier mal eben so ein Foto Blog hochziehen weil die Möglichkeiten unbegrenzt sind. Es ist ja nicht nur die Auslieferung, sondern auch die Vorhaltung in der Mediathek und die Zusammenstellung für den Beitrag, die eine Rolle spielen. Für eventuelle Optimierungen oder Änderungen bräuchte ich echt mehr fundierte Meinungen und Szenarien.

Ian Styx am |

Ich will aber natürlich auch nicht den Eindruck erwecken, man solle sie alldieweil überhaupt nicht nutzen ... denn natürlich freue ich mich wenn sie benützt wird, weil sie einen echten Mehrwert bietet, schön aussieht. sich exzellent verhält usw. - ja, dafür habe ich sie gebaut - nur (eben) mit Bedacht und im Maße. ?

Dann ist alles GUT!

Schönen ersten Mai. ?

Beat Post author am |

Muss mir das noch einmal überlegen... Wen (ausser mir) so eine Galerie überhaupt interessieren könnte, ob sich der Aufwand lohnt,...

Nach "einmal drüber schlafen" bin ich von der Jahres-Galerie-Idee nicht mehr so überzeugt. Aktuell denke ich, dass man so oder so nicht verhindern kann, dass Bilder in Vergessenheit geraten. Und wie angesprochen, ist eine Darstellung von über 100 Bildern in einem Blogeintrag auch icht mehr übersichtlich.

Die Idee tauchte ja im Zusammenhang mit dem Seitenleisten-Plugin "Drei Zufallsbilder" auf. Vielleicht erweitere ich diese auch einfach mal auf fünf Bilder... :think:

Ian Styx am |

Ähem .... das ist ja nur ein Gimmick - das im Übrigen viel Leistung zieht.
Ich würde persönlich eher auf eine gecachte Lösung setzen, bei der sidebar, also weg von dynamischen Requests. Zum Beispiel ein Bild der Woche oder so; und/oder vielleicht ergänzen durch einen monatlichen Blogbeitrag mit den 12-24 schönsten Bildern. Andererseits hast du ja immer Bildeinträge in deinen Entries. So könnte man weekly oder monthly summaries schreiben und mit kleinen Galerien aufpeppen...

Beat Post author am |

Ähem .... das ist ja nur ein Gimmick - das im Übrigen viel Leistung zieht.

Jetzt tust Du diesem Plugin aber unrecht! Ich finde das so wertvoll, wie das History-Plugin darüber. Die Funktionalität (bei jedem Refresh neue Bilder, Verlinkung von Bild zu Artikel) gefällt mir wirklich sehr gut. Von mir aus könnte man das Plugin von allen Zusatzfunktionen (andere Quellen, hotlinked items, eigene styles, etc.) befreien um es etwas zu verschlanken. Aber ansonsten: Top! Für mich ist das mehr als nur ein Gimmick.

Zu den anderen gecachten/statischen Ideen denke ich: Eher Nein. Ist mir zuviel Aufwand. Aufgrund der Galerie-Restriktionen dachte ich mal über Quartalsbeiträge nach, doch schon das ist mir zu aufwendig. Deshalb hatte ich zu Beginn Jahresbeiträge im Fokus.

Auf www.beatsblog.ch lasse ich von jetzt an mal 5 Bilder über das Seitenleisten-Plugin anzeigen. Das Thema ist für mich noch nicht abgeschlossen, doch ich muss erst mal herausfinden (spüren), was ich wirklich will...

Ian Styx am |

Nicht das wir uns mißverstehen, ich mag sie auch - (in Maßen). ? Sie ziehen halt einfach Leistung; das war es was ich sagen wollte.

Ich finde, dass auf beatsblog die Einzeleinträge jetzt doch schon ziemlich flott laden, obwohl ja das entrypaging aktiv ist. Dabei fiel mir ein, dass ich neulich Nacht darüber nachgedacht habe, ob es (der delay) nicht auch eine Frage der Position des Plugin (in der Pluginliste) sein könnte. Je weiter oben, desto besser, würde ich sagen. Hatten wir darüber schon mal nachgedacht und es auf Validität überprüft?

Beat Post author am |

Nein, darüber haben wir noch nicht nachgedacht. Ich habe das Plugin nun mal an 3. Stelle, direkt nach den zwei Anti-SPAM-Plugins plaziert. Eine erste Messung brachte aber nur einen marginalen Unterschied zu Tage, welcher auch auf anderes zurückzuführen sein könnte.

Meine Laienmeinung ist ja immer noch: Wenn es hier (hosttech) schnell geht und dort (manitu) eben nicht, dann liegt es an der Infrastruktur. Da hier nginx cacht, dachte ich, dass ich auf www.beatsblog.ch mal den "experimental" Cache einschalte um zu sehen, ob das etwas bringt. Leider funktioniert der Blog dann nicht mehr und ich erhalte folgende Fehlermeldung:


Fatal error: Uncaught TypeError: Argument 3 passed to voku\cache\AdapterOpCache::setExpired() must be of the type int, string given, called in /home/sites/site100015826/web/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/Cache.php on line 503 and defined in /home/sites/site100015826/web/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/AdapterOpCache.php:83 Stack trace: #0 /home/sites/site100015826/web/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/Cache.php(503): voku\cache\AdapterOpCache->setExpired() #1 /home/sites/site100015826/web/styx-master/include/functions.inc.php(1522): voku\cache\Cache->setItem() #2 /home/sites/site100015826/web/styx-master/include/functions_entries.inc.php(518): serendipity_cacheItem() #3 /home/sites/site100015826/web/styx-master/include/genpage.inc.php(143): serendipity_fetchEntries() #4 /home/sites/site100015826/web/styx-master/include/functions_routing.inc.php(19): include('/home/sites/sit...') #5 /home/sites/site100015826/web/styx-master/index.php(113): serveIn in /home/sites/site100015826/web/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/AdapterOpCache.php on line 83

 

Ian Styx am |

Immerhin hast du dadurch einen Fehler aufgespürt! ;-)

Ich habe ein Update der lib gemacht und den Fehler dann noch mal per Hand einzeln hoffentlich erschlagen.

Ich würde sagen, der Nutzen dieses experimentellen Caches ist zweifelhaft, insbesondere für das genannte Problem. Dieser Cache soll ja Datenbankanfragen cachen. Das macht aber gerade da überhaupt keinen Sinn, wo jeder Folgerequest eine veränderte Datenbankquery benötigt. Das läßt sich so nicht cachen, außer innerhalb der Datenbank selbst, was sowieso und schon viel besser erledigt wird.

Ich würde jetzt mit einem Gesamtupdate von 3.0 auf mein bald folgendes (beta/rc) Release warten, vielleicht so um den 10-12. Mai herum.

Zur Infrastruktur ... ist es doch eben so, dass so viel anderes überall wo bisher getestet nicht läuft, bis auf NGINX auf dokumenzi (das über so eine Art proxy cache verfügt) und wahrscheinlich nur deshalb so viel schneller ist, weil es alle Kombinationen von Request Anfragen im Cache irgendwie vorhält. Ansonsten haben wir überall halbwegs aktuelle MariaDB Installationen und als einzigen Unterschied die verschiedenen Traces zum und vom Server. Das kann, wenn nicht vieles im Argen liegt, keine solch signifikanten Unterschiede ausmachen. Vielleicht ist es eben so, dass keine der anderen Testszenarios die ich benutzen kann, über ein solche Historie von Einträgen verfügt und diese eben doch eine Rolle spielen.

Allgemein: Migration S9Y zu Styx Edition

Ian Styx am |

Wie hast Du denn das gemacht? ?

Spaß beiseite. Das ganze ist ein (nicht enden wollender) Prozeß. Damals musste ich einen Weg finden mit den damaligen Mitteln. Das wurde dokumentiert und zu einem gewissen Zeitraum sogar noch einmal nachgearbeitet.

Doch Styx und S9y(origin) haben sich seitdem verändert und gehen auch unterschiedliche Wege. Ich kann leider nicht jede gut oder schlecht gemachte Änderung in Origin ständig auf potentielle flaws für den Styx upgrade Prozeß checken. Dazu hat sich Styx zu sehr weiterentwickelt. Und nicht zu vergessen ebenso die PHP Entwicklung der letzten 10 Jahre.

Am saubersten ist es immer neu anzufangen und gegebenenfalls Teile rückzuportieren, so wie du es gemacht hast.
Die erwähnte Serendipity (Datenbank) Import Methode entstammt alten und einfacheren Zeiten und sie entbindet einen nicht für die physische Transformation anderer Teile selber zu sorgen. Wieweit diese Methode zB. mit der mysql Transformation nach utf8mb4 zusammenarbeitet vermag ich momentan nicht zu sagen. Außerdem sagt sie: This is NOT an importer meant for upgrading Serendipity. This importer assumes that both Serendipity installations use the same version.

Allerdings habe ich gerade in den letzten Tagen im Zuge der letzten Arbeiten für das 3.0-beta/rc release durchaus von verschiedenen älteren Versionen gerade aus der Serendipity 1.x Serie upgegraded. Dazu fand ich ein paar Bugs, die mit der 3.0-beta bzw mit der nächsten stable 2.9.5 korrigiert werden.

Es ist also durchaus möglich einfach ein Styx (2.9.5) release auf sein altes Origin Blog zu entzippen und aufmerksam dem Upgrade Prozeß zu folgen. Das heißt, man muss verstehen lernen, was die einzelnen upgrade tasks bedeuten und im System vollziehen und warum manches danach anders funktioniert oder mit alten Vorhaltungen sogar zu Fehlern führt. Templates und Plugins sind da eine sehr beliebte Fehlerquelle. Je ungepflegter, desto mehr!
In dem von dir verwiesenen "The important Upgraders HowTo - Step by Step Guide" geht es hauptsächlich um die (halb-) automatische autoupdate Methode.

Ich muss immer sagen, wer seine 1.x Version bisher nicht upgedatet hat, der kann nicht unbedingt erwarten, dass alles ohne einen Fehler und entsprechend persönlichen Einsatz beim (Hammel) Sprung funktioniert.

So ein großes Upgrade über Serien hinweg kann also schon vor der Anzeige der Upgrade tasks zu fatalen Fehlern führen (gerade was uralte Plugins oder bestimmte PHP Versionen angeht), so dass man per Hand diese alten Plugins entfernen, oder, sofern installiert und in Gebrauch, per Hand einzeln physikalisch updaten muss. (Die Fehlermeldungen sind allerdings für den Laien nicht immer wirklich aussagekräftig, so dass oft nur ein Profi weiß, dass beispielsweise manche Smarty Meldungen nicht auf einen Fehler in Smarty, sondern auf ein templates/ config.inc.php Problem, oder ein bestimmtes theme/template file, oder auf ein Plugin zurückzuführen sind.) Aber es geht und wie gesagt mit der Styx 2.9.5 - also 2.9 Series - umso besser! Je weiter sich S9y origin von der damaligen 2.1-alpha1 nach aufwärts entfernt, desto weniger greifen upgrade tasks und Restbestände verbleiben, so dass dort zunehmend der von dir gegangene Weg als favorisiert zu sehen ist.

Danach können die tasks durchlaufen werden und im weiteren Prozeß Anpassungen des eigenen Templates vorgenommen werden. Von den neuen und teils besseren (default) Konfigurationseinstellungen will ich hier gar nicht erst sprechen... (zB. die thumb Größe der Media Dateien usw. usw.).

Ratsam ist es, gerade mit den neu behobenen Fehlern, in der Wartung möglichst schnell danach auf Plugin Zombies zu checken. Erst dann kann man sich langsam an die Feineinstellungen machen und diesbezüglich auf Entdeckungstour gehen. Oder gleich die Datenbank utf8mb4 Migration in der Wartung angehen. Jemand der neu installiert, hat dadurch so manches Problem gar nicht erst.

Ein letztes Wort:
Wichtig ist, sich vorher schlau zu machen was für Systemvoraussetzungen gestellt sind, damit man nicht in die Falle läuft etwas installieren zu wollen was gar nicht supported wird! ?

Ian Styx am |

Ich habe daraufhin die Upgrade section nochmal überarbeitet. ?

https://ophian.github.io/hc/en/installation.html#user-content-the-important-upgraders-howto---step-by-step-guide

Beat Post author am |

Sieht gut/besser aus! ?

Wobei... ich persönlich wäre nie auf die Idee gekommen (oder: hätte mir nie zugetraut), den aktiven Liveblog direkt zu migrieren. Das wäre mir viel zu heiss gewesen. Natürlich kann man backupen. Trotzdem...

Webspace gibt's heute im Überfluss und eine Subdomain einrichten ist auch keine Hexerei. Danach eine neue Styx-Installation aufzusetzen und zum Schluss lediglich die Daten zu migrieren, erscheint mir immer noch als eine sehr gute Idee. So kann man sich Zeit nehmen und Kleinigkeiten korrigieren, ohne dass der Live-Blog je offline geht oder gefährdet wird. Wenn dann alles soweit steht, muss/kann man ja ganz simpel das Zielverzeichnis der aktiven Blog-URL anpassen und quasi innert Sekunden ist die neue Version online. Danach kann man ganz entspannt die alte S9Y-Blog-Version löschen.

Ich will mich mit diesem Weg nicht profilieren, doch zumindest ansatzweise (eben: als Idee), hätte ich ein solches Vorgehen (für Angsthasen) gerne gelesen.

Ian Styx am |

Das beruht ja auf diversen Erfahrungen mit dieser Vorgehensweise. Es ist ja/war eigentlich eines der Vorzüge von Serendipity, dass man relativ easy updaten konnte und das sogar von ziemlich alten Versionen. Nur ist natürlich so eine System- oder eine Serien überspannende Migration eine wie auch immer etwas unsichere Sache und eigentlich nichts, was sich ein Anbieter solcher Systeme unbedingt wünscht. Haben die Entwickler an alles gedacht? Aber wer, wenn nicht sie?

Das mit dem Angsthasen kann man also für beide Wege beschreiben, oder auch sagen, dass du relativ mutig warst und mit einem konsequenten Vorgehen, treffsicherem Unterteilen und ein wenig zusätzlicher Hilfe zu einem guten Schluss gekommen bist. Als Idee/Möglichkeit steht es ja drin, nur nicht exakt ausgearbeitet. Wer gleich auf die 3.0 migrieren will, so wie du, muss dies auch so tun!

Die allermeisten User sind dazu ja auch viel zu ungeduldig. Und schwupps sind sie dann schimpfend weg und beim vermeintlich besseren Wordpress. Das böse Erwachen kommt dann oft ein paar Jahre und Erfahrungen später.

Tooltips

Ian Styx am |

Wahrscheinlich, wenn so gewählt, < acronym > das sind die Zusatzinformationen < /acronym > (ohne die Leerzeichen im Tag). [Aber auch acronym als tag müsste man wohl für CKE ACF EAC explizit erlauben.] Wie das genau mit dem tooltip funktionieren soll muss man wohl selbst herausfinden. Das Plugn ist ziemlich alt und baut wohl auf eine Javascript library die auch schon 7 Jahre auf dem Buckel hat. Ich kann nicht erkennen dass jemand damit schon mal herumexperimentiert hat und damit im s9y forum aufgelandet wäre.

Beat Post author am |

Nach einer knappen Stunde rumärgern sage ich: Dieses Plugin ist -so wie es ist- nicht zu gebrauchen! Ich lösche das wieder.

(habe im Beitrag noch ein span-title Beispiel angefügt)