Freitag, 15. Mai 2020
alte Vorschaubilder vergrössern
Derzeit habe ich dank Corona und schlechtem Wetter etwas viel Zeit. Da komme ich dann schon mal auf die eine oder andere Idee, wie ich meinen Blog etwas aufpeppen oder verschönern könnte ?.
In der Vegangenheit hatte ich ja lange mit mit gerungen, welche Grösse denn nun die Vorschaubilder in meinem Blog mit der neuen Styx-Edition haben sollten. Es gibt in meinem Blog verschiedenste Varianten. In den Anfängen, ab 2005, waren die Vorschaubilder 150px (oder gar nur 120px) breit. Wenn ich mich richtig erinnere, wurden sie dann mal 200px und ab Ende Januar 2020 verwende ich nun die empfohlene Breite von 400px Breite.
Ich gebe gerne zu, dass die anfängliche Skepsis verflogen ist und ich nun daran denke, ALLE Vorschaubilder im aktiven Blog auf 400px zu vergrössern. Das Vorgehen muss gut überlegt sein und dafür soll dieser Artikel dienen.
Als ersten Schritt, habe ich via Wartung Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben und Erstelle alle Bild-WebP-Format-Variationen durchgeführt. Damit dies bei über 3'000 Bildern funktioniert, musste ich die Execution Time in den PHP-Settings auf 600 Sekunden einstellen, das sonst der Befehl vor der Fertigstellung abgebrochen wurde.
Eine der Konsequenzen dieser Idee ist auch, dass ich nicht nur die Breite der Vorschaubilder vergrössere, sondern ich will auch gleich die alten serendipityThumb.jpg durch sytxThumb.webp ersetzen. Das wird also eine grössere Aktion.
Bevor ich die styx_entries Tabelle exportiere und abändere, untersuche ich den Quelltext eines einzelnen Beitrags. Und zwar diesen hier. Ich werde da den Quelltext ändern und mir genau notieren, welche Teile ich durch was ersetze.
Weil hier auf blog.dokumenzi.ch webp nicht unterstützt wird, werde ich DB-Änderungen zuerst auf https://styx.beatsblog.ch/ testen, bevor ich die Änderungen dann am Live-Blog vornehme.
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2645-alte-Vorschaubilder-vergroessern.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Das ist keine gute Idee und sicher ein mißverständlicher Verschreiber! Du willst xxx.serendipityThumb.jpg, durch xxx.styxThumb.jpg ersetzen. ? Ditto für die webp Variationen (so da schon welche wären).
Nur zu Information: Normale Upgrader von einem damaligen S9y haben ja .serendipityThumb als Appendix Auszeichnung aktiv.
Wenn diese Auszeichnung in der Konfiguration des Blogs auf styxThumb oder lilaThu geändert wird, wird automatisch eine neue Aktion in der Wartung (Mediatheksaufgaben) aktiv, die es erlaubt, alle bisherigen echten Medien und Medien-Datenbank-Enträge, sowie alle Blog und staticpage Einträge welche jene benutzen zu konvertieren.
[Nachtrag 17. Mai: Wie in den weiteren Kommentaren beschrieben bedeutet "automatisch" hier aber nicht unmittelbar, sondern nur unter der Bedingung, dass mind. bereits ein neues Medium mit dieser neuen Auszeichnung (über Medien hnzufügen) erstellt wurde.]
Das gilt auch, wenn du - der du (durch deine Art der Migration) bereits eine neue, wie bei Neu-Installationen, gesetzte Thumb Auszeichnung benutzt, diese in der Konfiguration zurück auf serendipityThumb stellst. Dann würde dir die Wartung erlauben, alle Medien und Einträge auf diese Auszeichnung zurückzuportieren. Danach könnte man dann genau umgekehrt vorgehen. (Wirf mal einen Blick in die zurgehörige Wartungs Info dazu, wenn du einen anderen Appendixnamen in der Konfiguration gewählt hast.) Wichtig ist also eine konsistente Grundlage für die Konversion.
[Nachtrag 17. Mai: Das mit dem Zurückstellen ist mißverständlich ausgedrückt und bezieht sich auf die Bedingung des vorherigen Nachtrags. Solange alle Einträge einheitlich sind, kann man den thumb Namen in der Konfiguration ändern und anschließend in der Wartung "Konvertiere alte Vorschaubild-Namen" anstoßen.]
Allerdings ist es immer gut, wenn man vor solchen Operationen einen Backup Dump zieht. Achtung: Das sind mind. '_images, '_entries, '_staticpages, '_mediaproperties und (?), sowie auch der ganze /uploads Ordner an sich.
Dabei kann natürlich viel schiefgehen und du müsstest darauf vertrauen, dass ich an alles gedacht habe als ich diesen Konverter schrieb. Ich habe viel getestet und war am Schluß zufrieden. Aber das basierte auf meinen Testinstallationen, die sicherlich nur theoretisch alle kombinatorischen Möglichkeiten und Bedenkungen ausschöpften. Außerdem kann solch ein Skript auch mal Husten haben und was dann...?
Du siehst, da ist eventuell mehr zu bedenken. Mit beiden Auszeichnungen (alte und neue) gleichzeitzig zu fahren, ist überhaupt nicht schlimm! Die Möglichkeit aber, dass einem die eigene Pedanterie viel größere Probleme einbrockt, ist also gegeben und sollte vorher einfach wohl bedacht sein!
Beat Post author am :
Etwas viel Information auf einmal. ?
Verständnisfrage:
In der beatsblog-Konfiguration steht derzeit: Vorschaubild-Endung = styxThumb
Trotzdem wird im Quelltext des #1003-Beitrags auf .serendipityThumb.jpg referenziert.
Falls (was ich bezweifle) ich Dich richtig verstanden habe, könnte ich jetzt in der Konfiguration eine Vorschaubild-Endung von z.B. beatThumb eintragen. Danach würde mir unter Wartung irgendwas angeboten, was alle diese neuen Vorschaubilder erzeugt und auch noch den Quelltext aller Einträge editiert? Kaum zu glauben.
Ian Styx am :
Da nimmst du richtig an, denn du hast das mit der Bedingung der konsistenten Grundlage wohl nicht richtig gelesen.
Wenn alte Einträge (natürlicherweise) auf .serendiptyThumb stehen und du aber ein neues Block aufgezogen hast das in der Konfiguration bereits das neue Default: styxThumb stehen hat, werden alle neueren Einträge in die Medathek und damit auch die darauf beruhenden neu referenzierten Blogeinträge mit styxThumb ausgezeichnet.
Der Konverter kann aber nur von alle AAA auf alle BBB oder vice versa konvertieren. Deshalb müsstest du - so du unbedingt willst - erst auf serendipityThumb zurück (mit dem Konverter) und dann erst alle auf styxThumb portieren (ebenfalls damit).
Besser?
Doch! So ist es gedacht.
Ian Styx am :
Ich musste gerade selbst noch mal nachschauen. Es ist schon so lang her...
Diese Option im Wartungs Mediatheks Synchronizr wird einem auch erst dann angeboten, wenn tatsächlich bereits zwei verschiedene Thumb Auszeichnungen vorliegen. Ist das nicht der Fall, muss man nicht konvertieren können.
Beat Post author am :
? it's magic ?
Hmmm... zum Glück habe ich einen Testblog...
Doch ich sollte Deinen Hinweis, dass dies eigentlich unnötig und reine Kosmetik/Pedanterie ist, wohl ernstnehmen. ?
Wohl besser, wenn ich das vorerst mal lasse und mich nur um die "with=150px" Angaben kümmere. Wobei... falls durch die oben von Dir beschriebene Aktion nicht nur die serendipityThumb.jpg zu styxThumb.webp umgewandelt werden, sondern auch noch die Vorschaubildgrösse auf die voreingestellten 400px angepasst würde, wäre das durchaus eine Überlegung wert.
Ian Styx am :
Wenn ich (diesbezüglich) nicht eben auch so wäre ... gäbe es das nicht - also ist die Bezeichnung nicht unbedingt nur auf dich gemünzt. ☺
Hier zum nachlesen (für jene ohne)...
Du meinst "Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben"?
Dies sollte all jene Vorschaubilder neu generieren (inklusive webp), die eben nicht der neu gesetzten Größe (400px) entsprechen. Einträge brauchen dafür doch nicht neu geschrieben bzw konvertiert werden, oder? (Bin mir gerade nicht sicher wie ich das gehandelt habe.)
NACHTRAG: Du hast aber über die Blogentries geredet, oder?
Beat Post author am :
Im Quelltext des #1003-Beitrags steht als Beispiel:
Ganz am Schluss "with:110px" bezeichnet wohl die Grösse des Vorschaubildes. Nach meinem Verständnis müsste ich -um grössere Vorschaubilder zu erhalten- diesen Wert hier immer auf 400px schreiben.
Ian Styx am :
Um das herauszufinden würde ich folgendes machen. Schreibe einen Testeintrag mit einem Bild das du auf diesem (neuen) Blog zum ersten Male heraufgeladen hast. Jetzt steht darin ja < img blah blah width=400px >, oder? Verdoppele diesen Media include im Quelltext und ändere den zweiten auf 150px. Wie sieht es aus wenn du die Seite im Frontend aufrufst?
Ian Styx am :
Ach nee ist ja klar...
Die Frage ist ja ob überall 110 bzw sein analogon 400 stünde, denn es gibt ja auch hochkant Bilder mit eiinem anderen width da ja die Höhe dann 400 wäre.
Beat Post author am :
Guckst Du: https://styx.beatsblog.ch/2632-Vorschaubildgroesse.html
doch es wird kompliziert... denn ein neues "picture"-Element erzeugt einen ziemlich anderen Quelltext für ein Bild, als dies früher S9Y-Original gemacht hat.
Aber... wenn ich wie oben angedeutet, "with=110px" auf "with=400px" ändere, dann wird das Vorschaubild schon in der neuen Grösse angezeigt. Siehe: https://styx.beatsblog.ch/1003-Hoehenmeter-sammeln.html
Beat Post author am :
STOPP!
Ich muss die Komplexität wieder reduzieren, sonst wird das nichts!
Ich mach jetzt mal einen Export der entries-Tabelle von www.styx.beatsblog.ch. Darin ändere ich alle "with=83px" (Hochformat) auf "with=300px" sowie alle "with=110px" (Querformat) auf "with=400px". Dann schaue ich weiter.
Du musst Dir übrigens keine Zeit nehmen für diesen Quark. Es ist eine Art "spielen"... Du kannst Deine Zeit bestimmt sinnvoller nutzen...
Ian Styx am :
Muss heißen "ändern würde", denn siehe https://styx.beatsblog.ch/uploads/2008/20080713_01.serendipityThumb.jpg
zeigt, dass du nur ein 110ner auf 400 unschön aufgebläht hast.
Ganz allgemein gesprochen ist es nicht so wirklich ratsam, einfach sein entries.sql zu nehmen und mit search und replace solche Dinge zu ändern. In der Datenbank stünden sie dann immer noch mit ihrer originalen Größe, mit unübersehbaren Folgen für spätere Zeiten und Aktionen.
Wenn man konvertiert, muss man das durchgehend und durchgehend richtig machen; am besten mit einem skript das keine Ausnahmen zuläßt bzgl Reigenfolge, Dependencies etc.
Beat Post author am :
In welcher denn? In der styx_images? Soweit ich gesehen habe, stehen dort von den Thumbails keine Grössenangaben.
Als Bastler, lässt sich vieles hinbiegen.Siehe aktuell: https://styx.beatsblog.ch/1003-Hoehenmeter-sammeln.html
Doch wie es Bastler so ansich haben, kratzen sie immer nur an der Oberfläche und falls die Struktur im Hintergrund dadurch Schaden nimmt, merken sie das nicht...
Ian Styx am :
Soweit du nur von Thumbs sprachst hast du natürlich recht!
Ich habe das nur allgemein als Warnung ausgesprochen. Sieht jetzt schon viel besser aus! ?
Ian Styx am :
Kann man denn in (on cl ick weder zusammen führen)
nicht gleich das ganze
Geraffel entfernen und bei image das
auf ein
reduzieren, bei gleichzeitiger Einfügung von serendipity_image_right in die class="" und analog bei den left floateten Bildern ??
Beat Post author am :
?? Du hättest mich lachen sehen sollen, als ich Deinen Kommentar las! ?
Latürnich! Wer kann, der kann!
Leider habe ich in der Zwischenzeit etwa 5 verschiedene Vorschaubildgrössen gefunden, dazu noch jeweils Hoch- und Querformat, macht mindestens 10 Varianten....
Hinzukommt, dass die nun grossen Vorschaubilder oftmals Bilder unten aus dem Beitrag und über die Fusszeile ragen. Das sieht z.T. ziemlich unschön aus. Siehe z.B. unten auf dieser Seite: https://styx.beatsblog.ch/archives/2006/12/P5.html Bastlermässig kann ich das lösen, indem ich vor dem abschliessenden Paragraphen am Schluss ein "hr" einsetze. Aber das betrifft viele Beiträge und die müsste ich auch erst mal heraussuchen.
Dann noch die Schärfung/Überarbeitung der Vorschaubilder...
Das braucht alles seine Zeit. Deshalb denke ich, dass ich nicht noch tiefer im Quellcode rumwursteln werde. Zumal -wie Du richtig vermutet hast- ich nichts anderes kann, als im SQL-File mit Notepad++ search and replace...
Ian Styx am :
Freut mich wenn ich zur Erheiterung beitrage. Soviel zu Lachen gibts ja sonst nicht...
Alles in Einzelteilen natürlich.. und nur da wo es Sinn macht. Aber das alles ist wahrhaft Spielerei. Warum nicht einfach lassen. Die Meinung die du damals vertreten hast änderst du ja auch nicht rückwirkirkend. Das ist Historie und damit ein werdendes Kunstwerk.
Zum Überschlag Eintrag könnte man dem p in solchen Beiträgen ein style="display: flow-root;" oder inline-block addieren oder den Artikelcontent in ein div mit eigener class="pipapo" kleiden und mit pipapo {display: inline-block;} in die user,css setzen.AUGENBLICK: pure update ist unterwegs.Komisch, irgendwie kommt mir das bekannt vor.... hatten wird das nicht schon einmal?
Wie und wieso machst du das? (was nicht besser durch die autonatischen ImageMagick Optimierungen geht) ??
Beat Post author am :
Mist. Mit der Aktion habe ich mir jetzt echt ins Knie geschossen... ?
Trotz 600 sec. Executiontime kann die Eintrags-Konvertierung nicht vollständig abgeschlossen werden. Ich habe dann wieder auf styxThumb umgestellt, doch auch da bricht PHP nach 10 Min. die Operation ab. Nun habe ich "sowohl als auch" im Uploads-Verzeichnis, kann aber nicht genau feststellen wo "sowohl" und wo "als auch".
Als Nothilfe lade ich das heute Morgen lokal gebackupte Uploads-Verzeichnis erneut hoch und weil ich nicht weiss, was nun in der entries-Tabelle steht, werde ich auch die wieder überschreiben.
Ich würde deshalb sagen: bei >3'000 Bildern und >2'500 Beiträgen kann die Konvertierung nicht durchgeführt werden.
Ian Styx am :
Tja doof aber auch. Dann müsste man das in 20iger Schritten machen so wie bei entryproperties cache... Eins nach dem anderen und luft holen zwischendrin, so in etwa. Ob ich das für das release nioch hinbekomme kann ich nicht sagen.
Ian Styx am :
Was ist denn wenn du die execution time kurzfristig auf Bilder x 1s setzt?
Beat Post author am :
ganz ruhig...
Wenn man Vorschaubilder erneuert und infolge PHP-Restriktion die Aktion abgebrochen wird, kann man danach einfach wieder starten und nach ein paar Intervallen ist man dann durch. Ich nehme an, weil die bereits Erneuerten fast keine Bearbeitungszeit mehr benötigen und so dann einfach die noch Ausstehenden abgearbeitet werden.
So ähnlich müsste das bei der Konvertierung auch funktionieren. Doch leider kriegt man nach dem erneuten Einloggen unter Wartung diesen Menüpunkt nicht mehr angeboten. Styx glaubt, die Konvertierung fertig abgearbeitet zu haben, was aber nicht stimmt. So als Laie würde ich nun sagen, dass der Konverter zuerst die Summe aller Entries erfassen muss und bei jedem abgearbeiteten Beitrag diesen markiert oder abzählt. So wüsste er, ob noch zu konvertierende Beiträge ausstehen oder nicht.
ABER: Ich denke, es lohnt sich nicht, hier irgend einen Aufwand zu treiben. Denn wer (ausser mir) kommt schon auf so doofe Ideen?
Meine Absicht war, dass durch das Neuerzeugen von serendipity-Vorschaubildern (nun in 400px statt in 150px) eben schärfere Bilder zu erhalten als wenn eben die alten 150px-Vorschaubilder einfach hochskaliert werden.
Ian Styx am :
Das sollte ich vielleicht in die Synchro Info Hilfe notes mit aufnehmen. Und ja das Verhalten hätte ich erwartet.
Und das hatte bei der Konvertierung nicht geklappt, oder nur nicht geklappt weil du komplett abgebrochen hattest?
Ja klar doch, was Kleines aufzublasen ist (fast) immer schlechter als ein Großes artgerecht zu verkleinern, jedenfalls bei Bildern! ?
Beat Post author am :
Nach 10 Minuten (600sec ist das Maximum, welches ich einstellen kann) bricht die Operation ab und ich lande auf einer 503-Seite. Wenn ich dann wieder die Adminseite öffne, muss ich mich nicht einloggen und komme direkt auf das Admin-Backend. Wenn ich dann Wartung anwähle, steht mir die Konvertierungsfunktion leider nicht mehr zur Verfügung.
Ian Styx am :
Ah...dumm! Da musss ich mir dann mal etwas überlegen.
Ian Styx am :
Nur zur Sicherheit nachgefragt. Wir sprechen hier von der Option: "Erneuere alle (*.serendipityThumb) Vorschaubilder" - ja / nein?
Beat Post author am :
Nein. Ich spreche von der "Konvertierung aller Vorschaubilder in Blogeinträgen". Ich weiss den genauen Wortlaut nicht mehr, weil es mir eben nicht mehr angezeigt wird. Du hast es "Mediatheks Synchronizr" genannt.
Beat Post author am :
ACHTUNG!
Ausgangslage: In meinem Upload-Verzeichnis gibt es zu jedem Bild folgende Varianten:
Nun änderte ich in der Konfiguration/Bildkonvertierung die Vorschaubild-Endung auf serendipityThumb mit einer Grösse von 400px. Dann wählte ich unter Wartung "Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben". Die Idee dahinter: Ich erhalte neue serendipityThumb.jpg in der richtigen Grösse (400x300). Danach stellte ich die Konfiguration/Bildkonvertierung/Vorschaubild-Endung wieder auf styxThumb (wie vor der Aktion). Somit sollte ich für die alten Beiträge, neue, scharfe und grössere Vorschaubilder erhalten.
Das Resultat: Alle serendipityThumb.jpg wurden gelöscht aber KEINE neuen SerendipityThumb.jpg wurden erzeugt! Dies bestätigte die Überprüfung per FTP. Es waren keine serendipityThumb.jpg mehr vorhanden.
Zum Glück habe ich heute Morgen das gesamte Uploads-Verzeichnis lokal gesichert und so konnte ich die serendipityThumb's wieder hochladen.
Bitte teste das bei Dir. Es wäre ein grober Fehler, wenn bei einer Grössenänderung der Thumbnails nur die alten gelöscht aber keine neuen erzeugt werden.
Ian Styx am :
Bevor ich nochmals überprüfe² kann ich jetzt schon sagen, dass deine Ausgangslage falsch ist.
Ein Bild kann immer nur ein einzelnes thumb haben (von den .v/ Variationen abgesehen), egal wie es in der config benamt ist. Es kann aber durchaus sein, dass eben thumbs von alten Einträgen ein anderes Schema aufweisen als die neueren. (Dafür ist die eventuelle Konvertierungsmethode gemacht.) Aber beides zugleich in realita per selben image geht nicht!
Du muss dir das wie sichbare Medienobjekte vorstellen. Ein Objekt hat immer ein Thumb, sofern es die Größe und der Typ zulässt. Gibt es nun weitere, sind das eben noch andere und auch sichtbare Medienobjekte und wird alles andere wie Datenbank und Entryconversions gehörig durcheinanderbringen. Solche Abläufe sind (vereinfacht): Suche aus der Datenbank das Bild / die Bilder. Dann erstelle die Pfade und zugleich das Thumb mit entsprechendem Namenschemata. So muss/müsste es in echt vorliegen. Das ist das "array" das durchlaufen wird, wenn du solche Dinge anstößt wie, Media tasks Umbenennen, oder Medien Verschiebungen in den Verzeichnisebenen. All das muss ja nicht nur real in /uploads, sondern auch sehr genau und ziel-/treffsicher in den Datenbank Tabellen der Medien und Entries / Staticpages geändert werden.
Also ist alles was zusätzlich im uploads Ordner herumliegt entweder eine Ausnahme (zB. Variationen durch webP oder durch Imageselectorplus) oder eben ein direktes Medienobjekt mit oder ohne thumb.
Zu deinem Ablauf:
Das sind grundsätzlich 2 verschiedene Sachen und sollten auch grundsätzlich voneinander getrennt behandelt werden. Früher hatten Vorschaubilder eine Größe von 110px. Das wurde möglicherweise vom User in 150px oder so geändert. Heute haben sie eine Vorgabe von 400px. um u.a. auch in der Mediathek schön auszusehen. Stellst du jetzt deine (alte) Blog Konfiguration auf 400, kannst du eben alle ThumbBilder die nicht dieser bestimmten Größe entsprechen umändern lassen. Dazu wird immer erst die alte Version gelöscht bevor die neue erstellt und platziert wird. Diese Option gibt es schon ziemlich lange.¹
Meine Beiträge zur Mediathek und der Medien-Synchronisationsgeschichte sind hauptsächlich detaillierte Untersuchungen und ein ziemlich großer Haufen Fixes für das korrekte Handling und für Bugs. Ebenso unter anderem zB die Verzeichnisebenen-Wechsel-Möglichkeiten. Zusätzlich eben nur noch die Ausnahmen und alles was mit der WebP Geschichte zu tun hat. Alles in allem habe ich alles ziemlich durchgewalkt.
Was also passiert, wenn du in der Konfiguration beides zugleich (also Größe und Benamung) änderst, kann ich nicht sagen, da ich auf so eine Idee gar nicht kommen würde. Aber du sagst, es hätte dir alles zerhauen und das insbesondere auch noch durch die falsche Ausgangslage? Verstehe ich das richtig?
(¹) Wartungs Medien Synchroniser Task
Synchronisiert die Datenbank mit allem (erlaubten) was in /uploads herumliegt, falls man mal etwas zusätzlich so hineingeworfen hat. Auch dient es der allgemeinen Synchronisation, zwischen images Tabelle und uploads/ realita Ordner. Löscht also zB auch Dinge, die da eventuell durch Fehler stehengeblieben sind. Im Einzelnen sind dies
Ist das worüber wir gerade sprachen
Erneuert alle Vorschaubilder die so in der Klammer benamt sind, Also einfach eine "alle" statt "bestimmte" (wie in der zweiten) Aktion.
Naja, darüber habe ich schon gesprochen Wird erst aktiv, wenn es auch tatsächlich etwas zu konvertieren gäbe. Bedingt aber, wenn man die Thumbs über die "Alle Erneuern" (3) Option neu bilden lassen möchte, dass diese Konvertierung zuerst geschehen sein muss.
Für Upgrader, um in den Vorteil der komprimierteren Bilder für alte Medien zu kommen.
(²)
Ich benötige keine erneute Überprüfung und tests, da ich gerade erst zur Veröffentlichung von 2.9.5 entsprechend viele Tests gemacht hatte, die eben genau jenes beinhalteten, also alte Blogs hochhieven und die Mini Vorschaubilder auf die neue Größe habe konvertieren lassen.
Nachtrag:
Damit du siehst, dass ich tatsächlich doch noch einmal alles überprüft habe, habe ich doch tatsächlich noch einen dummen typo Bug bezüglich des Parsens von staticpage Inhalten beim thumb conversion task gefunden und gefixt. Also hat es sich doch gelohnt. Danke! ?
Beat Post author am :
Nachfolgend eine "ungefähre" Zusammenfassung meiner Upload-"Fakten":
Beat Post author am :
Meist liegt die Lösung ganz nah vor einem, doch man sieht sie einfach nicht... ?
? Ta, ta, ta, ta! ? WUNDERBAR! Alles funktioniert! ?
Ich werde das noch etwas beobachten und austesten und dann, irgendwann nächste Woche, die gleichen Änderungen auf dem Live-Blog, www.beatsblog.ch, vornehmen.
Ian Styx am :
Sehr hübsch! (Kleinen Makel gefunden in https://styx.beatsblog.ch/1982-Nicht-schlitteln.html) Bravo!!
Gibts sonstnochwas zu sagen zu meinem Tageserguß?
Übrigens, ich glaube herausgefunden zu haben, warum manchmal das versteckte Mathe Captcha angezeigt wird. Ich hatte ja erst die neuen Versionen von Firefox in Verdacht, doch inwischen glaube ich dass das an dem NGINX Proxy liegt und damit nicht von uns beeinflusst werden kann.
Beat Post author am :
Ja, solche, oder so änliche, Bilder habe ich auch schon entdeckt. Das kommt immer dann vor, wenn das Originalbildverhältnis nicht 3:4 entspricht. So wird das angesprochene Bild mit einer Breite 62px beschrieben. Das habe ich natürlich nicht auf 300 angepasst (eine Variante mehr). Nobody is perfect.
Sehr informativ. Ich gehöre leider zu der Sorte Menschen, denen man gewisse Dinge mehrfach erklären muss, bis sie es kapieren. ?
Habe soeben "Behalte alle vorhandenen Vorschaubilder" durchgeführt und das lief ohne Fehler ab. ? Eine Frage habe ich noch: Aktuell ist der unterste Punkt: "Lösche alle Bild-WebP-Format-Variationen". Wozu soll das gut sein? Muss man die danach neu erstellen?
Ich fände es natürlich Spitze, wenn die Erklärungen, welche Du im Kommentar erwähnt hast, unter Wartung in so i-Kästchen einsehbar wären.
Weshalb jedoch, wie im Kommentar #7011 erwähnt, alle serendipityThumb-Files gelöscht wurden, verstehe ich immer noch nicht. Aber ich sehe das durchaus positiv, denn es hat mich der Lösung nähergebracht. ?
Ian Styx am :
Ehhh das kann ich nicht jeden Tag machen... ?
Was man erstellen kann, soll man auch löschen können. Müssen muss man gar nix. Man hat sonst ja gar keine Möglichkeit die Variationen zu löschen.
Ich auch nicht, da ich nicht weiß was du wie genau gemacht hast und welche Ausgangslage genau vorhanden war. In deinen Beschreibungen ging es mit der Terminologie etwas munter durcheinander, ein Grund, warum ich versucht habe das sehr ausführlich in c7012 zu beschreiben.
Ian Styx am :
Um das machen zu können, musst du mir erstens sagen welche Erklärung du jetzt genau meinst, zweitens warum in Wartung media sync und drittens benötige ich die Beantwortung meiner Frage:
Diese inkludiert die diesbezügliche Frage, ob du tatsächlich in der Konfiguration (Größe und Name) zugleich geändert hast und dann (erst) welche der 5 Optionen (siehe c7012) im Wartungs Media Sync gedrückt hast?
Ich habe übrigens dem ersten Kommentar dieses Posts (c6982) ein paar Nachträge verpasst um grobe Mißverständlichkeiten auszuräumen.
Beat Post author am :
(¹) Wartungs Medien Synchroniser Task
Synchronisiert die Datenbank mit allem (erlaubten) was in /uploads herumliegt, falls man mal etwas zusätzlich so hineingeworfen hat. Auch dient es der allgemeinen Synchronisation, zwischen images Tabelle und uploads/ realita Ordner. Löscht also zB auch Dinge, die da eventuell durch Fehler stehengeblieben sind. Im Einzelnen sind dies
Ist das worüber wir gerade sprachen
Erneuert alle Vorschaubilder die so in der Klammer benamt sind, Also einfach eine "alle" statt "bestimmte" (wie in der zweiten) Aktion.
Naja, darüber habe ich schon gesprochen Wird erst aktiv, wenn es auch tatsächlich etwas zu konvertieren gäbe. Bedingt aber, wenn man die Thumbs über die "Alle Erneuern" (3) Option neu bilden lassen möchte, dass diese Konvertierung zuerst geschehen sein muss.
Für Upgrader, um in den Vorteil der komprimierteren Bilder für alte Medien zu kommen.
Nein. Die Vorschaubildgrösse von 400px war schon zu Beginn meiner Aktionen so eingestellt (plus: styxThumb).
Also nochmal: Ich hatte einen Upload-Ordner mit ca. 16'000 Einträgen (siehe c7013). Das heisst, es gab bereits für jedes jpg-Bild je ein serendipityThumb.jpg sowie ein styxThumb.jpg. Für mein Vorhaben, die alten serendipityThumb-Vorschaubilder neu mit 400x300 anzeigen zu lassen, taugten die meist <150px kleinen Bilder jedoch nicht. Dann (ich zitiere aus c7011):
Ian Styx am :
Das Wort 5-er Liste hätte genügt, statt ein Full quote! ?
Ja da sitze ich sowieso schon dran. Die Frage ist halt nur wie genau und wo... Zu viel für eine Styx Options Info, scheint mir.
Und damit dann eigentlich doch. Denn du hast (durch deine Art der Migration) die neuen defaults einer neuen Installationen vorliegen. Die alten pre-migration Einstellungen waren 110/150px? und serendipiyThumb. Und waren eben auch so (real) in uploads. Hättest du "ordentlich" migriert, wären die alten Einstellungen (da Datenbankbasiert) erhalten geblieben.
Beat Post author am :
Mich wundert etwas, weshalb Du nicht schon lange gefragt hast, warum es für jedes Bild eine serendipityThum und eine styxThumb Datei gab.
Ich sage es Dir, auch ohne entsprechende Frage ?. Ich habe nach der Migration irgendwann auf Erneuere alle (*.styxThumb) Vorschaubilder geklickt. Ich hatte damals die Hoffnung, dass ich so ALLE Vorschaubilder auf styxThumb umstellen könnte und hatte völlig vergessen, dass der jeweilige Bezug ja in jedem entry-Eintrag vermerkt ist.
Bei meinen Aktionen am Freitag konnte ich dann Konvertiere alte Vorschaubild-Namen nie komplett durchführen, weil dieser Schritt eben länger als 600sec dauerte. Die Inkonsistenz in der styx_entries-Tabelle habe ich dann zwar festgestellt, bin jedoch nicht auf die Idee gekommen, dass ich einfach die noch nicht auf styxThumb umgestellten Beiträge per Notpad++ hätte nach-korrigieren können. Deshalb habe ich dann die ursprüngliche (alte) styx_entries-Tabelle wieder hochgeladen.
Wenn ich das alles richtig verstehe, dann habe ich gestern (beim Erfolg) aber eigentlich nichts anderes manuell gemacht, was Konvertiere alte Vorschaubild-Namen eigentlich hätte automatisch machen sollen.
Ian Styx am :
Das habe ich einfach stillschweigend angenommen, seit du das mit dem Doppelvorkommen erwähnt hattest. ?
Und es ist gut dass du meine Frage(n) dann doch noch ausführlicher beantwortest, soweit die Erinnerung trägt.
Die neuen Konfigurationseinstellungen einer NEU-Installation sind das entscheidende und eben verschiedene Möglichkeiten der Media Synchronisation. Es gibt ja auch noch die automatische beim Öffnen der Mediathek.
Ian Styx am :
Hätte das etwas geändert, wenn du diese Seite
https://ophian.github.io/hc/en/media-migration-tasks.html
vorher gelesen hättest und in der Wartungs Info darauf hingewiesen worden wärst?
Beat Post author am :
Gab es diese Seite denn schon (vor heute)? Ich finde die Info gut und wertvoll. Ich muss aber auch gestehen, dass ich zu der Sorte Menschen gehöre, die erst Handeln, dann Studieren und wenn das alles nichts nützt, mal nach einem Manual suchen... ?
"und in der Wartungs Info..." Ich bin mir nicht sicher, ob wir hier das Gleiche meinen. Beim Titel: Optionen für die Erzeugung der Vorschaubilder gibt es ja bereits eine Infobox. Ich hätte mir nun selbiges für jeden einzelnen der nachfolgenden Punkte vorgestellt (also nicht alles in einer Infobox, sondern zu jedem (menü-)Punkt eine entsprechende Erklärungsinfo). Das ist aber nur meine persönliche Ansicht.
Ian Styx am :
Kenne ich.. ?
Nein nein, sie ist durch unseren Diskurs entstanden. In der Wartung Media Sync kann nur auf kurzes verwiesen werden. Deshalb lieber als dringend zu lesender Link.
Und...: Gerade fertiggestellt:
https://ophian.github.io/hc/en/faq/#docs-strange-entry-date-issues-after-moving-to-another-server-with-differing-offset
Beat Post author am :
? Es ist vollbracht!
Habe heute Nachmittag fast fünf Stunden investiert um auf www.beatsblog.ch alle Vorschaubilder zu vergrössern und gleichzeitig alles auf *.styxThumb umzustellen. ?
Es gab unzählige Bild-Grössen-Variationen und durch die verschiedenen Blog-Updates in den fast 15 Jahren Blog-Geschichte gab es auch mindestens drei verschiedene Varianten, wie die Grössenangaben in die entries-Tabelle geschrieben wurden.
Es wird immer noch ein paar wenige kleine Vorschaubilder geben, doch ich denke schon, dass ich grösser 98% erwischt habe.
Einen kurzen Moment gezittert habe ich, als ich die über 3'000 *.serendipiyThumb-Files aus dem Uploads Verzeichnis gelöscht habe. Doch die braucht es ja nun nicht mehr und ich konnte (zum Glück) auch keinen negativen Effekt feststellen. So wurde auch da etwas aufgeräumt. ?
Ian Styx am :
Holla die Waldfee ? Deswegen war das hier so ruhig...
Ich bin immer noch der Meinung das ein testblock mit der Wartungs Automatik (etwas) schneller gegangen wäre, oder lags an dem 600s execcution time 503 redirect.
Beat Post author am :
Ja, auf www.styx.beatsblog.ch bin ich an der PHP Execution Time gescheitert.
Durch Tüfteln habe ich aber ziemlich gut gelernt, wie ich das händisch hinkriege. Ich will Deine Wartungsautomatik keinesfalls schmälern, doch ich weiss nicht, wie sie mit über 30 verschiedenen Bildgrössen und drei verschiedenen Quelltextvarianten umgegangen wäre. Einmal stand da "width:120px", dann "width=120px" oder auch " width=\"120\". Dann noch Hoch- und Querformat in X verschiedenen Grössen. Vor allem deshalb brauchte ich Stunden.
Ian Styx am :
Die Bildgröße der Thumbs und ihre Berechnung ist Teil der Mechanik, da ja die Bildgröße der echten Bilder seit dem upload gespeichert wird.
Beat Post author am :
Das klingt ja schon verlockend... Ich könnte es ja auf www.styx.beatsblog.ch nocheinmal versuchen (falls ich noch eine alte styx_entries-Tabelle finde).
Nur, wie kann ich das Timeout-Problem umgehen? Das mit 0,5 sec. pro Bild kann ich so nirgends konfigurieren.
... hmm... ich weiss nicht... sieht jetzt doch recht ansprechend aus. Wirklich begeistern könnte ich mich für diese Idee ja eigentlich nur, wenn der ganze alte Quellcode-Karsumpel auch noch weggeräumt würde und somit die Formatierung (Rahmen/Schatten, etc.) durchgängig würde. Doch ich befürchte, das wäre dann doch zuviel verlangt.
Ich bezweifle, dass Aufwand und Nutzen in einem vernünftigen Verhältnis stehen...
Ian Styx am :
Vielleicht, in dem man für diese Prozedur einen temporären Eintrag
in die
https://github.com/ophian/styx/blob/master/include/admin/images.inc.php#L65
setzt. Soweit das vom Hoster überhaupt erlaubt ist, also einfach ausprobieren.
Ian Styx am :
Das sind Attribute des img Elements. Sie spielen solange keine Rolle (und dabei ist es egal ob mit oder ohne px, meine ich) solange ein style="width:WERT" da ist, der sie überschreibt. Das ist eine Frage der Wertigkeit. So kam - glaube ich - der Letztere u.a. sowieso nur in die img string Auszeichnung, sonst hätte man das ja gleich im CSS machen können.
Beat Post author am :
Mir wird immer wieder bewusst, dass mein technischer Verständnis ziemlich limitiert ist und ich um Lichtjahre von Deinem Wissensstand entfernt bin...
Erst heute habe ich verstanden, was Du mir im Kommentar c6999 sagen wolltest. Damals konnte ich nur darüber lachen, weil ich schlicht nur Bahnhof verstanden habe. Heute gelange ich zur Aussage: Inline-Styling ist des Teufels! ?
Ich versuchte nämlich, den alten Bildern abgerundete Ecken und Schatten beizubringen, wie das bei aktuellen Bildern der Fall ist. Aber: Vom ersten Beitrag (16.12.2005) bis zum Beitrag vom 14.06.2013 sind die Vorschaubilder sehr stark inline formatiert.
Ich habe deshalb heute c6999 noch ein paar mal gelesen und überlegt, ob ich einen Anlauf nehmen soll, um den Quelltext der Beiträge zu entschlacken (und somit Formatierung aus dem Beitrag und in das user.css zu verschieben). Aber... ich lass es bleiben. Es gibt doch einige Variablen (Lightbox-ID, Kommentare, title- und alt-Informationen, Bild-Name, Vorschaubild-Name) die ziemlich verstreut zwischen den Styling-Anweisungen liegen. Ich traute mir nicht zu, das wirklich in den Griff zu kriegen.
Das ist nicht schlimm... Habe nochmal ein paar Vorschaubilder angepasst und nun finde ich (fast) keine Minibilder mehr. Man muss es auch mal gut sein lassen! Mit dem Erreichten bin ich wirklich zufrieden und schliesse somit diesen Punkt ab.
Nochmals VIELEN DANK für Deine Unterstützung (und natürlich rückwirkend auf die hartnäckige Motivation um 400px-Vorschaubilder einzuführen). Nun gibt es in beats blog keine Mini-Bildchen mehr. ?
Ian Styx am :
? aber auch Behufte haben mitunter ihre Brechtigung.
Ian Styx am :
Nur zur Info
Auf https://www.beatsblog.ch/1700-Rimini-Cesenatico.html
fehlt ein Bild /uploads/2011/20110406_06.styxThumb.jpg mit seinem Pendant /uploads/2011/20110406_06.jpg.
Vielleicht findest du ja heraus ob es ganz weg ist und ersetzt werden müsste oder nur etwas anders heißt, oder so.
Ich hätte gerne mal gesehen wie das schöne Grand Hotel ausssieht. Sie erinnern mich sehr daran, dass ich einst selber gerne mal in Triest ein solches besucht hätte. Es steht immer noch auf meiner Bucketlist. ?
Beat Post author am :
Es gibt ein paar ganz wenige alte Bilder, die irgendwie korrupt und 0 Byte gross sind. Woher das kommt, habe ich leider keine Ahnung. Bei 20110406_06 war zumindest noch ein Vorschaubild in einem alten Backup, so dass ich es (vom Original-Digi-Bild) wieder herstellen konnte.
Es ist aber ein Selfie und hilft Dir somit nicht weiter. Bilder der beiden Grand Hotels (Cesenatico und Rimini) sind jedoch nach wie vor in oben erwähntem Beitrag drin.