WBCE Home | WBCE Hilfe | WBCE Addon Repository | Impressum | Datenschutz

WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 18.07.2019 14:50:02

rjgamer
Developer

Modul Style Guidelines

Mal wieder ich: Es würde WBCE echt guttun, wenn man sich auf gewisse Style Guidelines einigen würde. Die unterschiedlichen UIs der Module sind echt nicht hübsch anzusehen. Aber wie schon seit Jahren: Nur meine persönliche Meinung  kiss

Offline

Liked by:

giz

#2 18.07.2019 15:03:04

florian
Administrator

Re: Modul Style Guidelines

Es würde WBCE echt guttun, wenn man sich auf gewisse Style Guidelines einigen würde.

Ja, finde ich grundsätzlich auch. Allerdings bleibe ich dabei, dass der Aufwand, alles auf Bootstrap umzustellen, zu hoch ist.

Bei Bakery mache ich zudem nur das nötigste, weil wenn man da einmal anfängt, kommt man vom Hölzchen zum Stöckchen, und es ist ja leider auch fraglich, wie lange das Modul überhaupt noch einsetzbar ist (gewachsener Code, PHP-Kompatibilität).

Last edited by florian (18.07.2019 15:03:26)

Offline

#3 18.07.2019 18:37:13

webbird
Administrator

Re: Modul Style Guidelines

Style Regeln und einheitliche GUI heißt ja nicht automatisch Bootstrap. wink Nicht mal zwangsläufig _irgendein_ Framework.

Es gab mal die Regel, dass CSS-Klassen in Modulen einen modulspezifischen Prefix haben müssen, das würde zumindest das eine oder andere Problem vermeiden.

Bei den unterschiedlichen Backend Themes ist es aber ohnehin schwierig, für ein einheitliches Bild zu sorgen.

Wünschenswert wäre es aber auf jeden Fall.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

#4 18.07.2019 18:49:55

bernd
Developer

Re: Modul Style Guidelines

Das war ja einer der Gründe warum ich vor Urzeiten bei den Arbeiten am Argos-Reloaded schon eingeführt hatte die Module zumindest in ein div mit entsprechenden Klassen zu packen.
Bei den Admin-Tools z.B.:

echo '<div class="adminModuleWrapper '.$toolDir.'">';
require WB_PATH.'/modules/'.$toolDir.'/tool.php';
echo '</div>';

Damit hätte man wenigsten eine kleine Chance allzuschlimme "Ausrutscher" der Modul-Entwickler auf Backend-Theme Ebene abzufedern.
Ist halt nur eine Sch... Arbeit  devil


2 x ROT13 hält besser ...

Online

#5 18.07.2019 19:05:12

florian
Administrator

Re: Modul Style Guidelines

Beiträge aus dem Ursprungsthread herausgelöst

Offline

#6 18.07.2019 19:28:12

rjgamer
Developer

Re: Modul Style Guidelines

florian wrote:

Ja, finde ich grundsätzlich auch. Allerdings bleibe ich dabei, dass der Aufwand, alles auf Bootstrap umzustellen, zu hoch ist.

Vor zwei Jahren hättest du mich zu 100% auf deiner Seite gehabt, wenn du mir gesagt hättest ich soll die wichtigsten Module auf Bootstrap umschreiben und WBCE wird im Backend zu 100% Bootstrap voraussetzen. Ich dachte ne zeitlang sogar darüber nach das WBCE zu forken, UI-mässig auf Bootstrap anzupassen und die Module zu vereinheitlichen.

Meine Aussage war eher nostalgisch und ich wollte eigentlich keine neue Diskussion, geschweige einen Thread eröffnen. Dass ich WBCE als Anwender nicht mehr einsetzen werde, ist zu 100% klar. Nur aber mit einem weinenden Auge, da die Community die florian hier aufgebaut hat schon recht toll ist  thumb_up

Last edited by rjgamer (18.07.2019 19:29:57)

Offline

#7 19.07.2019 09:32:35

webbird
Administrator

Re: Modul Style Guidelines

Warum nicht? Da ist doch absolut nichts verkehrt dran. Bei WB wurden solche Diskussionen immer schnell abgewürgt, hier wird das sicherlich nicht der Fall sein. Man kann doch zumindest einen Regelsatz zusammenstellen, z.B. dass Module ihre Ausgabe immer in ein DIV kapseln sollen, das eine modulspezifische Klasse hat, auch wenn man da gar nichts mit stylen will. (Mach ich immer.) Oder eben das mit dem Präfix. Wenn 5 Module auf einer Seite eine CSS-Klasse namens .content verwenden, _kann_ das ja nur Kuddelmuddel geben. Heißt die Klasse aber z.B. .mod_nwi_content, ist das weitestgehend ausgeschlossen.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

berny

#8 19.07.2019 10:59:21

boeseroeser
Guest

Re: Modul Style Guidelines

Für Standards bin ich grundsätzlich immer zu haben.

Als Modulentwickler ist es mir auch grundsätzlich egal, wie die Klassen heißen, solange sie funktionieren und halbwegs vernünftig passen.

Sprich: Wenn mir jemand sagt: Nenne den Absenden-Schalter <button class="unserstandardabsendenschalter"...> statt <input class="meingeheimding"..>  - dann nehme ich den Standard, ist mir doch wurscht, spare ich mir Arbeit und Gedanken.
Aber: Sagt es mir jemand?

Bootstrap: Naja, einfach Bootstrap reinhängen und fertig - das wird nichts.

BS ist umfangreich und man braucht nur 1% davon. Es ist einem Modulentwickler nicht zuzumuten, sich da durchzuackern und "sein" 1% herauszusuchen. Auch führt das nicht zu mehr Einheitlichkeit, weil es innerhalb von BS wieder 30 Möglichkeiten gibt.
Da müsste es also wieder jemanden geben, der den Überblick hat und sagt, was wo wie sein soll.

Da kann man dann gleich sagen: Wir holen das 1% das wir brauchen raus, und das ist unser Styleguide und der ist so und so anzuwenden. Und zwar über alle Backend-Themes hinweg, tw auch fürs Frontend.
Aber: Wer macht das?

Liked by:

stefanek

#9 19.07.2019 11:04:55

stefanek
Developer

Re: Modul Style Guidelines

Ein großer Teil des Style-Guides wird sich aus den Modulen des CMS selbst ergeben. (Module wie Settings, Media, Groups, Pages etc.)

Alles andere: Was wird denn eurer Meinung nach benötigt? Wo hackt es. Wo gibt es die größten Probleme?


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#10 19.07.2019 11:14:58

florian
Administrator

Re: Modul Style Guidelines

Wir hatten diese Diskussion vor drei Jahren schon mal, es gab sogar vielversprechende Ansätze (siehe Links unten), das ist dann irgendwie versandet.
Was ich mir wünschen würde, wäre ein einfaches Framework, das einem die Arbeit erleichtert, wo man mit wenig Code einfach zum Ziel kommt.
Sprich, dass es einfache div-Klassen gibt, um Feldbeschreibungen / Eingabefelder nebeneinander zu platzieren und vorgegebene Button-Klassen für Speicher, Speichern und Zurück, Abbrechen. Mehr braucht es eigentlich nicht.
https://forum.wbce.org/viewtopic.php?pid=5385#p5385
https://forum.wbce.org/viewtopic.php?pid=5048#p5048

Offline

#11 19.07.2019 11:15:55

stefanek
Developer

Re: Modul Style Guidelines

Das ist ja alles hier vorhanden und wird mit dem Umbau auf Twig bereits umgesetzt.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#12 19.07.2019 11:17:24

stefanek
Developer

Re: Modul Style Guidelines

Man kann das in Aktion sehen, den Ansatz davon, im Modul-Backend von der Sitemap.
Dort ist es allerdings auf Modul-Ebene gesetzt, noch nicht global für das ganze Backend.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#13 19.07.2019 11:30:39

boeseroeser
Guest

Re: Modul Style Guidelines

Es gibt wohl Dinge, die historisch gewachsen sind und die man eben mal so beibehält: Speichern-Schalter links, Abbruch-Schalter rechts usw.
Da wurde und wird ja üblicherweise von anderen Modulen kopiert, sodass das nicht allzuweit auseinandergelaufen ist.
Aber man kann ja durchaus mal sagen: Das ist eine Standard-Modulseite (ohne Funktion) - kopiere bitte nur von dort, wenns leicht geht.

Was mich übrigens immer etwas stört ist dass die Module in der modify.php so zusammenwachsen, dass man oft gar nicht mehr erkennt, was wohin gehört.

So insgesamt zur Einheitlichkeit:
Ich habe zb Topics bewusst etwas anders gemacht, damit ein Nutzer gleich merkt: Das ist jetzt was anderes, da bin ich nicht in der Seitenverwaltung.
Ich finde es grundsätzlich NICHT schlecht, wenn Module, die anders sind, auch etwas anders aussehen. zb die Farbe der Buttons. In aller Regel hab ich ja zu 90% WYSIWYG-Seiten, 1-2 Formulare und vielleicht noch eine Gallery.

Wenn in der Verwaltung die "unüblichen" Module stärker auffallen, ist das imho kein Nachteil.

#15 19.07.2019 11:38:39

stefanek
Developer

Re: Modul Style Guidelines

Man kann ja von der Entwicklerseite (WBCE) nicht unbedingt bestimmen, wie Module auszusehen haben.
Guidelines sollten Richtungsweisend aber nicht obligatorisch sein.
Das Backend des Systems sollte auf jeden Fall einheitlich sein, weitestgehend auch der mit ausgelieferten Module und Tools.

Edit: häufig verwendete Module die aber nicht mehr vom ursprünglichen Entwickler gepflegt werden, kann man natürlich dann auch anpassen. Und auch jeder Entwickler der Sinn darin sieht, das Backend zu vereinheitlichen, auch mit seinem Modul.
Originalität hier und da wird aber nicht schaden.

Last edited by stefanek (19.07.2019 11:40:53)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#16 19.07.2019 11:46:18

stefanek
Developer

Re: Modul Style Guidelines

Grad überflogen.
An meiner Meinung hat sich seit gefühlten 20 Jahren nichts geändert.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#17 19.07.2019 13:47:18

boeseroeser
Guest

Re: Modul Style Guidelines

Jeder Modulentwickler wird darauf achten, dass das Modul mit älteren oder auch "Classic" ;-) Versionen funktioniert, wenn es keine triftigen Gründe gibt, das anders zu halten. Wenn es einen brauchbaren Style-Guide gibt - und der lässt sich damit vereinbaren! - wird man sich wohl daran halten.

Insofern kann es nur um Details gehen, die so oder so funktionieren; im Idealfall einfach die generischen HTML-Tags mit ein paar Classes dazu.
Button, inputs usw.

Tabellen:
Wer es noch nicht weiß: Die Dinger haben Vorteile, zumindest den, dass die Elemente auch ohne CSS so halbwegs am Platz halten. Wenn ich keine Tabellen nutze, MUSS ich CSS nutzen. Da gibt es dann oft die seltsamsten Ersatz-Konstrukte, (zb mit ul, li und span), die sehr unpraktisch sind.
Wenn die Nachteile von Tabellen überwiegen (zb am Handy) macht man per display:block; einfach divs draus.

Über "Code-Qualität" braucht man gar nicht diskutieren. Das wichtigste ist, dass es ein Modul gibt. Dann: Dass es gut funktioniert und brauchbar aussieht. Dann noch 13 andere Kriterien - und dann erst mal die subjektiv empfundene "Code-Qualität" nach Hildegard von Bingen oder sonst wem.
So halte ich das, und wahrscheinlich auch Ruud.

Prefixes
Der Modulname ist meist zu lang und sperrig.
Ich hab mir angewohnt, ein Kürzel aus 2-4 Buchstaben zu verwenden. Die dann dafür überall: IDs, CSS-Classes, JS und PHP (Functions und Variable mit größerem Geltungsbereich)
gup_ (GlobalUpload), tp_ (Topics), gc_ (GlobalComments), tsrs_ (Teasers), rfg_, tnl_  usw. Nicht immer, aber zumindest bei den Neueren.
Das halte ich für praktikabel.

#18 19.07.2019 13:55:31

stefanek
Developer

Re: Modul Style Guidelines

boeseroeser wrote:

Jeder Modulentwickler wird darauf achten, dass das Modul mit älteren oder auch "Classic" ;-) Versionen funktioniert

nope


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

Liked by:

florian

#19 19.07.2019 14:40:38

boeseroeser
Guest

Re: Modul Style Guidelines

stefanek wrote:
boeseroeser wrote:

Jeder Modulentwickler wird darauf achten, dass das Modul mit älteren oder auch "Classic" ;-) Versionen funktioniert

nope

Bei Core-Modulen - die ohnehin immer gleichzeitig mit einer neuen WBCE-Version ausgeliefert werden - ist das natürlich was anderes. Da muss man keine Rücksicht nehmen.
Darum sind auch die Core-Module die ersten Kandidaten für eine Standardisierung  jeder Art. Erst wenn das gemacht ist, werden andere folgen.

Bei anderen Modulen halst man sich ordentlich Probleme auf, wenn man den Anwenderkreis allzu knapp hält - außer man ist dann ohnehin der einzige, der ein Modul verwendet.

#20 19.07.2019 14:46:07

webbird
Administrator

Re: Modul Style Guidelines

Neben den Boliden wie Bootstrap existieren auch einige sehr brauchbare Mini-Frameworks, die sich wirklich auf die Grundlagen konzentrieren. Florian verwendet ja einige davon.

Abgesehen von unterschiedlichen Themes würde es mir gefallen, wenn es dazu sowas wie Colorsets gäbe. So ähnlich wie Bootswatch für Bootstrap. Bei BC geht sowas mit den sogenannten Varianten, bei WBCE könnte man es im einfachsten Fall so halten, dass man entweder mehrere <colorset>-backend.css mitliefert und der Anwender benennt sich dann die um, die er verwenden will, oder durch Setzen einer Klasse im Body-Tag des Themes. Beides keine allzu schwierigen Eingriffe.

Man kann sich ja auch das, was man braucht, schön zusammenstellen, z.B.

* Für Icons FontAwesome
* Für Grid XXX
* Für Whatever YYY

Ich habe mich bei BC2 letztlich für Bootstrap entschieden, weil es halt Quasi-Standard ist und wenn man sich mal reingefunden hat viel bietet, so dass man nicht immer wieder alles neu zusammensuchen muss, ich bin aber nicht unbedingt ein Verfechter. Ich würde sagen ich habe mich dran gewöhnt, schaue aber auch immer wieder mal, was die Konkurrenz so zu bieten hat. Mit ein wenig Cherrypicking kriegt man sicherlich auch was Brauchbares zusammen.


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

Liked by:

florian, bernd

#21 19.07.2019 15:18:00

webbird
Administrator

Re: Modul Style Guidelines


Ich habe eine Amazon-Wishlist. wink
Erfolgreich vom eigentlichen Problem ablenken kann auch eine Lösung sein.

Offline

#22 19.07.2019 15:35:12

stefanek
Developer

Re: Modul Style Guidelines

Îch wiederspreche hier gerne.
Grade dann kann der Verzicht auf Konventionen sinnvoll sein, wenn man Kollisionen mit weiteren Frameworks vermeiden will.

So halte ich es weiterhin so, dass zusätzliche Backend Themes weiterhin mit z.B. Bootstrap gemacht werden können.

Was wir brauchen ist hauptsächlich ein kleines, internes Framework welches den Content des Themes regelt.
Nicht das Drumherum, das Menü etc. Dieses kann eben mit beliebigen Frameworks erstellt werden oder zu Fuss mit einfachem CSS wie bei Argos.

Aber man muss auf jeden Fall dann Kollisionen vermeiden.
Und nein, besser nicht in der form von wbce-button.


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#23 21.07.2019 10:57:15

berny
Member

Re: Modul Style Guidelines

Geht ja um "Style Guidelines"

mir ist aufgefallen, dass zB bei MP-Forms immer eine Instanz verwendet wird und diese automatisch ver- und weitergegeben wird.

Kann man so etwas nich als Prefix für Classen und vieles mehr umsetzen?

Damit würde es ja egal sein, wie ein Modul heißt usw...

Last edited by berny (21.07.2019 10:58:07)

Offline

#24 21.07.2019 11:51:22

rjgamer
Developer

Re: Modul Style Guidelines

Es würde alles so einfach gehen, wenn man sich auf einige CSS Klasse eines einfachen CMS Frameworks einigen würde anstatt die Kuh neu zu erfinden.

Offline

#25 21.07.2019 14:04:23

rjgamer
Developer

Re: Modul Style Guidelines

rjgamer wrote:

Es würde alles so einfach gehen, wenn man sich auf einige CSS Klasse eines einfachen CMS Frameworks einigen würde anstatt die Kuh neu zu erfinden.

Wenn erwünscht könnte ich mal was ausarbeiten. Hätte aber gerne die Rückenddeckung der WBCE Verantwortlichen.

Offline

Board footer

Powered by FluxBB

up