Kommentare von

beats TEST blog

Weblog Kommentare

Styx-Stand: 01.05.2020, 10:58

Ian Styx am |

OK mache dir vorher mal ein Backup der entries Tabelle, sicherheitshalber.

Alles in einem Rutsch!

Dann:

UPDATE styx_entries AS T1,
      (SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time
        FROM styx_entries 
        WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23') AS T2 
  SET T1.timestamp=(T2.timestamp - 3600)
WHERE T1.id = T2.id;

661 Datensätze betroffen.
Überprüfe mit

SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time from styx_entries WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23' ORDER BY time ASC

müsste jetzt leer sein.

Ian Styx am |

Nur der Einfachheit halber sei es noch gesagt, dass man das erste date_format weglassen kann da man ja nix angezeigt bekommt. im Update sub select. Also:

UPDATE styx_entries AS T1,
      (SELECT id, timestamp
         FROM styx_entries 
        WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23') AS T2 
  SET T1.timestamp = (T2.timestamp - 3600)
WHERE T1.id = T2.id;

 

Ian Styx am |

Entferne bitte mal das

$serendipity['useWebPFormat'] = true;

falls du es einfach übernommen hast. Ich habe immer wieder vergessen darauf hinzuweisen, dass das eigentlich nur eine temporäre Variable für die local.inc war, die während der (frühen) Enwicklung hin zu webp nötig war, damit man mit Vor-Versionen bereits testen konnte. (Ist in den NEWS erklärt.) Als ich dir dann das Beispiel für die CBA fetch Limit gezeigt habe, war die einfach da noch drin, ist aber mit 3.0 als explizite USER Variable unnötig geworden

Beat am |

Das habe ich erledigt.

Sehr strange war, dass ich nach dem Klick auf den Admin-Link eine Updateschleife zu 3.0.beta1 durchlaufen musste (ohne mich vorher anzumelden). Nach diesem Quasi-Update sehe ich jedoch nicht die geringste Veränderung. In der Backend-Fusszeile steht immer noch 3.0.0 und auch das Cahngelog zeigt gar nichts von einer neuen Beta-Version. ?

Übrigens: Ich wollte das Serendipity_config_local.inc.php auf www.beatsblog.ch ebenfalls überprüfen. Dort habe ich jedoch keine Berechtigung dazu. Ich finde das irgendwie komisch glaube aber, dass ich das schon einmal bemerkt habe. Kann mir das egal sein oder soll ich deswegen den Manitu-Support anschreiben?

Ian Styx am |

Das mit dem beta Ding hat eventuell (bzw sicherlich) mit deinen Downgrades zu tun.

Ja das ist ein bekanntes und bewußt gesetztes Verhalten bei Manitu und es ist eher unnötig dies als "Fehler" zu deklarieren. Sie versprechen sich davon mehr Sicherheit. Dumm ist nur, wenn man ganz dringend da rein muss, zb weil man sein 503 maintenance mode verbockt hat, oder gerne mit USER Variablen arbeitet.

Für solche Fälle gibt es glaube ich ein Script names fixperm, siehe
https://ophian.github.io/hc/en/faq/#docs-my-upgrade-failed-or-i-cannot-change-permissions-of-my-files
Ich habe es allerfings noch nie für den Manitu Fall angewendet.

Beat am |

Ach nee... das hat damit zu tun, dass ich eine alte Version des serendipity_config_local.inc.php abgeändert und hochgeladen habe. Darin steht nämlich:

$serendipity['versionInstalled']  = '3.0-alpha4';

Was muss ich denn nun da reinschreiben? Wenn ich es auf '3.0.0' ändere, erhalte ich eine leere, weisse Frontendseite. Und ich kann ja eben nicht mal rasch auf beatsblog nachsehen. So doof. ?

Nachtrag: Hat sich erledigt. Nach dem "Update" steht da nun:

$serendipity['versionInstalled']  = '3.0.0';

Ian Styx am |

Das file heißt serendipity_config_local.inc.php. '3.0.0' wäre schon richtig, aber eigentlich jetzt doch unnötig, da du ja den upgrade task bekommen und abgeschlossen hast. Damit schreibt sich diese dann von selbst neu.

Beat am |

Ja, hab's auch grad gemerkt und den Kommentar oben abgeändert.?. Scheint nicht mein Tag zu sein. Ich lasse heute wohl besser die Finger von der Konfiguration...

Ian Styx am |

?

Ich habe übrigens die pure Solution committet mit einigen Änderungen.... ?

Beat am |

Ich schulde Dir noch eine Antwort von wegen Kommentieren per iPhone. Das funktioniert sowohl bei www.beatsblog.ch (mit js) und auch bei www.styx.beatsblog.ch (ohne js).

Was man aber nicht tun sollte: Den Blog mit einem iPad und Safari im Hochformat betrachten Die statische Titelseite und die Blogdarstellung (/frontpage) sieht noch o.k. aus, doch die Single-Entry-View ist zum ? heulen. Da wird in der linken SL der Content dargestellt und umgekehrt. Die rechte Seitenleiste stimmt zwar, doch sollten bei der Auflösung ja generell keine SL angezeigt werden.

Sobald man etwas nach unten scrollt, korrigiert sich SL und Content, doch die Seitenbreite ist viel zu breit. Dies liegt vermutlich am entrypaging-Plugin, welches weit rechts, ausserhalb allem noch dargestellt wird (und deshalb wird wohl auch die Seite incl. SL dargestellt, weil eine bedeutend grössere Bilschirmbreite angenommen wird).

Ich habe dann das entrypaging-Plugin deaktiviert und siehe da: nun stimmt auch die Darstellung auf dem iPad (ohne SL)

Tja: Das entrypaging-Plugin bremst nicht nur die Single-Entry-View, sondern es zerschiesst auch die Darstellung in einem Safari-Browser. Ich muss das wohl -schweren Herzens- killen. ☠

nochmals: Bilder einfügen

Ian Styx am |

Es gibt zwar im CKE diese rote Hilfslinie, die einen Paragraphen ermöglicht, um unter bestimmten Situationen aus solch einer Verklemmung herauszukommen. Aber ich habe es selber schon erlebt, dass diese nicht immer oder immer dort erscheint wo ich sie gerne hätte.
Insofern ist es bei deinem Beipiel besser, vor der Bildeinführung einen leeren Paragraphen in die leere Form zu setzen, dann den Zeiger vor diesen zu platzieren, um dort dann das Bild einzufügen.

Beat Menzi am |

:th_up: Ah, dafür ist diese rote Hilfslinie. Danke! Schon wieder etwas gelernt!

Grid-Verschiebung

Ian Styx am |

Ich hätte fast gesagt NÖ! ABER,
Nur, wenn du einen sehr großen Bildschirm hast und voll aufziehst. Ich habe einen 24'er Zoll, da kann ich das sehen. Aber die default Breite eines Browserfensters sollte doch eher nur bei 2/3 oder 3/4 liegen. Nicht mehr.
Ich glaube, ich habe schon aus diesem Grund irgendwo eine Begrenzung im CSS ausgeführt und mich für größere Screens nicht mehr gekümmert. Das kann man aber sicher anpassen.

Ian Styx am |

Nee, es ist schon prozentual, hängt allerdings davon ab, ob der Inhalt etwas inne hat, das die volle Breite des content Containers ausnutzt, so zb irgendein Container eines Footers, eines Comments oder einer Textzeile die lang genug ist um automatisch umzubrechen etc.

Ian Styx am |

Hmm... Ich fürchte es ist komplizierter als auf meinen ersten und zweiten Blick gedacht...

Beat Menzi am |

Wenn es ist, wie es sein soll, dann stimmt es auch für mich. :th_up:

Die Verschiebung ist ja nicht gross und ich habe das auch nur zufällig bemerkt. Damit kann ich problemlos leben.

Beat Menzi am |

Wobei ich Dir insofern recht gebe, dass in meinen zwei Menüs, wo der Hauptbereich schmaler ist, kein Objekt umbricht oder die volle Breite ausnutzt.

Beat Menzi am |

*STIMMT!*

Ich habe in beiden Menüs Lorem ipsum bis zum Zeilenumbruch eingetragen und somit ist der Hauptbereich auch in voller Breite dargestellt und es zeigen sich keine Unterschiede mehr.

Ian Styx am |

Nee das ist sicherlich nicht absichtsvoll soooo gemeint. Ich hatte wohl nur kein Beispiel an dem mir das selber aufgefallen wäre. Die Frage ist wieviel Energie man jetzt dahinein steckt...

Beat Menzi am |

Keine! Vergiss es einfach! (oder schreibe es ganz zuunterst auf die to-do-list)

Ian Styx am |

:th_up:
Jetzt wo du das raus hast müsstest du nur noch etwas finden was du da zB als zusätzliche Erklärung hineinschreiben kannst. Das müssen ja nicht mehr als 1-3 ununterbrochene Sätze sein.

Beat Menzi am |

8-) Ne, ne, lass mal. Ich behaupte, dass das gar rein niemandem auffällt. :wave:

Beat am |

Ich habe jetzt an den betroffenen Stellen ein "Lorem ipsum"-Text mit span-style-visibility:hidden eingesetzt. Funktioniert tip top!

Archive & homelinks

Ian Styx am |

Jein. Es ist einfach dasselbe wie für die Startseite des Blogs. Ansonsten ist es eben anders wenn man sich auf einer single entry Seite befindet. Da ist HL1 der Titel. Es ist ein Endpunkt.
Bei den Kategorien ist es wieder so wie für Start/ bzw Entries Liste und den Archiven.
Ich finde es gut wie du die Dinge überprüfst und auch mal infragestellst.! Nur so kann man Denkfehler oder Fehler finden und aus den Gewohnheiten ausbrechen. Nur weiter so! ;-)