Weblog Kommentare
Styx beta:3.0-rc...
Beat Post author am |
Soeben wurde mir das Update auf www.beatsblog.ch angeboten. Leider konnte es nicht durchgeführt werden. Es stoppt mit folgender Fehlermeldung:
Das Entpacken der Update-Zip-Datei ist fehlgeschlagen, da die folgenden Dateien nicht beschreibbar waren:
- /home/sites/site100015826/web/styx-master/templates/default/admin/js/js.cookie.min.js
Nachtrag: Konnte per FTP die Dateiberechtigungen ändern und dann hat der Update auf 3.0-rc1 funktioniert. ?
Nun steht in der Backend-Fusszeile: Betrieben mit Serendipity Styx 3.0-rc1 und PHP 7.4.2
Die Beta-Version beinhaltet auch eine Prüfsumme. Somit läuft der "Installation prüfen" Test fehlerfrei durch. Es wurden weder Plugin- noch Template-Zombies gefunden und den Template-Cache habe ich auch geleert. Soweit also alles o.k. ![]()
Ian Styx am |
SELECT *,DATE_FORMAT( FROM_UNIXTIME( value ) , '%Y-%m-%d %H:%m' ) AS date, NOW() AS now, UNIX_TIMESTAMP() AS tnow FROM styx_config WHERE name LIKE 'last_update_check_%'
Falls du zukünftig mal Zweifel haben solltest an der Funktionalität (1x am Tag wird überprüft), nimm das als check wie lange du noch warten musst, dann packe noch zusätzlich 1 Stunde obendrauf und es sollte schnapp machen! ?
Gut reagiert mit der Berechtigung!
Es ist keine Beta mehr im Übrigen, sondern der Release Candidate N° 1, das ist sozusagen fast fertig!
Beat Post author am |
? Normalerweise warte ich nicht auf Updates. Die kommen "einfach" irgendwann. Wird auch hier noch kommen. Ist auch nicht tragisch, wenn es erst morgen soweit ist. ?
Ian Styx am |
Es wurden weder Plugin- noch Template-Zombies gefunden und den Template-Cache habe ich auch geleert.
Nur mal so: Letzteres ist eigentlich unnötig, da bereits beim Upgrade geschehen. Tut also nur notwendig, wenn die Templates zicken machen und man sicher sein will das kein Smarty compiler cache herumspuckt. Die beiden ersten (Altlasten-Manager) sind eigentlich auch erst dann nötig, wenn man von einer alten Version upgraded und alte Restbestände entfernen will, oder eben alle Jahre mal, um aufzuräumen, oder eben auch öfter, wenn man viel herumspielt.
Beat Post author am |
o.k. Hier nun auch Serendipity Styx 3.0-rc1 und PHP 7.4.5
Ian Styx am |
Blog Subtitle needs some love now. ?
Beat Post author am |
Nur eine kurze Frage. Dazu habe ich im "Erweiterten Beitrag" ein Screenshot eingefügt.
Nach dem Hochladen erhalte ich für jedes Bild die gezeigten 6 Meldungen. Die drei gelben zeigen die kommenden Operationen an und die drei grünen bestätigen dann deren Durchführung. Obwohl ich mich dieser Meldungen gewohnt bin, irritieren mich die gelben Hinweise jeweils. Werden die später, im Final-Release (Stable-Version), unterdrückt oder bleiben die?
Ian Styx am |
Mein lieber Beat! ☺
Ich denke das auch immer! Aber ich bin entschlossen es beizubehalten. Denn mehr Information - alldimal so hübsch aufbereitet - ist immer besser als zu wenig. Du wirst es schätzen lernen, wenn plötzlich allerliebst rote Meldungen auftauchen, die unser oder jemandes nahes Ende aufzeigen. Man kann dann und vorher wunderbar darauf verweisen, was wann und wo gut und oder schlecht gelaufen ist. Und die Hilfe wird es ebenfalls zu schätzen wissen, als wenn sie nur ein genervtes "hat nicht geklappt" um die Ohren gehauen bekommt. Ergo sum: Ja!
Wie sagte ein großer Philosoph gerade erst heute:
Alle [Texte] sind als [..] Geschichten zu verstehen, die sich (fast) immer nur mit dem sichtbaren Teil des Ganzen beschäftigen. Diese Unwichtigkeit ist aber auch befreiend, denn es ist auch unwichtig, wenn man total daneben liegt
Hört Hört! ?
Beat Post author am |
? Danke für die Info. ?
Beat Post author am |
Habe gerade www.styx.beatsblog.ch auf 3.0-rc1 upgegradet. Mit dem automatischen Upgrade hat das leider überhaupt nicht funktioniert. Es wurden praktisch alle Verzeichnisse angemäckelt, dass sie nicht beschreibbar seien. Ein FTP-Check bestätigte dies auch. Weshalb das so war, ist mir völlig unklar, denn ich habe die Domaine damals eingerichtet und eine jungfräuliche Styx-Installation durchgeführt und überhaupt nichts an den Berechtigungen geändert.
Ich musste dann feststellen, dass ich für einige der Verzeichnisse keine Berechtigung habe um die Verzeichnis- oder Dateiberechtigungen zu ändern. Wieso auch immer.
Darauf habe ich den Auto-Upgrade-Prozess abgebrochen, 3.0-rc1 heruntergeladen, entpackt und auf www.styx.beatsblog.ch hochgeladen. Die neue Version wurde erkannt und ein paar Klicks später lief dann auch alles wie gewünscht.
Bei dieser Übung bin ich über die Berechtigungen des Cache-Verzeichnisses gestolpert. Hier (www.blog.dokumenzi.ch) hat das Cache-Verzeichnis die Berechtigung 771. Auf www.beatsblog.ch die Berechtigung 770, das heisst, keine öffentliche Berechtigung um Dateien auszuführen. ? Könnte das eine Auswirkung auf das Zeitfresser-Problem haben?
Leider habe ich auch auf www.beatsblog.ch keine Berechtigung um Zugriffsberechtigungen zu ändern. Ich muss da mal den Manitu-Support anschreiben und fragen, weshalb das so ist.
Ian Styx am |
In dem Fall war wohl das oberste Verzeichnis (in das hinein der Blog installiert war) nicht richtig beschreibbar. Eine kleine Ännderung und alles wäre durch gelaufen.
Von welchem cache Verzeichnis sprichst du? /cache ist nur ein Smarty cache für die backend Hilfe auf der Startseite, nichts existentielles.
Zeitfresser Problematik? Eher nein! Ansonsten hätte es errors gegeben, aber das tut es ja nicht.
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.