Grrr... ? Stimmt. Mit dem pure-Theme sind die Seitenleisten wieder so breit wie zuvor und auch Kommentieren mit dem Adroid-Mobile funktioniert. Hmmm... muss mir wohl das style.css und mein user.css zur Brust nehmen...
Jetzt fehlt doch eigentlich nur noch deine user.css. Wo ist sie denn?
Beat Post author am |
habe die neue (pure) index.tpl nun für pure-beat abgeändert (Search und Mobile-Footer raus, Google-Fonts und Scroll-to-top rein). Rein optisch stimmt es soweit.
Doch: Sobald ich das Theme auf pure-beat umstelle, geht das Kommentieren per Android micht mehr. Mit pure Original funktioniert das... grübel... (die Entfernung von js und die entsprechenden CSS-Anpassungen habe ich nur auf styx.beatsblog.ch vorgenommen und nicht hier)... Ah. ok. ich könnte mal das user.css umbenennen, damit ich ausschliessen kann, dass es an der abgeänderten index.tpl liegt...
Kann ich jetzt einfach die Templateverzeichnisse pure und pure-beat in den aktiven Live-Blog kopieren oder sollte ich dort auch besser die neusten 3.01.DEV Dateien aufspielen?
Ja, das kannst du genauso machen, oder sogar nur die wirklich geänderten files.
Alles andere ist nicht wichtig, wenn du nicht anfängst herumzuspielen. Das kann dann warten bis die 3.0.1 erscheint.
Beat Post author am |
Habe hier nur etwas rumgespielt. Ich wollte herausfinden, wie ich einen zweiten Google Schriftfont einbringen kann um diesen z.B. für Titel zu verwenden.
Hm, hast du wohl geschafft.
Ähem, sieht aber "weniger gut" aus! Und verwirrt.
Beat Post author am |
Ja, hat mich auch nicht wirklich überzeugt. Wobei die grundsätzliche Idee, Titel und Content mit verschiedenen Schriftarten zu gestalten finde ich schon interessant.
Es gibt in meinem Kopf aber auch noch eine entgegengesetzte Idee. Grundsätzlich möchte ich meinen Blog so unabhängig wie möglich betreiben. Ich war froh, als ich reChapta rausschmeissen konnte und so gibt es auch die Überlegung, auf die Einbindung von Google Fonts zu verzichten. Ich könnte den Raleway-Font doch auch downloaden und selber hosten.(?) Das würde dann auch die index.tpl um einen externen Link reduzieren, was vermutlich der Geschwindigkeit (minimal) zu Gute kommen würde.
Grundsätzlich ist ja die Idee externer font Quellen genau die: Entlastung des eigenen Servers. Also das, was CDNs für weitere assets bieten sollen. Dumm ist eben, dass man sich einen Mithörer ins eigene Boot holt. Was ich nicht sagen kann ist, ob jeder Request (d)einer Seite, egal ob der Font dann tatsächlich ausgeliefert wird oder nicht, auch zu so einer Art versteckter Analytik führt. Anzunehmen ist es. Und mehrt den Datenreichtum anderer. Insofern wäre es mir privat auch immer lieber, man würde eben auf alles Externe sowet wie möglich verzichten.
Zu Raleway (im Banner) passt übrigens Lato. Ein schöner font! Aber dann eher für alles. Die Lesbarkeit hat aber auch mit Zeilenabstand und Buchstabenanstand zu tun. Das ist fast eine Wissenschaft für sich.
Beat Post author am |
Also, ich liefere nun Raleway ab eigenem Server. Nachdem ich das hier testete, kopierte ich die Fonts und die angepasste index.tpl sowie user.css nach www.styx.beatsblog.ch. Via Pingdom.com habe ich die Startseite gemessen.
Im heutigen Klausen-und-Pragel-bei-starkem-Foehn werden noch alle Bilder in mini gestyled, obwohl bereits die 300x400 Version geladen wird. Also einfach in diesem Eintrag alle width und height Attribute der images herausnehmen.
Gibt es aus deiner Sicht noch etwas zu verbessern bzw zu fixen für die 3.0.1 ?
Beat Post author am |
Ich falle auch immer wieder darauf herein: Hier auf blog.dokumenzi.ch sind noch immer die kleinen Vorschaubilder. Geändert habe ich das nur auf beatsblog.ch und styx.beatsblog.ch (und dort werden auch die grossen Vorschaubilder angezeigt).
Gibt es aus deiner Sicht noch etwas zu verbessern bzw zu fixen für die 3.0.1 ?
Nein, dazu fällt mir nichts ein.
Aber: Ich kämpfe schon seit immer mit Cookie-Problemen. Ich habe das nie erwähnt, weil ich das Problem lokal orte und auch vermute, dass sich meine insgesamt 6 verschiedenen S9Y-Installationen gegenseitig irgendwie in die Quere kommen. Das äussert sich so:
- beim Hochladen von neuen Bildern wird mir immer das Verzeichnis "Verkauf" vorgeschlagen. Egal, wie oft ich auch das Verzeichnis "2020" anwähle. Wenn ich alle Cookies aus dem Browser lösche, sehe ich beim ersten Hochladen "Stammverzeichnis", doch selbst wenn ich dann ein Bild in "2020" hochlade, wird mir beim nächsten Upload wieder "Verkauf" angezeigt.
- Wenn ich einen neuen Beitrag schreibe, wird mir standardmässig immer der Tag "BeatsBlog" ausgefüllt, obwohl es diesen Tag gar nicht gibt. Ich muss diesen Vorschlag jedesmal manuell löschen. Cookies aus dem Browser löschen bringt hier gar nichts. Auch beim ersten neuen Beitrag danach wird mir wieder "BeatsBlog" vorausgefüllt.
Werden Cookies irgendwo in der DB gespeichert? Kann man die quasi serverseitig löschen?
Beat Post author am |
Bei mir spukt die Mediathek. Ich erhalte nicht mehr als 50 Dateien pro Seite dargestellt. Bei 96 oder 100 Bildern erhalte ich eine leere, blanke Seite.
Noch was: Wenn ich in der Mediathek 4 Bilder nebeneinander darstellen lasse (z.B. 4x12=48) und dann eine Seite blättere, erhalte ich danach wieder die Standardansicht mit 2 Bildern (2x24=48). Dann klicke ich wieder auf das Symbol für "4-column grid" was auch prompt ausgeführt wird. Wenn ich wieder eine Seite wechsle, erhalte ich aber wieder eine 2-Bilder-Ansicht. Das Gleiche passiert auch bei "3-column grid".
Dss ist das Cookie serendipity[addmedia_directory]:"Verkauf". Cookies werden immer Clientseitig gespeichert.
Das sieht mir nach einem Fehler aus. Wahrscheinlich in beiden Fällen.
Nachfrage: Für den letzteren wird dir ein freetag mit diesem Namen ausgefüllt?
Beat Post author am |
Das ist das Cookie serendipity[addmedia_directory]:"Verkauf". Cookies werden immer Clientseitig gespeichert.
Wo denn? Ich kriege das in FireFox, Einstellungen, Datenschutz & Sicherheit, Cookies und Website-Daten, Daten entfernen... nicht los. Und weshalb habe ich nun schon wieder 33 Cookies von www.beatsblog.ch im Browser gespeichert, obwohl ich vor etwa 1 Std. alle Cookies gelöscht habe?
Nachfrage: Für den letzteren wird dir ein freetag mit diesem Namen ausgefüllt?
Ja, das passiert immer, wenn ich auf neuen Beitrag erstellen klicke. Wenn ich nur schon einen Titel vergebe und den Beitrag ansonsten leer abspeichere, kriegt er denTag "BeatsBlog" mit. Diesen gibt es eigentlich gar nicht und falls ich mal vergesse ihn aus einem Artikel zu löschen, so korrigiere ich das später über "Tags verwalten", in dem ich den Tag lösche.
Ich sagte ja das ist ein Fehler. Ich weiß auch schon genau wo.
Andereseits schaust du auch falsch. Sie sind in den Developer Tools [F12] unter Web-Spiecher - Cookies zu finden. Sie werden natürlich auch immer wieder neu erstellt, weil das essentielle Comfort Cookies des Backends sind. Die will man/du doch gar nicht löschen....!
Beat Post author am |
Grrr... ? Stimmt. Mit dem pure-Theme sind die Seitenleisten wieder so breit wie zuvor und auch Kommentieren mit dem Adroid-Mobile funktioniert. Hmmm... muss mir wohl das style.css und mein user.css zur Brust nehmen...
Ian Styx am |
Nein Nein. Höchstens um Änderungen aus dem Vorversuch zu entnehmen.
Es liegt m.E. an dem veränderten index.tpl.
Beat Post author am |
Hörst Du mich stöhnen... ?
Ian Styx am |
Ein bisschen lauter...❗ wie meinen ⁉ ?
Ian Styx am |
Jetzt fehlt doch eigentlich nur noch deine user.css. Wo ist sie denn?
Beat Post author am |
habe die neue (pure) index.tpl nun für pure-beat abgeändert (Search und Mobile-Footer raus, Google-Fonts und Scroll-to-top rein). Rein optisch stimmt es soweit.
Doch: Sobald ich das Theme auf pure-beat umstelle, geht das Kommentieren per Android micht mehr. Mit pure Original funktioniert das... grübel... (die Entfernung von js und die entsprechenden CSS-Anpassungen habe ich nur auf styx.beatsblog.ch vorgenommen und nicht hier)... Ah. ok. ich könnte mal das user.css umbenennen, damit ich ausschliessen kann, dass es an der abgeänderten index.tpl liegt...
Ian Styx am |
Ähem ... ist deine beat pure.js schon angepasst? ?
Beat Post author am |
Ian Styx am |
Yepp! ?
Beat Post author am |
Kann ich jetzt einfach die Templateverzeichnisse pure und pure-beat in den aktiven Live-Blog kopieren oder sollte ich dort auch besser die neusten 3.01.DEV Dateien aufspielen?
Ian Styx am |
Ja, das kannst du genauso machen, oder sogar nur die wirklich geänderten files.
Alles andere ist nicht wichtig, wenn du nicht anfängst herumzuspielen. Das kann dann warten bis die 3.0.1 erscheint.
Beat Post author am |
Habe hier nur etwas rumgespielt. Ich wollte herausfinden, wie ich einen zweiten Google Schriftfont einbringen kann um diesen z.B. für Titel zu verwenden.
Ian Styx am |
Hm, hast du wohl geschafft.
Ähem, sieht aber "weniger gut" aus! Und verwirrt.
Beat Post author am |
Ja, hat mich auch nicht wirklich überzeugt. Wobei die grundsätzliche Idee, Titel und Content mit verschiedenen Schriftarten zu gestalten finde ich schon interessant.
Es gibt in meinem Kopf aber auch noch eine entgegengesetzte Idee. Grundsätzlich möchte ich meinen Blog so unabhängig wie möglich betreiben. Ich war froh, als ich reChapta rausschmeissen konnte und so gibt es auch die Überlegung, auf die Einbindung von Google Fonts zu verzichten. Ich könnte den Raleway-Font doch auch downloaden und selber hosten.(?) Das würde dann auch die index.tpl um einen externen Link reduzieren, was vermutlich der Geschwindigkeit (minimal) zu Gute kommen würde.
Ian Styx am |
Grundsätzlich ist ja die Idee externer font Quellen genau die: Entlastung des eigenen Servers. Also das, was CDNs für weitere assets bieten sollen. Dumm ist eben, dass man sich einen Mithörer ins eigene Boot holt. Was ich nicht sagen kann ist, ob jeder Request (d)einer Seite, egal ob der Font dann tatsächlich ausgeliefert wird oder nicht, auch zu so einer Art versteckter Analytik führt. Anzunehmen ist es. Und mehrt den Datenreichtum anderer. Insofern wäre es mir privat auch immer lieber, man würde eben auf alles Externe sowet wie möglich verzichten.
Zu Raleway (im Banner) passt übrigens Lato. Ein schöner font! Aber dann eher für alles. Die Lesbarkeit hat aber auch mit Zeilenabstand und Buchstabenanstand zu tun. Das ist fast eine Wissenschaft für sich.
Beat Post author am |
Also, ich liefere nun Raleway ab eigenem Server. Nachdem ich das hier testete, kopierte ich die Fonts und die angepasste index.tpl sowie user.css nach www.styx.beatsblog.ch. Via Pingdom.com habe ich die Startseite gemessen.
Google Fonts: 33 Requests, Size = 741 kb, Load-Time = 943 msec. (Content-Size & -Requests = 91% beatsblog)
Lokale Fonts: 31 Requests, Size = 657 kb, Load-Time = 958 msec. (Content-Size & -Requests = 100% beatsblog)
Geschwindigkeitsmässig ist das nahezu identisch. Das Ganze ist also eher eine ideologische Frage.
Beat Post author am |
Habe www.beatsblog.ch nun entsprechend angepasst.
Ian Styx am |
Im heutigen Klausen-und-Pragel-bei-starkem-Foehn werden noch alle Bilder in mini gestyled, obwohl bereits die 300x400 Version geladen wird. Also einfach in diesem Eintrag alle width und height Attribute der images herausnehmen.
Gibt es aus deiner Sicht noch etwas zu verbessern bzw zu fixen für die 3.0.1 ?
Beat Post author am |
Ich falle auch immer wieder darauf herein: Hier auf blog.dokumenzi.ch sind noch immer die kleinen Vorschaubilder. Geändert habe ich das nur auf beatsblog.ch und styx.beatsblog.ch (und dort werden auch die grossen Vorschaubilder angezeigt).
Nein, dazu fällt mir nichts ein.
Aber: Ich kämpfe schon seit immer mit Cookie-Problemen. Ich habe das nie erwähnt, weil ich das Problem lokal orte und auch vermute, dass sich meine insgesamt 6 verschiedenen S9Y-Installationen gegenseitig irgendwie in die Quere kommen. Das äussert sich so:
- beim Hochladen von neuen Bildern wird mir immer das Verzeichnis "Verkauf" vorgeschlagen. Egal, wie oft ich auch das Verzeichnis "2020" anwähle. Wenn ich alle Cookies aus dem Browser lösche, sehe ich beim ersten Hochladen "Stammverzeichnis", doch selbst wenn ich dann ein Bild in "2020" hochlade, wird mir beim nächsten Upload wieder "Verkauf" angezeigt.
- Wenn ich einen neuen Beitrag schreibe, wird mir standardmässig immer der Tag "BeatsBlog" ausgefüllt, obwohl es diesen Tag gar nicht gibt. Ich muss diesen Vorschlag jedesmal manuell löschen. Cookies aus dem Browser löschen bringt hier gar nichts. Auch beim ersten neuen Beitrag danach wird mir wieder "BeatsBlog" vorausgefüllt.
Werden Cookies irgendwo in der DB gespeichert? Kann man die quasi serverseitig löschen?
Beat Post author am |
Bei mir spukt die Mediathek. Ich erhalte nicht mehr als 50 Dateien pro Seite dargestellt. Bei 96 oder 100 Bildern erhalte ich eine leere, blanke Seite.
Noch was: Wenn ich in der Mediathek 4 Bilder nebeneinander darstellen lasse (z.B. 4x12=48) und dann eine Seite blättere, erhalte ich danach wieder die Standardansicht mit 2 Bildern (2x24=48). Dann klicke ich wieder auf das Symbol für "4-column grid" was auch prompt ausgeführt wird. Wenn ich wieder eine Seite wechsle, erhalte ich aber wieder eine 2-Bilder-Ansicht. Das Gleiche passiert auch bei "3-column grid".
Ian Styx am |
? ach ja...
Dss ist das Cookie serendipity[addmedia_directory]:"Verkauf". Cookies werden immer Clientseitig gespeichert.
Das sieht mir nach einem Fehler aus. Wahrscheinlich in beiden Fällen.
Nachfrage: Für den letzteren wird dir ein freetag mit diesem Namen ausgefüllt?
Beat Post author am |
Wo denn? Ich kriege das in FireFox, Einstellungen, Datenschutz & Sicherheit, Cookies und Website-Daten, Daten entfernen... nicht los. Und weshalb habe ich nun schon wieder 33 Cookies von www.beatsblog.ch im Browser gespeichert, obwohl ich vor etwa 1 Std. alle Cookies gelöscht habe?
Ja, das passiert immer, wenn ich auf neuen Beitrag erstellen klicke. Wenn ich nur schon einen Titel vergebe und den Beitrag ansonsten leer abspeichere, kriegt er denTag "BeatsBlog" mit. Diesen gibt es eigentlich gar nicht und falls ich mal vergesse ihn aus einem Artikel zu löschen, so korrigiere ich das später über "Tags verwalten", in dem ich den Tag lösche.
Ian Styx am |
Ich sagte ja das ist ein Fehler. Ich weiß auch schon genau wo.
Andereseits schaust du auch falsch. Sie sind in den Developer Tools [F12] unter Web-Spiecher - Cookies zu finden. Sie werden natürlich auch immer wieder neu erstellt, weil das essentielle Comfort Cookies des Backends sind. Die will man/du doch gar nicht löschen....!
Beim freetag muss ich erst noch schauen.
Ian Styx am |
Das hatten wir schon mal (gefragt und erklärt). Da wird kein Cookie gesetzt. Es ist eine Ein-Mal-Ad-Hoc-Ansicht.