XH Core-Styles - Systemschriftart

[frase]

@Christoph [cmb]
Es wird jetzt ziemlich schwierig, kleine Häppchen zu liefern - weil alles mit allem zusammenhängt
Ändere ich das Eine, muss ich das Andere mitändern usw.
Da wird es schwierig bei den DIFFs.

Aber noch eine Frage zum Filebrowser:
SVG können momentan nicht angezeigt werden - wahrscheinlich, weil getimagesize() bei SVGs nicht funktioniert.
Wie ich das als blutiger Laie so sehe, gibt es in View.php nur zwei Stellen, an denen danach gefragt und - wenn es denn geht - das Bild angezeigt wird.
Könnte man diese Bedingungen nicht umformlieren, sodass bei SVG eben die Größe nicht ausgelesen, aber trotzdem das Bild angezeigt wird?
Möchtest du evtl. vorher mal darüber schauen? Oder verschieben wir das auf später? Oder geht da gar nichts?

[cmb]

Es wird jetzt ziemlich schwierig, kleine Häppchen zu liefern - weil alles mit allem zusammenhängt
Ändere ich das Eine, muss ich das Andere mitändern usw.
Da wird es schwierig bei den DIFFs.

Kleine Häppchen schließen umfangreiche Änderungen an diversen Stellen nicht aus. Wenn es also nicht anders sinnvoll möglich ist, dann kann es halt auch ein komplexes Diff werden. Aber es ist wichtig, dort Änderungen zu unterlassen, die nicht wirklich mit der eigentlichen Änderung zusammenhängen. Zum Beispiel keine Umformatierungen, weil man gerade dabei ist, oder hier und da noch eine kleine zusätzliche Nachbesserung.

Auf der anderen Seite ist es klar, dass z.B. Änderungen an solchem Code schnell sehr unübersichtliche Diffs ergeben. Da bietet es sich ggf. an vor den Änderungen zunächst zu Refaktorieren. Heredocs mag ich eigentlich erst ab PHP 7.3, aber da diese Version ja irgendwann vorausgesetzt werden kann, ist es vielleicht schon heute sinvoll, diese hier zu verwenden. Aber auch ein sprintf() hier und da kann hilfreich sein. Oder halt die Markuperzeugung in Templates auslagern.

Aber noch eine Frage zum Filebrowser:
SVG können momentan nicht angezeigt werden - wahrscheinlich, weil getimagesize() bei SVGs nicht funktioniert.

Dieser Code ist sowieso buggy. getimagesize() darf nicht verwendet werden, um zu prüfen, ob eine Datei eine Bilddatei ist. Fileinfo brauchen wir aber zumindest hier auch nicht wirklich. Im Prinzip müsste der fehlerhafte Commit zurückgenommen werden, und statt der fixen Liste von Dateiendungen eben die konfigurierten geprüft werden. Und ja, dann sollte man vielleicht so kleinlich sein, und es akzeptieren, wenn getimagesize() fehlschlägt (und ja, es kann keine SVGs erkennen, und wird es vermutlich auch in absehbarer Zeit nicht, wenn überhaupt jemals), und dann die Größe irgendwie dem Browser überlassen.

[frase]

Aber es ist wichtig, dort Änderungen zu unterlassen, die nicht wirklich mit der eigentlichen Änderung zusammenhängen. Zum Beispiel keine Umformatierungen, weil man gerade dabei ist, oder hier und da noch eine kleine zusätzliche Nachbesserung.
[...]
Da bietet es sich ggf. an vor den Änderungen zunächst zu Refaktorieren.

Okay. Bin mir nicht ganz sicher, ob ich nicht doch schon an anderen Stellen rumgefummelt habe. Ich schicke dir jetzt einfach mal nur die View.php. Theoretisch sollten dort nur sämtliche Inline-Style-Angaben entfernt sein.
Die könntest du vergleichen. Dass das Style-Änderungen nach sich zieht, ist klar.
Ich denke, es ist aber besser, wenn du die stylesheet.css erst später bekommst. Denn die wird komplett anders (und ist sie auch schon).

filebrowser_remove-styles.zip

SVG-Anzeige verschieben wir.

[frase]

@cmb - Christoph
Betrifft: Filebrowser hier

Hier kommen die restlichen geänderten Dateien.

admin.php - schon eingepflegt
\classes\View.php - fehlt noch - siehe meinen letzten Post

neue Dateien:

\tpl\cmsbrowser.html
- Code aufgeräumt
- Inline-Styles und überflüssige Elemente entfernt
- Toggle-Buttons mit FA-Icons erweitert
- gesamte Ausgabe in einen neuen DIV (xhFilebrowserDiv) gepackt (-> verkürzt CSS)
- h1-Überschrift eingefügt (siehe auch weiter unten: \languages)

\tpl\editorbrowser.html
- Code aufgeräumt:
- - u.a. DOCTYPE nach oben, bei style- und script-Tag das type-Attribut entfernt
- Inline-Styles und überflüssige Elemente entfernt
- Toggle-Buttons mit FA-Icons erweitert
- gesamte Ausgabe in einen neuen DIV (xhFilebrowserDiv) gepackt (-> verkürzt CSS)
- (.xhfb_Bg) CSS-Klasse bei File-List angefügt

\css\stylesheet.css
- Diese Datei ist komplett neu.

\languages\default.php ... en.php ... de.php
- neue Sprachvariable für die h1-Überschrift im CMS-Browser eingeführt $plugin_tx['filebrowser']['heading']="Filebrowser";

Bemerkung dazu:
"Filebrowser" ist eine etwas "unglückliche" Bezeichnung.
Eigentlich ist es ja schon ein kleiner "File Manager" (deutsch: Datei-Verwaltung oder Datei-Manager).
Manu(?) hat im TinyMCE-Dialog in filebrowser.js "title: 'File Manager'" stehen, was die Sache besser trifft - aber inkonsistent ist.

---

Dieser Filebrowser ist funktional unverändert.
Er ist optisch nur geringfügig modifiziert - sollte aber wesentlich robuster gegen Beeinflussung durch Template-Styles sein.
Er sollte mit und ohne xhContainer (weitgehend) gleich aussehen (sagen wir mal zu 98% )

filebrowser.zip

[cmb]

Danke, Frank! Ich habe die beiden Änderungen doch zusammengefasst, weil der Zwischenschritt (nur Entfernen der inline Styles) eigentlich nichts bringt.

Auf jeden Fall gefällt es mir! Was halten andere davon? Wer sich nicht mit Git(hub) rumschlagen will, kann sich den Gesamtstand auch direkt herunter laden: https://github.com/cmb69/cmsimple-xh/ar ... d-feel.zip (direkter Download).

"Filebrowser" ist eine etwas "unglückliche" Bezeichnung.
Eigentlich ist es ja schon ein kleiner "File Manager" (deutsch: Datei-Verwaltung oder Datei-Manager).
Manu(?) hat im TinyMCE-Dialog in filebrowser.js "title: 'File Manager'" stehen, was die Sache besser trifft - aber inkonsistent ist.

Ja, Filebrowser ist eine Untertreibung, aber das ist halt der Name des Plugins, und eine Umbenennung könnte mehr verwirren als klären. Ich persönlich tendiere eigentlich dazu, einfach den Pluginnamen (also “Filebrowser”) für die Headings in CMS- und Editorbrowser zu verwenden; zumindest aber sollte es einheitlich sein, also nicht das eine Mal “File Manager” hart kodiert, und das andere Mal sprachspezifisch.

[frase]

Ich persönlich tendiere eigentlich dazu, einfach den Pluginnamen (also “Filebrowser”) für die Headings in CMS- und Editorbrowser zu verwenden; zumindest aber sollte es einheitlich sein, also nicht das eine Mal “File Manager” hart kodiert, und das andere Mal sprachspezifisch.

Da habe ich überhaupt nichts dagegen. Dann müsste Manu "hart umkodieren" auf "Filebrowser" und im Filebrowser könnte die h1-Überschrift ebenfalls hart kodiert werden. Die neue Sprachvariable könnte dann raus.
Übrigens, Frage: default.php gibt es wohl nicht mehr?

[cmb]

Ich persönlich tendiere eigentlich dazu, einfach den Pluginnamen (also “Filebrowser”) für die Headings in CMS- und Editorbrowser zu verwenden; zumindest aber sollte es einheitlich sein, also nicht das eine Mal “File Manager” hart kodiert, und das andere Mal sprachspezifisch.

Da habe ich überhaupt nichts dagegen. Dann müsste Manu "hart umkodieren" auf "Filebrowser" und im Filebrowser könnte die h1-Überschrift ebenfalls hart kodiert werden. Die neue Sprachvariable könnte dann raus.

@manu?

Übrigens, Frage: default.php gibt es wohl nicht mehr?

Die werden für den Core und die internen Plugins automatisch generiert, wenn ein Distro-Zip erstellt wird.

[frase]

Hi, ich bins schon wieder.
Ich habe noch ein mini-Problem bei der Darstellung im CMS-Browser entdeckt.
Betrifft den mittleren Bereich -> Unterordner.
Der Einheitlichkeit wegen, müssten die Kreuze (Buttons) zum Löschen der Ordner vor dem Ordner-Symbol stehen.
Dazu habe ich die View.php überarbeitet. Gleichzeitig habe ich den betreffenden Code so verändert, dass er (für mich) übersichtlicher wird.
Bitte vor evtl. Übernahme prüfen.

filebrowser-view-php.zip

[manu]

Ich persönlich tendiere eigentlich dazu, einfach den Pluginnamen (also “Filebrowser”) für die Headings in CMS- und Editorbrowser zu verwenden; zumindest aber sollte es einheitlich sein, also nicht das eine Mal “File Manager” hart kodiert, und das andere Mal sprachspezifisch.

Da habe ich überhaupt nichts dagegen. Dann müsste Manu "hart umkodieren" auf "Filebrowser" und im Filebrowser könnte die h1-Überschrift ebenfalls hart kodiert werden. Die neue Sprachvariable könnte dann raus.
Übrigens, Frage: default.php gibt es wohl nicht mehr?

Kein Problem. Es fragt sich letztendlich, ob "Filebrowser" ein statischer Name ist, oder hier der Name des Plugins reinsoll (wobei "hi_kcfinder" ist dann als Titel schon wieder eher verwirrend als erhellend). Ich meine daher: statischer Name.
Ich finde übrigens das Design des filebrowsers sehr gelungen. Typisch Flachnasendesign wie es jetzt Mode ist.

[cmb]

Dazu habe ich die View.php überarbeitet. Gleichzeitig habe ich den betreffenden Code so verändert, dass er (für mich) übersichtlicher wird.

Das ist genau das, was wir möglichst vermeiden wollen. Immer wenn eine Commit-Message etwas wie „gleichzeitig“ oder „wo wir gerade dabei sind“ enthält (oder schon ein einfaches “und” in der Commit-Überschrift), dann sollte man stutzig werden, denn dann kann es sein, dass mehrere Änderungen in einem Patch durchgeführt werden; siehe Tow changes in one patch. In diesem Fall kann das Vertauschen der “Buttons” und das Umformatieren des Codes prima in separaten Commits erfolgen. Allerdings verstößt diese Umformatierung eigentlich gegen unsere Coding Standards, so dass ich zunächst lieber darauf verzichten würde. Daher habe ich nur die Vertauschung der Buttons eingecheckt.

Ach ja, bezüglich der Lösch-Icons: das x ist für mich okay, aber dann sollten wir unbedingt das Schließen-Icon in den Pagedata-Reitern ändern, weil das eigentlich gleich aussieht, aber eine ganz andere Funktion erfüllt. Ideen? Vielleicht fa-window-close oder fa-window-close-o?

Es fragt sich letztendlich, ob "Filebrowser" ein statischer Name ist, oder hier der Name des Plugins reinsoll (wobei "hi_kcfinder" ist dann als Titel schon wieder eher verwirrend als erhellend). Ich meine daher: statischer Name.

Da schließe ich mich an, zumal andere Dateimanager ihre eigene filebrowser.js haben, und dort den title selbst wählen können (ist bei hi_kcfinder zur Zeit „KCFinder“).

Jedenfalls habe ich nun “Filebrowser” auch in cmsbrowser.html hart kodiert.