Jetzt überlege ich mir ernsthaft, ob ich meine eigenen Smileys in der Kommentar-Funktion unterdrücken soll (geht ja in der Plugin-Konfiguration ganz simpel). Ist für Kommentare nun irgendwie doppelt-gemoppelt.
Für mich als Author von Beiträgen braucht es die Smileys aber weiterhin, denn sonst werden mir diese in den älteren Beiträgen nicht mehr angezeigt. Zudem gibt es animierte GIF-Smileys wohl nicht als utf8mb4-Emoji. Das bleibt dann wohl zukünftig dem/den Blog-Author/en vorbehalten.
Shit jetzt geht der reload, der den bereits geschriebenen Content behält, nicht mehr...
Jetzt muss ich alles neu schreiben...
Nein das meinte ich nicht ? und habe es auch nicht behauptet ?. Du hast doch etwas von dort ja, hier nicht oder so geschrieben, worauf ich meinte, dass könne man vielleicht auch per CSS erledigen, da es ja unterschiedlicher Orte betrifft.
Das könnte man mittels Smarty Variablen in den betreffenden Templates auch noch ziemlich finetunen (über gegebene oder nicht gegebene class Selektoren), so dass es entweder nur dich, andere Autoren, oder allgemeine Besucher betrifft.
Beat Post author am |
Ich hoffe, mit "alles neu schreiben" meinst Du nur den Text des letzten Kommentars und nicht all die neu aufgebaute Funktionalität... ?
Was die Smiley-Anzeige anbelangt ticke ich einfacher und ganz pragmatisch (auch aufgrund mangelnden Wissens). Ein Klick im Emoticonchooser-Plugin und die Smileys werden hier (im Frontend-Kommentar-Formular) nicht mehr angezeigt. Besucher/Kommentatoren haben ja jetzt jede Menge an utf8mb4-Emojis auf Knopfdruck verfügbar. Das reicht.
Für mich als Author (oder auch andere Authoren, wenn es denn welche gäbe) stehen die animierten Smileys für Beiträge ja immer noch zur Verfügung. Beim Antworten auf Kommentare kann ich locker darauf verzichten.
Ach, das war mir gar nicht mehr bewusst, dass man das für das frontend only per Option deaktivieren kann. Umso besser!
Beat Post author am |
Info: Habe im Eintrag einen Mobile-Screenshot angefügt, der zeigt, dass die Code-Box nicht vollständig verkleinert.
In meinem Live-Blog wird dies nie zum Problem, weil ich a) nie einen solch hohen Grad von Verschachtelung habe und b) noch nie Code in eine Antwort geschrieben habe.
pre {
min-width: auto;
}
@media screen and (min-width: 640px) {
pre {
min-width: 20em;
}
}
Beat Post author am |
? wie gesagt. Im Live-Blog wird das nie vorkommen und hier im Testblog stört es mich nicht. Und so wie ich Dich bisher kennengelernt habe, dauert es nicht lange, bis ein Update dies fixt. ? ich brauche also nur zu warten...
Fies 2: Ts, ts... ein Code-Button im Frontend-Kommentarformular... wer kommt denn auf so eine Idee?...? das muss ein Programmierer/Entwickler sein, der Leser hat, die in "Puzzle-Rätsel-Code" sprechen/kommentieren... ? ?
Und wer braucht beim Kommentieren Undo/Redo? ? Ein Bild an-/einfügen wäre für Normalos interessanter, doch das ist wohl zu kompliziert und ein Sicherheitsgraus... (war auch nur so ein Gedanke)
PS: Hätte der Frontend-Kommentareditor einen Button weniger, würde die Button-Leiste (auf meinem Handy) nicht umbrechen... ich wüsste ziemlich genau, welchen Button ich weglassen würde ? und Nein, es ist nicht der mit den Emojis... ?
PPS: Hast Du im Kommentar-Plugin rumgespielt? ? Zeilenumbruch nach 47 Zeichen? 141 Zeichen Anzeigelänge? Ich wollte nämlich etwa 10-20 Zeichen hinzugeben, weil jetzt oft am Zeilenanfang oder nach nur wenigen Zeichen Schluss ist. Ist das nur bei mir so? Siehst Du das anders?
Zu F2: Kommt öfter vor als man denkt. Gerade unter "Programmierern/Developern" sind Blog Systeme weit verbreitet und besprechen eine Thematik, die dies für sich und die Leser=Kommentatorenschaft erfordert.
ZU 2: Ja Undo/Redo könnte man rausnehmen, ich hatte nur den Eindruck man könne damit schneller eine Formatierung rückgängig machen. Sonst muss man bei der Markierung immer genau treffen um den Buuton umzustellen. Außerdem gibt es ja keinen Quelltext Button, aus guten Gründen, und so bliebe nur die Löschen Taste.
Zu PS: Das kannst du doch in dem du dir das in deiner index.tpl umstellst bzw herausnimmst.
Zu PPS: Ja, im Zuge der Suche nach den komischen Umbruchverhalten in deinem ehemals kursiven Text. Ich habe grundsätzlich so gedacht, dass drei Zeilen gut und genug sind. Es ist ja nur ein Anriß des echten Comments. Wo genau der Umbruch stattfindet hängt natürlich von der verwendten Schrift und Größe, sowie vom Inhalt ab. Jeder Buchstabe und jedes Bildchen verbraucht variablen Platz, also sind die Einstellungen immer nur annähernd.
Beat Post author am |
Das kannst du doch in dem du dir das in deiner index.tpl umstellst bzw herausnimmst.
SUPER! Danke! Habe Undo/Redo entfernt. Jetzt passt es auch auf dem Mobile! ?
Ian Styx am |
Beat Post author am |
Frontend-Editor? Für Kommentare? Habe ich etwas verpasst?
Habe ihn gerade auf styx.dokumenzu.ch gesehen. Den muss ich hier scheinbar via user.css (unbewusst) unterdrückt haben...
Beat Post author am |
Mit Pure-Theme kommt alles richtig! ?
Ian Styx am |
Nee, du musst natürlich die index.tpl auf "pure-beat" anpassen! ?
(und meinen Kommentar lesen)
Beat Post author am |
besser?
viel BESSER! ? 
? hammermässig gut, dieses Frontend-Editor-Feld! SUPER-gemacht!
Ian Styx am |
Ich sachs ja... something wonderful is going to happen ... ?
Beat Post author am |
JA, danke!
Jetzt hat auch die Diskussion um _unterstreichen_ ein gutes/besseres Ende gefunden.
Ian Styx am |
Update mal deine Plugins ...
Beat Post author am |
Jetzt überlege ich mir ernsthaft, ob ich meine eigenen Smileys in der Kommentar-Funktion unterdrücken soll (geht ja in der Plugin-Konfiguration ganz simpel). Ist für Kommentare nun irgendwie doppelt-gemoppelt.
Für mich als Author von Beiträgen braucht es die Smileys aber weiterhin, denn sonst werden mir diese in den älteren Beiträgen nicht mehr angezeigt. Zudem gibt es animierte GIF-Smileys wohl nicht als utf8mb4-Emoji. Das bleibt dann wohl zukünftig dem/den Blog-Author/en vorbehalten.
Beat Post author am |
Gemacht. Auf was muss ich jetzt achten? ?
Ian Styx am |
Mommmment...! ?
Schau nochmal in deine Plugins... es könnte ja sein... ?
Beat Post author am |
? you made my day!
Ian Styx am |
oder per CSS an bestimmten Orten.. ?
Beat Post author am |
Du meinst: Du magst die animierten Smileys auch? Also nur in der Mobile-View unterdrücken?
Ian Styx am |
Shit jetzt geht der reload, der den bereits geschriebenen Content behält, nicht mehr...
Jetzt muss ich alles neu schreiben...
Nein das meinte ich nicht ? und habe es auch nicht behauptet ?. Du hast doch etwas von dort ja, hier nicht oder so geschrieben, worauf ich meinte, dass könne man vielleicht auch per CSS erledigen, da es ja unterschiedlicher Orte betrifft.
Das könnte man mittels Smarty Variablen in den betreffenden Templates auch noch ziemlich finetunen (über gegebene oder nicht gegebene class Selektoren), so dass es entweder nur dich, andere Autoren, oder allgemeine Besucher betrifft.
Beat Post author am |
Ich hoffe, mit "alles neu schreiben" meinst Du nur den Text des letzten Kommentars und nicht all die neu aufgebaute Funktionalität... ?
Was die Smiley-Anzeige anbelangt ticke ich einfacher und ganz pragmatisch (auch aufgrund mangelnden Wissens). Ein Klick im Emoticonchooser-Plugin und die Smileys werden hier (im Frontend-Kommentar-Formular) nicht mehr angezeigt. Besucher/Kommentatoren haben ja jetzt jede Menge an utf8mb4-Emojis auf Knopfdruck verfügbar. Das reicht.
Für mich als Author (oder auch andere Authoren, wenn es denn welche gäbe) stehen die animierten Smileys für Beiträge ja immer noch zur Verfügung. Beim Antworten auf Kommentare kann ich locker darauf verzichten.
Ian Styx am |
Ja ja, natürlich.. und kopieren hilft auch da.
Ach, das war mir gar nicht mehr bewusst, dass man das für das frontend only per Option deaktivieren kann. Umso besser!
Beat Post author am |
Info: Habe im Eintrag einen Mobile-Screenshot angefügt, der zeigt, dass die Code-Box nicht vollständig verkleinert.
In meinem Live-Blog wird dies nie zum Problem, weil ich a) nie einen solch hohen Grad von Verschachtelung habe und b) noch nie Code in eine Antwort geschrieben habe.
Ian Styx am |
Beat Post author am |
? wie gesagt. Im Live-Blog wird das nie vorkommen und hier im Testblog stört es mich nicht. Und so wie ich Dich bisher kennengelernt habe, dauert es nicht lange, bis ein Update dies fixt. ? ich brauche also nur zu warten...
Ian Styx am |
Fiese ? im ?! ?
Beat Post author am |
Fies 2: Ts, ts... ein Code-Button im Frontend-Kommentarformular... wer kommt denn auf so eine Idee?...? das muss ein Programmierer/Entwickler sein, der Leser hat, die in "Puzzle-Rätsel-Code" sprechen/kommentieren... ? ?
Und wer braucht beim Kommentieren Undo/Redo? ? Ein Bild an-/einfügen wäre für Normalos interessanter, doch das ist wohl zu kompliziert und ein Sicherheitsgraus... (war auch nur so ein Gedanke)
PS: Hätte der Frontend-Kommentareditor einen Button weniger, würde die Button-Leiste (auf meinem Handy) nicht umbrechen... ich wüsste ziemlich genau, welchen Button ich weglassen würde ? und Nein, es ist nicht der mit den Emojis... ?
PPS: Hast Du im Kommentar-Plugin rumgespielt? ? Zeilenumbruch nach 47 Zeichen? 141 Zeichen Anzeigelänge? Ich wollte nämlich etwa 10-20 Zeichen hinzugeben, weil jetzt oft am Zeilenanfang oder nach nur wenigen Zeichen Schluss ist. Ist das nur bei mir so? Siehst Du das anders?
Ian Styx am |
Zu F2: Kommt öfter vor als man denkt. Gerade unter "Programmierern/Developern" sind Blog Systeme weit verbreitet und besprechen eine Thematik, die dies für sich und die Leser=Kommentatorenschaft erfordert.
ZU 2: Ja Undo/Redo könnte man rausnehmen, ich hatte nur den Eindruck man könne damit schneller eine Formatierung rückgängig machen. Sonst muss man bei der Markierung immer genau treffen um den Buuton umzustellen. Außerdem gibt es ja keinen Quelltext Button, aus guten Gründen, und so bliebe nur die Löschen Taste.
Zu PS: Das kannst du doch in dem du dir das in deiner index.tpl umstellst bzw herausnimmst.
Zu PPS: Ja, im Zuge der Suche nach den komischen Umbruchverhalten in deinem ehemals kursiven Text. Ich habe grundsätzlich so gedacht, dass drei Zeilen gut und genug sind. Es ist ja nur ein Anriß des echten Comments. Wo genau der Umbruch stattfindet hängt natürlich von der verwendten Schrift und Größe, sowie vom Inhalt ab. Jeder Buchstabe und jedes Bildchen verbraucht variablen Platz, also sind die Einstellungen immer nur annähernd.
Beat Post author am |
SUPER!
Danke! Habe Undo/Redo entfernt. Jetzt passt es auch auf dem Mobile! ?