WBCE CMS – Way Better Content Editing.
You are not logged in.
Ja.
Ich würde mir wünschen, dass man die Gelegenheit beim Schopf packt und den "Wildwuchs" etwas eindämmt.
Templates und Module sollten auf Anhieb besser miteinander funktionieren - und Templates sollten besser austauschbar sein.
Dazu braucht es nicht mehr als ein ein paar Copy/Paste Blöcke - die wohlüberlegt sind und in jedes Template und Modul reinkommen.
Eine Sache sind zb Breakpoints bei responsiven Designs.
Es ist gefährlich, wenn jedes Modul sein eigenes responsives CSS mitbringt.
Da muss man sich jetzt was überlegen.
Auch die Standard-Anordnung der Blöcke... ich bin mit nicht ganz glücklich mit der Ruud'schen Herangehensweise, weil sie von der gängigen Praxis abweicht. Praktisch kein vorhandenes Template hat 3 Blöcke im Contentbereich (links/mitte/rechts)
Die derzeit bei Bootstrap üblichen 3 Blöcke hat man ja nur auf der Startseite - und da macht man sie mit Members oder sonstwas = nur 1 Block.
Auf Unterseiten sind fast immer 2 Blöcke: Hauptcontent, Sidebar. Ob die Sidebar links oder rechts ist, hängt ohnehin vom Design ab, das kann man kaum beliebig tauschen.
Nicht ausgegoren, aber vielleicht ein Anfang:
http://websitebaker.at/topics/finding-standards-templates-und-module-css.html
Mir ist im WB-Forum vorgeworfen worden, dass ich nur "Meine" Standards durchdrücken will.
Faktisch ist es einfach mal so, dass die meisten neueren Templates von mir sind und es keinen Sinn macht, alles umzureißen, wenn es nicht gute Gründe dafür gibt.
Von Templates gibt es keine "Upgrades", schon gar nicht mit geänderten Blöcken.
Und noch eine Sache:
Viele (meiner) Templates handhaben den 2. Block so:
[== PHP ==]
if(defined('TOPIC_BLOCK2') AND TOPIC_BLOCK2 != '') {
$page_content_2 = TOPIC_BLOCK2;
} else {
ob_start();
page_content(2);
$page_content_2 = ob_get_contents();
ob_end_clean();
}
Wenn ein Topic dargestellt wird, wird der Inhalt für die Sidebar in der Konstanten TOPIC_BLOCK2 gespeichert.
Erst so entfaltet Topics seine volle Pracht.
Eventuell sollte man das verallgemeinern: Auch andere Module können eine passende Sidebar generieren.
Man könnte zb "MODULE_SIDEBAR" als Standard festlegen, und naturgemäß gilt: Das Modul, das zuerst definiert, hat die Sidebar.
Standards allgemein: Gute Sache. Ich persönlich halte mich an dieser Stelle aber raus.
Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Ich denke ich verstehe worauf Du hinaus willst(hoffentlich).
Standards sind zwingend erforderlich wenn man austauschbare Templates möchte , vor allem bei den Heutzutage doch recht unterschiedlichen(und oft auch umfangreichen) Templates. Eine Bedingung dafür ist, soweit ich sehen kann das auch in den Modulen gewisse Standards eingehalten werden.
Auf der anderen Seite kann man die standard Modul Ausgabe kaum so flexibel gestalten, das sie für alle Templates passt. Solche Versuche in WP und Joomla sind oft kläglich gescheitert und wenn man da zum beispiel ein wohlgestaltetes Template von Template Monster kauft und dann weitere Module einbaut , sehen die meist sch... aus. Das liegt aber wohl in der Natur der Sache -> Module können nicht Formatierung für alle Templates enthalten und umgekehrt nicht alle Templates Formatierungen für alle Module.
Ich hatte mir damals für meinen eigenen Fork folgendes überlegt:
- Die Ausgabe aller Module erfolgt immer Template(php) basiert ,
- Damit kann dann entweder das Standardtemplate des Moduls oder oder eine angepasste Version vom Seitentemplate geladen werden.
- Wenn also das Seitentemplate extra Formatierungen für das Modul mitbringt werden diese genommen, sonst der Modul Standard.
- Die Modultemplates würden dann einfach im Unterordner /deintemplate/modules/modulname/ zu finden sein.
Sprich die standard Formatierung währe halt ein "best guess" und wenn ein Template was besonderes braucht einfach copy and paste und anpassen.
Obendrein kann man den Modulen so auch mehrere Standard Templates zu Auswahl mitgeben (eins für ne Sidebar eine für ganzseitig...)
Offline
Hmmm, habe noch ein wenig den Link auf deiner Seite gelesen , das mit den Standarisierten Blöcken/Sections ist nicht schlecht , sozusagen ein empfohlener Standard wie sich Templates bei bestimmten Blöcken verhalten sollen(oder das es sie auf jeden Fall managen kann). Man darf es nicht erzwingen , aber das macht auf jeden Fall Sinn . Für die Template Autoren weil Sie dann wissen, welche Blöcke sie auf jeden Fall erwarten können, und für die Anwender weil sie Wissen das zum Beispiel alle zertifizierten(Chio Standard no. 1 ) Templates bestimmte Blöcke unterstützen. Ich würde es eventuell am Namen des Blocks festmachen ist eventuell technisch etwas einfacher als an der Nummer aber das ist nicht so wichtig.
Bei Processwire schlage ich mich im Moment ein wenig mit ziemlich genau diesem Problem herum. Keine Standards :-)
Sich auf Etwas verlassen können ist immer wichtig wenn man mit einer Software arbeiten muss.
Last edited by norhei (24.07.2015 11:48:39)
Offline
Viele (meiner) Templates handhaben den 2. Block so
Danke, das ist ein Codeschnipsel, das ich immer suche und nie finde, das ist der einzige Grund, weshalb es z.B. beim WBCE-Template nicht drin ist.
Die Idee einer Standardisierung hat durchaus Charme. Einfach das Template zu wechseln, ohne dass einem alles um die Ohren fliegt, hat schon was.
Das WBCE-Template hat ja noch andere Schwächen und ist auch mehr oder weniger eilig heruntergeklappert. Ein WBCE-Template 2.0 könnte durchaus standardkonform aufgebaut werden.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Von irgendwas erzwingen ist keine Rede, natürlich kann jeder machen was er will.
Allerdings: Die Gelegenheit ist günstig.
- Es gibt eine überschaubare Anzahl an Modulen, viele davon werden ohnehin gerade überarbeitet.
- Bei den Templates ähnlich.
- Änderungen am Core liegen ja auch gerade an.
Zur Not können wir jetzt noch selbst nachbessern und unterstützen, es kommen ja nicht täglich 30 neue Module dazu ;-)
Sobald WBCE in Schwung kommt, werden Module und Templates auf Basis anderer erstellt - und diese "genetische Basis" pflanzt sich weiter fort. Was man jetzt als "Standards" macht, hat man in der Zukunft am Hals. ;-)
Macht man es richtig, wird es ein echtes Feature sein, macht man es nicht gut, wird es von selbst verschwinden. Jetzt ist die Chance, es gut zu machen.
Zuerst mal: Ich rede nur vom Frontend!
Ich würde ein "Modul-Standards-Test" Template machen, mitsamt Testcontent.
Also ein Template, das natürlich mal selbst die Standards erfüllt und das umschaltbar ist: heller Grund, dunkler Grund, breit, schmal, mit/ohne Bootstrap.
Das kann man einem Modul-Entwickler geben und sagen: Schau dir dein Modul damit an. Sieht es gut aus?
Umgekehrt für Template-Entwickler:
4 Blöcke Standard-Content mit eben allem drin, was sein soll. Und da wieder: Schau dir das an: Sieht dein Template gut aus?
Für beide kann man ein WBCE-Standards.css bereitstellen, das nur mehr anzupassen und rein zu kopieren ist. Das soll auch keine Riesen Latte sein.
"Zertifikat"
Ich weiß, das klingt blöd. Man muss aber einerseits dem Anwender sagen können: Mit diesem Modul, diesem Template wird das besser funktionieren als mit anderen. Ob du das willst, kannst du selbst entscheiden.
Dem Autor muss man eine Richtlinie geben, wie er dieses Zertifikat bekommt.
Wenn die Standards zu verquer und unpraktikabel sind, wirds ein Rohrkrepierer. Also muss das möglichst praxisnah sein.
Und hier muss man einfach zusammenarbeiten, weil sonst kommt was raus, was nur _einer_ als praxistauglich empfindet - für eben seine Praxis.
Hintergrund einfach:
Als Modul-Autor ist es mir eigentlich egal, welche Class mein Button bekommt. Ob die class="btn" ist oder class="meingeheimerstyle" ist mir letztlich völlig wurscht. Als Template-Autor habe ich aber keine Ahnung, welche classes die Module mitnehmen, ich will nur nicht 100e Möglichkeiten.
Und als Anwender will ich nicht bei jedem Modul in der frontend.css herumwurschteln - und nach dem Upgrade wieder.
Farben und dergleichen soll ein Modul GAR nicht definieren. Das muss ins Template.
Nur so als Gedanke - ich weiß das klingt jetzt mal sehr seltsam:
Ich rede hier auch nicht von der Optik, sondern nur den Klassen, die zu definieren sind.
Also - abgesehen von den "Basics" - also den Blöcken und einiger WB-spezifischer Sachen:
Was Module betrifft legt man zunächst mal Bootstrap a priori als Standard fest. Heißt: In einem Bootstrap-Template muss ein Modul gute Figur machen.
Das betrifft ja nur wenige Klassen (Button, Input usw) - auf diese schränkt man dann ein und sagt: Dieser stark reduzierte Satz wird jetzt allgemeiner Standard und soll auch ohne Bootstrap definiert sein.
Bei Templates macht man das dann umgekehrt so, dass man sagt: Ein Modul, das mit diesem reduzierten Satz aus Bootstrap funktioniert, sollte auch in deinem Template funktionieren. Du musst also zb die Farbe von .btn, .btn-warning und .btn-success festlegen.
Als Unterstützung bietet man ein css an, das dann nur mehr zu ändern ist.
Ich denke, so kann man das am ehesten auf die Reihe bekommen.
PS: Ich bin kein Fan von Bootstrap, aber irgendwo muss man ja mal anfangen. Ich bin mir auch ziemlich sicher, dass auch andere solche Gedanken haben, was die Sache in Zukunft vereinfachen wird.
Last edited by grindbatzn (25.07.2015 14:11:39)
Da wir hier alle keinen Korken im Arsch haben, sollten Änderungen am Core eigentlich nie ein Problem sein :-)
Das Problem das ich so sehe ist nur, das hier grade noch einiges zu reparieren ist , beim ersten Testlauf von WBCE hat grade zum Beispiel der CKeditor gestreikt :-(
Dann fiel mir auf das in der Benutzerverwaltung immer noch keine Suche möglich ist (schmerzhaft bei vielen Benutzern) also schnell eine einfache Lösung bereitet (könntest mal testen ? http://forum.wbce.org/viewtopic.php?id=31)
Aber eigentlich wollte ich ja multilingual fixen ...
Es kann also noch ein klein wenig dauern ....
Welche Blöcke sind denn soweit denkbar?
Header mit Logo und Navi
Ein Slider / oder Bild
Ein Inhaltsblock mit Sidebar links und, oder rechts
Mehrere Sonderblöcke über und unter dem Inhaltsblock .
Der Footer
Wenn man Diese Blöcke mit page_content('Footer') , page_content('logo')...... usw aufrufen könnte währe das wahrscheinlich sehr hilfreich ?
Offline
@norbert: nur so kurz nebenbei: Hast du meine Mails bekommen? Auch das mit dem Attachement?
Blöcke:
Man sollte es nicht übertreiben. Das Problem mit den Blöcken ist ja: Man müsste die auf jeder Seite befüllen - was ja kein Mensch macht.
Letztlich schaffen es die Leute nur, einen einzigen Block zu bewirtschaften.
Man muss also ein Template so anlegen, dass es mit einem oder max 2 Blöcken funktioniert. Ab da ist der Rest verwirrender Ballast. KLar: Optional geht viel, aber keinesfalls irgendwie "nötig".
Viele verstehen das Konzept "Blöcke" überhaupt nicht (merke ich immer wieder bei meinen Kunden)
Manchmal (nach dem 3. Bier) denke ich an ein im Core integriertes "Sidebar-Modul", das per AdminTool verwaltet wird und einfach dort, wo die Sitebar leer ist, irgendeinen Content reinschmeißt. Links, Newsletteranmeldung, letzte News, Zufallsbild, HTML/PHP....
Irgendwas Vorgefertigtes zum Auswählen im Admintool.
Last edited by grindbatzn (25.07.2015 14:42:08)
Blöcke:
Letztlich schaffen es die Leute nur, einen einzigen Block zu bewirtschaften.
Ja das ist meist so, leider. Bild block + Text + vielleicht noch ein paar tags.
Ein paar globale Blöcke fertig haben und wenn kein Content if (!page_content('sidebar')) global_block(34);
So ginge es im Moment.
Aus meiner erfahrung würde ich sagen das es am besten ist wenn das CMS ein Standarisiertes Set von blöcken zur verfügung stellt und jedes Template selber überlegen kann was es damit tut.
Ich kapiere überigens den part mit dem leeren Block 99 nicht.
Offline
Der Block 99 ist der Offline-Block, da hin kommt alles, was gerade nicht sichtbar sein soll oder aus Gründen™ anders, z.B. über ein Droplet o.ä. eingebunden wird.
Ansonsten zwei Dinge.
1.) WBCE muss einfach bedienbar bleiben, sowohl was die Contentpflege als auch das Erstellen von Templates betrifft. Bootstrap ist NICHT einfach. Im Gegenteil.
2.) Es darf keine Gängelung geben, die einem irgendwelche Blöcke aufzwingt, die man gar nicht braucht.
Wenn es ein entsprechendes Framework gibt, auf das man aufbauen kann, ist das gut und schön, aber die Betonung liegt hier auf kann. Wenn die absolute Bootstraphörigkeit ausbricht und wir bei einem Backend à la Joomla oder Contao landen, ist für mich (und nicht nur für mich) Schicht im Schacht.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
better-work
1. Logisch
2. Auch Logisch
Offline
Zunächst denke ich nur an das Frontend.
An das Zusammenspiel Editor/Module/Templates bei HTML und CSS
1. Ziel soll sein, dass ein Anwender GAR nichts mehr mit dem allen zu tun haben muss. Das (erzwungene) Nachbessern und Anpassen sollte stark reduziert werden.
Bootstrap ist ja nur ein CSS Framework. Natürlich soll niemand gezwungen werden. Aber wenn es in Bootstrap bereits eine <table class="table"> als Standard für "behübschte" Tabellen gibt, dann kann ich diesen Standard übernehmen und muss nicht extra "Z'fleiß!" eine class="wbsupertable" als Empfehlung angeben.
Es ist kein Theater, wenn ich als Default-Wert für Table im Editor eine class="table" mitgebe und statt 500px: 100%.
Ich habe das hier mal näher ausgeführt:
http://websitebaker.at/topics/table-standards.html
2. Blöcke: Da sollte die Regel gelten: Bereits 1 Block muss gut funktionieren. Gibt es einen 2. Block, ist dieser die Sidebar und entsprechend ist Block 1 schmäler. alle anderen Blöcke nur dann, wenn sie Output haben. Spezielle Blöcke Nr 5-9 (sollte wohl reichen)
Block 99 zum verstecken eines Blocks.
Das ist schon so gängig, dass man da eigentlich kein Rad mehr erfinden muss, man muss es nur mehr "standardisieren". Sogar das alte Andreas00 ist in nullkommanix auf diesen Standard gebracht.
Responsive sollte heute sowieso Standard sein.
Was sollte man empfehlen, wie der 2. Block am Handy ist?: Oben, unten? Gar nicht? Üblicher ist unten, weil eben auch leserichtung.
Welche Breakpoints sollte man empfehlen? Da sind die von Bootstrap nicht so ideal, da beginnt bei <768 schon das Handy.
Mobile First halte ich für ein Unding und es passt auch nicht zu WB. Der typische WB-User tut sich schwer damit, und - was ich so sehe - ist der Zuwachs an Handy-Zugriffen bereits etwas eingebremst. Je nach Thema einer Site.
Last edited by grindbatzn (27.07.2015 14:32:11)
https://github.com/WBCE/WebsiteBaker_CommunityEdition/issues/18
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Bitte bitte führt Bootstrap oder ein alternatives CSS Framework als Standard ein und erfindet nichts neues!
Erspart euch den Aufwand, definiert ein Open Source CSS Framework als Standard und verweist auf die entsprechende Dokunentation.
Offline
Darauf, das wir besseres zu tun haben als uns noch ein Neues CSS Framework auszudenken, da kannst Du auf jeden Fall sicher sein.
Offline
So lange das nicht verpflichtend wird und ich weiterhin Seiten auf der Basis des schlanken, simplen Fitgrid oder gar ganz ohne Framework bauen kann, soll es mir recht sein. Aber bitte kein Bootstrap-/$bloatedframework-Zwang.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline