?? 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...
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?
Dann noch die Schärfung/Überarbeitung der Vorschaubilder...
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... ?
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 serendipityThumbzurück (mit dem Konverter) und dann erst alle auf styxThumb portieren (ebenfalls damit).
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.
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.
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.
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.
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:
Bild.jpg
Bild.serendipityThumb.jpg (meist 150px)
Bild.styxThumb.jpg (meist 400px)
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.
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
Behalte alle vorhandenen Vorschaubilder
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
Erneuere alle (*.) Vorschaubilder (die es noch nicht gibt),
Größe von Vorschaubild ändern (die es noch nicht gibt) und
Synchronisiere Datenbank mit Bilder-Ordner
Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben
Ist das worüber wir gerade sprachen
Erneuere alle (*.serendipityThumb) Vorschaubilder
Erneuert alle Vorschaubilder die so in der Klammer benamt sind, Also einfach eine "alle" statt "bestimmte" (wie in der zweiten) Aktion.
Konvertiere alte Vorschaubild-Namen
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.
Erstelle/Lösche alle Bild-WebP-Format-Variationen
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 |
Bevor ich nochmals überprüfe² kann ich jetzt schon sagen, dass deine Ausgangslage falsch ist.
Nachfolgend eine "ungefähre" Zusammenfassung meiner Upload-"Fakten":
Meist liegt die Lösung ganz nah vor einem, doch man sieht sie einfach nicht... ?
Ich habe im Uploads-Verzeichnis von www.styx.beatsblog.ch alle Dateien die im Namen *serendipityThumb* enthalten, gelöscht.
Mit Notepad++ habe ich in der styx_entries-Tabelle alle serendipityThumb durch styxThumb ersetzt.
In der Blogkonfiguration/Bildkonvertierung/Vorschaubild-Endung wählte ich styxThumb mit einer Grösse von 400px (längste Seite)
? Ta, ta, ta, ta! ? WUNDERBAR! Alles funktioniert! ?
Ich habe nun eine konsistente Thumbnailbezeichnung
Alle Vorschaubilder sind nun 400px breit (oder hoch)
Alle Vorschaubilder sind scharf
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.
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 |
Kleinen Makel gefunden in https://styx.beatsblog.ch/1982-Nicht-schlitteln.html
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.
Gibts sonstnochwas zu sagen zu meinem Tageserguß?
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. ?
Sehr informativ. Ich gehöre leider zu der Sorte Menschen, denen man gewisse Dinge mehrfach erklären muss, bis sie es kapieren.
Ehhh das kann ich nicht jeden Tag machen... ?
Aktuell ist der unterste Punkt: "Lösche alle Bild-WebP-Format-Variationen". Wozu soll das gut sein? Muss man die danach neu erstellen?
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.
Weshalb jedoch, wie im Kommentar #7011 erwähnt, alle serendipityThumb-Files gelöscht wurden, verstehe ich immer noch nicht.
Ich auch nicht, da ich nicht weiß was du wiegenau 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.
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.
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:
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?
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 |
Um das machen zu können, musst du mir erstens sagen welche Erklärung du jetzt genau meinst, zweitens warum in Wartung media sync
(¹) Wartungs Medien Synchroniser Task
Behalte alle vorhandenen Vorschaubilder
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
Erneuere alle (*.) Vorschaubilder (die es noch nicht gibt),
Größe von Vorschaubild ändern (die es noch nicht gibt) und
Synchronisiere Datenbank mit Bilder-Ordner
Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben
Ist das worüber wir gerade sprachen
Erneuere alle (*.serendipityThumb) Vorschaubilder
Erneuert alle Vorschaubilder die so in der Klammer benamt sind, Also einfach eine "alle" statt "bestimmte" (wie in der zweiten) Aktion.
Konvertiere alte Vorschaubild-Namen
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.
Erstelle/Lösche alle Bild-WebP-Format-Variationen
Für Upgrader, um in den Vorteil der komprimierteren Bilder für alte Medien zu kommen.
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?
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):
Nun änderte ich in der Konfiguration/Bildkonvertierung die Vorschaubild-Endung von styxThumb auf serendipityThumb (war schon: 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.
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.
Nein. Die Vorschaubildgrösse von 400px war schon zu Beginn meiner Aktionen so eingestellt.
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.
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.
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 |
?? 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
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?