Bones / Naked für Contao?

[olop01]

Hallo liebe Contao Community

Ihr kennt sicher das Template Bones oder auch Naked für Wordpress, oder? Diese Themes ermöglichen einen unkomplizierten Start zur Erstellung eines eigenen Themes für Wordpress, zudem noch responsive.

Da ich meine zukünftigen Seiten für Contao nun auch responsive gestalten möchte, wollte ich als Amateur einmal bei den Profis fragen, wie man das am umkompliziertesten in Contao verwirklicht. Nutzt ihr auch bestimmte Starter-Themes, auf denen man aufbauen kann oder fängt man komplett bei Null an?

Ich weiß, so etwas kann man auch einfach googlen, aber ich finde immer eine persönliche Meinung / Einschätzungen von erfahrenen Contao Nutzern ist tausend mal mehr wert. Also bitte nicht schimpfen

Vielen Dank für eure Anmerkungen und Tipps!
Olop

[mlweb]

Ich nutze bei meinen Projekten ausschließlich eigene Themes. Da bin ich an keinerlei "Vorgaben" gebunden, die mich in der Umsetzung beeinflussen bzw. einschränken.
Natürlich nutze ich aus meinen Themes auch bestimmte Bausteine immer wieder, aber es sind ausschließlich meine eigenen. So finde ich auch bei Fehldarstellungen die anzupassende Codestelle sehr leicht wieder.
Wenn man fertige Themevorlagen benutzt, sollte man sich bewusst sein, dass es aufwendig sein kann fremden Code anzupassen.
Manches Mal ist der Aufwand für die Anpassung eines fertigen Themes schwer einzuschätzen. Erst wenn man sich intensiv mit dem Theme und dessen Aufbau befasst hat, stellt man z.B. fest, dass die gewünschten Änderungen weitere Anpassungen erforderlich machen.
Will man nur so etwas wie die Farbe oder ein Hintergrundbild austauschen, ist ein fertiges Theme natürlich ideal.

Ansonsten ist die offizielle Demo oder das Opensauce-Theme von Rocksolid sicher ein ganz guter Einstieg oder eine Quelle für Anregungen.


Nachtrag: Es werden natürlich auch etliche Themes zum Kauf angeboten, aber da kenn ich mich gar nicht aus.

[olop01]

Aber in Contao selbst gibt es doch auch bereits so eine Art eingebautes Grid-System, oder?

[tab]

Klar, es gibt ein Grid-System in Contao. Aber ein Grid allein ist noch kein Theme, das heißt, wenn du einfach nur die Inhalte reinklopfst, sieht das halt noch nicht wirklich gut aus .

[Achim H.]

@mlweb

Deine Einschätzung teile ich voll und ganz.
Nur im "Selbstgemachten" findet man sich letztlich wirklich zurecht.
Hilfreich ist, das Buch von Peter Müller von A bis Z (1 bis 800) durchzuarbeiten.

[olop01]

Okay, ihr seid da eben echte Profis. Also ich habe jetzt einfach mal das Grid System von Contao benutzt (zum Ausprobieren). Und zwar legt man da ja im 12 Spalten System seine Texte an. Jeder Text bekommt als Klasse grid*, wobei * für den Anteil steht, den er im 12er Gitter einnimmt.

Ich habe allerdings eines noch nicht verstanden: Sagen wir, ich habe zwei Texte, die ich in zwei Spalten darstellen möchte. Dann bekommt jedes der ce_texts die Klasse grid6 und sie werden 50/50 auf dem Platz aufgeteilt. Allerdings gibt es standardmäßig ein festes margin zwischen den grid Elementen. Wenn ich jetzt z.B. einen blauen Hintergrund für beide Texte möchte, dann habe ich immer einen weißen Rand zwischen beiden (durch das margin).

Wie umgeht ihr so etwas? Kann man das margin der Klasse einfach überschreiben, ohne Probleme? Legt ihr jedesmal ein extra div drum herum?

Vielen Dank für eure Anregungen.

[mlweb]

Das hat aber nicht direkt etwas mit einem fertigen Theme zu tun, sondern das gehört zum Contao-Framework.
Ich arbeite zwar nicht mit dem internen Grid (kenne den Aufbau somit auch nicht genau) aber grundsätzlich hat die Veränderung des Außenabstandes natürlich Auswirkungen. Wenn Du diesen z.B. auf Null setzt ist er nämlich weg. Kannst Du auch in den Entwicklertools des Browsers testen. Einfach an der entsprechenden Stelle das Häkchen wegnehmen.
Für Dein eigentliches Problem: Manchmal muss man bei der Gestaltung etwas sagen wir mal unkonventionell denken. Suche Dir ein Element welches den beiden übergeordnet ist/die beiden umschließt und ordne die Hintergrundfarbe dort zu. Die Gridsystem die ich kenne haben eigentlich alle auch einen "Zeilenaufbau". Diese Zeile sollte dann dazu geeignet sein.

[olop01]

Suche Dir ein Element welches den beiden übergeordnet ist/die beiden umschließt und ordne die Hintergrundfarbe dort zu. Die Gridsystem die ich kenne haben eigentlich alle auch einen "Zeilenaufbau". Diese Zeile sollte dann dazu geeignet sein.

Hi und vielen Dank für deine Antwort mlweb!
Allerdings gibt es keine umschließende Klasse. Die nächst höhere ist das div (id= startseite). Darin liegen dann alle Elemente die ich erstellt habe, auch meine beiden ce_text divs (class= grid6). Das legt Contao alles so an und ich bestimme mit den Klassen grid* lediglich, wie viel Breite sie im 12er Grid einnehmen. Aber da der Abstand eben ein margin ist, kann ich die Elemente nicht lückenlos einfärben.

Hier mal ein Screenshot. Man sieht die beiden Textblöcke, die ich in meinem Artikel für die Startseite eingefügt habe. Dazwischen der unschöne margin Abstand.
contao.png

Nun könnte ich entweder auf der Seite jedesmal die Elemente "eigenen HTML Code" einfügen, was aber sehr umständlich wäre, da ich das dann für jede Zeile machen müsste. Oder ich entferne IRGENDWIE das standard margin aus dem Grid System und ersetze es durch Padding (aber wie?)

[mlweb]

Zum einen kann man die Inhalte die "zeilenweise" ausgegeben werden sollen in unterschiedliche Artikel packen. Dann hast Du pro Seite mehrere Artikel der Klasse mod_article mit der ID xyz. Eine weitere Möglichkeit bietet die Erweiterung "wrapper" (zwar noch nicht für 3.5 freigegeben, funktioniert aber in einem meiner Projekte fehlerfrei).
Natürlich ist es mit entsprechenden css-Kenntnissen auch möglich das Grid so zu modifizieren, dass die Ergebnisse genau zum eigenen Projekt passen (z.B. nur padding einsetzen) oder aber man verwendet das Grid von Contao gar nicht - nutzt ein eigenes oder ein anderes fertiges Grid oder auch gar kein Grid. Für mich ist so etwas nie Allgemein zu beantworten. Das hängt immer von der Erfordernissen des konkreten Projekts bzw. des konkreten Layouts ab.

Nachtrag: Ich nutze übrigens in den allermeisten Fällen kein fertiges Grid-System. Für mich viel zu viel Ballast um zwei Inhalte nebeneinander zu stellen.
Wenn Du auf alte Browser keine Rücksicht nehmen musst sind sicher die css-Eigenschaften für flexbox und/oder columns interessant. Setze ich in meinem Projekten seit einiger Zeit verstärkt ein allerding häufig noch mit Fallbacklösung für ältere Browser.

[olop01]

Zum einen kann man die Inhalte die "zeilenweise" ausgegeben werden sollen in unterschiedliche Artikel packen. Dann hast Du pro Seite mehrere Artikel der Klasse mod_article mit der ID xyz.

Okay, wenn ich meine Seitenbereiche im main container in mehrere Artikel aufteile und den Artikeln denn entsprechende CSS Klassen zuweise, funktioniert es. So heißt die Klasse von Artikel 1 bspw. "blue" und bekommt via CSS die blaue Hintergrundfarbe. Ich denke, man muss hier immer auf die Namensgebung der Artikel achten, damit man bei möglichen Änderungen schnell den richtigen Artikel zum Editieren findet. Für mein kleines Projekt reicht diese Vorgehensweise, aber bei größeren Seiten ist das dennoch keine wirklich komfortable oder übersichtliche Lösung.

Vielleicht findet sich ja noch jemand in der Community, der das 12er Grid aktiv nutzt und seine Erfahrung damit mit uns austauschen kann. Ich finde es schade, dass das Thema Responsive / 12er Grid so wenig erklärt wird, in der offiziellen Dokumentation.

Wenn Du auf alte Browser keine Rücksicht nehmen musst sind sicher die css-Eigenschaften für flexbox und/oder columns interessant. Setze ich in meinem Projekten seit einiger Zeit verstärkt ein allerding häufig noch mit Fallbacklösung für ältere Browser.

Habe ich ebenfalls probiert, allerdings muss man für die flex boxen weitere extra Regeln im CSS aufstellen, wenn die Bildschirmgrößen kleiner werden. Im Contao Grid System in Verbindung mit dem fertigen Responsive CSS, funktioniert das Umschalten auf eine Spalte automatisch

[mlweb]

Okay, wenn ich meine Seitenbereiche im main container in mehrere Artikel aufteile und den Artikeln denn entsprechende CSS Klassen zuweise, funktioniert es.

Da musst Du nicht zwangsweise etwas extra zuweisen. Man kann z.B. auch mit Kindelementen arbeiten. Kommt halt immer aufs Projekt drauf an.

Ich denke, man muss hier immer auf die Namensgebung der Artikel achten, damit man bei möglichen Änderungen schnell den richtigen Artikel zum Editieren findet. Für mein kleines Projekt reicht diese Vorgehensweise, aber bei größeren Seiten ist das dennoch keine wirklich komfortable oder übersichtliche Lösung.

Diese Einschätzung kann ich so nicht nachvollziehen, vielleicht sehe ich aber auch das Problem nicht. Inhaltsänderungen im Artikel haben doch mit der Gestaltung eigegentlich nichts zu tun und die Namensgebung des Artikels hat doch damit nur in sofern etwas zu tun, dass aus dem Alias eine ID für das div-element mit der Klasse mod_article generiert wird - ggf. kann man sich auch diese IDs zu nutze machen.
Außerdem ist das ja auch nicht die einzige Lösung. Ich hatte ja auch schon die Erweiterung wrapper angesprochen, weiterhin fällt mir der dma_elementgenerator ein oder rocksolid-custom-elements. Also Möglichkeiten gibt es viele. Wie komfortabel man etwas empfindet hängt natürlich stark vom eigenen Kenntnisstand, den Vorlieben und/oder vom konkreten Projekt ab.

Habe ich ebenfalls probiert, allerdings muss man für die flex boxen weitere extra Regeln im CSS aufstellen, wenn die Bildschirmgrößen kleiner werden.

Klar im Framework sind da einige Grundeinstellungen vorhanden. Für eine responsive Website kommt man aber m.E. um eigene css-Angaben in media-queries ohnehin nicht drumherum.

[mlweb]

Man kann natürlich auch noch Anpassungen der Templates an die eigenen Zwecke vornehmen.

[olop01]

Diese Einschätzung kann ich so nicht nachvollziehen, vielleicht sehe ich aber auch das Problem nicht. Inhaltsänderungen im Artikel haben doch mit der Gestaltung eigegentlich nichts zu tun und die Namensgebung des Artikels hat doch damit nur in sofern etwas zu tun, dass aus dem Alias eine ID für das div-element mit der Klasse mod_article generiert wird - ggf. kann man sich auch diese IDs zu nutze machen.

Naja, ich meine den Mehraufwand den ich habe, da ich erst jede Zeile in einen eigenen Artikel stecken muss. Mehraufwand durch: Die Artikel erstellen; Bei Bearbeitungen immer erst den richtigen Artikel finden, öffnen, Element bearbeiten
Ich hätte ein padding anstatt des margins im Grid System benutzt - aber es gibt sicher einen Grund warum man sich für margin entschieden hat, den ich einfach nicht sehe.

Man kann natürlich auch noch Anpassungen der Templates an die eigenen Zwecke vornehmen.

Oh weh, davon habe ich keine Ahnung und so richtig viel sagt die Doku darüber auch nicht. Da lasse ich die Finger von!

[mlweb]

Naja, ich meine den Mehraufwand den ich habe, da ich erst jede Zeile in einen eigenen Artikel stecken muss.

Jede Zeile ? Was hast Du vor? Vielleicht kann man Dir besser einen Tip geben, wenn Du einen Link postest.

Ich hätte ein padding anstatt des margins im Grid System benutzt.

So etwas kann Sinn machen und kann auch funktionieren muss aber nicht. Kommt immer drauf an. Kannst Du doch einfach testen.

[olop01]

Jede Zeile ? Was hast Du vor?

Ich habe die Seite leider nur local gehostet via Apache Naja, ich habe immer ein Bild auf der einen Hälfte, daneben eine h2 und Begleittext auf der Hälfte daneben. Darunter kommt dann wieder das selbe Schema, usw. Um diese "Zeilen" voneinander zu trennen, färbe ich immer jede zweite Zeile ein. Und das ging mit dem 12er Grid eben aufgrund des margins nicht

Jetzt habe ich einfach mit meinem CSS das Standard margin überschrieben und durch padding ersetzt. Es scheint damit keine Probleme zu geben. Ich hoffe bloß, es ist Browserkompatibel

*[class*="grid"]  {
	padding: 12px 10px;
	margin: 0 !important;
}

[mlweb]

Wenn es viele Bilder sind - was ja die farbliche Hervorhebung suggeriert - würde ich darüber nachdenken ob die Bildergalerie mit entsprechender Beschreibung geeignet ist.
Habs zwar nicht getestet, denke aber dass da mit css etwas machbar ist.
Eine andere Möglichkeit wäre die css-Eigenschaft display: table - auch nicht getestet.

Andererseits, wenn es keine Nebenwirkungen mit dem Grid gibt, ist ja alles so wie Du es willst.

Was die Browserkompatibilität betrifft werden Attributselektoren glaub ich ab IE7 teilweise unterstützt. Wenn im Original auch der Attributselektor (habe ich jetzt nicht geschaut) verwendet wird, ist die Browserunterstützung auf jeden Fall dadurch nicht schlechter.
Ich würde nur versuchen ohne !important auszukommen. Das sollte man eigentlich nur bei Testszenarien oder im äußersten Notfall verwenden.

Nur Mal so am Rand und um Mißverständnissen vorzubeugen, verwendest Du tatsächlich Contao 4.0.x?

[soweit_ok]

Ich würde nur versuchen ohne !important auszukommen. Das sollte man eigentlich nur bei Testszenarien oder im äußersten Notfall verwenden.

Schriebst Du schon öfter und stimmt ja auch als Grundregel. Ich denke allerdings, sollte man nicht verallgemeinern. Bei sehr großen und zudem außergewöhnlich komplexen Webseiten mit außergewöhnlich vielen CSS-Anweisungen kann nach meiner Erfahrung die Situation entstehen, externes CSS einsparen zu wollen, weil´s unübersichtlich gerät und außerdem dann auch vieles immer mitgeladen wird, was nur auf wenigen Seiten vonnöten ist. Dann geht man zu mehr Inline-CSS und rein seitenbezogenem CSS über. Inline-CSS lässt sich jedoch nur mit !important überschreiben und wenn man es nur auf einzelnen Seiten tut, ist es dann auch garkein Problem. Dass man die Regel nicht global einsetzen sollte, da stimme ich natürlich vollkommen zu, oder man kriegt irgendwann graue Haare.

Und ansonsten kann ich dem TE auch aus eigener Erfahrung sagen, Deine Empfehlungen stammen ganz offensichtlich aus der Praxis und deren Beachtung, wie auch die anderer Praktiker, kann so manchen Verdruß ersparen. Je nach Fokus. Will man nur mal gelegentlich ein Projekt mit Contao realisieren, z. B. die eigene HP, kann der möglichst einfache Weg, ein fertiges Template mit einigen wenigen Anpassungen zu verwenden, durchaus Sinn machen. Ist hingegen für immer wieder neue Projekte Contao die Grundlage, schauts anders aus. Hier dann, sofern man die zeitl. Ressourcen erübrigen kann, keinen initialen Aufwand scheuen und sich eigene wiederverwendbare Komponenten aufbauen. Gilt ganz besonders auch für das Layout. Die wichtigste Kompente dabei: Durchblick erwerben. Auch was die Verwendung von Grids angeht. Punktuell komfortabel, doch gewiss nicht das Maß aller Dinge. Auf jeden Fall CSS3 auf dem Schirm haben, oft die bessere Alternative. Auch Mediaqueries sind zwar für manches praktisch, mit ihren Möglichkeiten aber auch sehr begrenzt, weil damit nur wenige Events abgefangen werden können.

[mlweb]

Klar Außnahmen gibt es immer und alles was man ganz bewußt auch gegen Grundregeln einsetzt hat seine Berechtigung. Häufig wird allerdings ohne Not !important eingesetzt, weil die Leute gar nicht wissen, dass das mit etwas Überlegung auch ohne !important funktioniert.

Auch Mediaqueries sind zwar für manches praktisch, mit ihren Möglichkeiten aber auch sehr begrenzt, weil damit nur wenige Events abgefangen werden können.

Was meinst Du damit genau?

[soweit_ok]

Was meinst Du damit genau?

Mediaqueries reagieren halt lediglich auf die aktuelle Viewportgröße und ggf. deren Änderung. Daneben ist dies auch nur in relativ groben Stufen praktikabel, sonst würde die Codemenge zu groß. Auch kann man damit nur das CSS überschreiben, sonst nichts. Dafür ja auch sehr praktisch, reicht aber nicht für darüber hinausgehende Anforderungen, die sich nur mittels Programmierung und ggf. direkter Manipulation im DOM lösen lassen.

Beispielsweise kodierte ich die Mediabox neu, weil mir die Fähigkeiten der verfügbaren Lösungen nicht reichten. U. a. wollte ich stufenlose Skalierung, und ohne auch nur kleinste Ruckler, was Feintuning in Verbindung mit dem Resize-Event erfordert. Noch kniffliger wird´s, wenn Abhängigkeiten in Verbindung mit anderen Elementen formelbasiert verarbeitet werden müssen. Widerum am Beispiel der Mediabox - die Bildunterschrift ist bei mir in eine fixe Statuszeile nach unten verlagert. Dieser Bereich kann Bildbeschreibungen beliebiger Länge aufnehmen. Für bis zu 3 Zeilen vergrößert sich die Elementhöhe dynamisch, bei noch mehr Inhalt erscheint eine Scrollbar. Dieses Element nimmt aber nicht nur unterschiedliche Höhe ein, sondern daneben auch einen prozentual immer größeren Teil des Viewports, je kleiner der Viewport ist. Das angezeigte Bild muss sich ebenfalls automatisch daran anpassen. Auch noch automatisch unterschiedlich, weil die jeweilige Platzanforderung beider Elemente ja stets anders ausfallen kann. Und das geht nichtmal linear zu verarbeiten. U. a. gibt es zwischendrin einen Größenbereich (ergibt sich im Test), in dem der Anpassungswert stufenweise überproportional zunimmt, um kurz darauf stufenweise wieder zurück zu gehen. Anderenfalls würde das Bild in dem Bereich überlappt. Mit dem Auge sieht man die Auswirkung dieser Formel nicht, es passt einfach immer.

Nur ein Beispiel, hoffentlich halbwegs nachvollziehbar erklärt, wo es ohne Programmsteuerung nicht geht. Gibt in meinen Layouts noch eine ganze Reihe vergleichbarer Situationen. Zusammenfassend immer dort, wo nichtlineare Abhängigkeiten zu berücksichtigen sind, um den verfügbaren Darstellungsraum optimal zu nutzen, reichen Mediaqueries nicht. Oder wenn die Codemenge so groß würde, dass es mit Programmierung deutlich schlanker umgesetzt werden kann. Eine simple Fallunterscheidung am selben Breakpoint "wenn DAS eintritt, lade DIESES CSS nach, oder wenn JENES ist, lade JENES CSS, übersteigt bereits die Möglichkeiten von MQ.

[mlweb]

Danke für Deine Erklärung. Leuchtet ein.
Mir war im ersten Step nur nicht ganz klar, was genau Du mit dem obigen Satz meintest.

Die Anpassung der Mediabox finde ich interessant.

[soweit_ok]

Die Anpassung der Mediabox finde ich interessant.

Hmmh, hat sich auch gelohnt, obgleich es um einiges kniffliger wurde, als ich erwartet hatte, bis das anständig fehlerfrei lief.
Prinzipiell hätte ich nix dagegen, auch mal den Code zu posten. Geht momentan aber nicht, weil sie seitdem nicht mehr unabhängig läuft, sondern auf Funktionen eines JS-Plugins zugreift, das Teil meines eigenen Layout-Frameworks ist.

Diese Funktionen könnte ich allerdings extrahieren und direkt in den Mediabox-Code mit reinpacken. Na ja, wer mag schon reduntanten Code. Will ich aber trotzdem mal machen, um die Mediabox auch ohne den ganzen Rest in beliebigen Contao-Versionen verwenden zu können. Immer das Ding mit der knappen Zeit halt, kann sich noch etwas hinziehen.

Falls es Dich evtl. auch für irgendwann später interessiert und Du möchtest, kannst Du das Modul gerne bekommen. Ich würde Dir in dem Fall ne PN senden, wenn´s denn mal soweit ist. Ist gut dokumentiert leicht nachvollziehbar, sofern man den normalen Mediabox-Quellcode versteht. Ist allerdings die MooTools-Version, also ungeeignet, wenn man nur jQuery einbinden will.

Edit: Achso, vielleicht sollte ich noch erwähnen - meine Mediabox-Variante hat auch noch ein paar weitere Features. Bspw. die "Minibox"-Umschaltung. Damit lässt sich das Overlay mit Buttonklick ausblenden, so dass man auch die Hauptseite bedienen kann. Der User kann das Minibild per Klick vergrößern/verkleinern. Bspw. praktisch für Fotos von Mitgliederlisten, Galerie-Thumbnails, Produktlistenfotos usw. um direkt zu wählen/wechseln statt alles durchblättern müssen oder extra die Mediabox schließen. Normal- und Miniboxansicht kann per Klick umgeschaltet werden, siehe Screenshots. Ansonsten kann der User noch die Overlayfarbe und -transparenz per Klick ändern. Ansonsten können Seiten durch Setzen der Klasse "mediabox" auch aus der Navigation in der Mediabox geöffnet werden. Das war´s momentan, weitere Funktionen sind noch geplant, u. a. Bildstrecken mit Anzeige mehrerer Bilder nebeneinander sliden. Theoretisch könnte ich das Teil auch mal als Erweiterung ins Respository stellen, aber k. A. ob das jemanden interessieren könnte. Zweitens weiß ich bislang nicht, wie das geht und drittens will ich nix versprechen, was ich dann vllt. zeitlich nicht auf die Reihe kriege.

tm_minibox.jpg mediabox.jpg

[mlweb]

Danke für Dein Angebot, aktuell benötige ich nichts dergleichen, aber grundsätzlich "speichere" ich so etwas immer ab. Habe also durchaus Interesse, wenn Du etwas fertig hast. mootools ist mir sogar fast lieber. Ich bin eigentlich nicht der Programmierer. Weil ich mich für einige notwendige Anpassungen an einem Akkordeon mal in mootools reingekniet habe, kann ich den Code glaub ich derzeit leichter verstehen als jquery oder reines javascript.

[soweit_ok]

Tja, das ist alles Geschmacksache. Alles, wofür ich nicht schon auf einer MooTools- oder jQuery-Lösung aufsetzen muss, code ich lieber in normalem JS. Diese Bibliotheken, wenn man eine davon eh schon laden muss, sind zwar schön komfortabel und ermöglichen schlankeren Code, aber man fängt sich damit auch mögliche Kompatibilitätsprobleme bei Updates ein. Und das kann ziemlich hässlich werden, wenn andere Contao Releases andere Bibliotheksversionen verwenden.

Okay, ist gemerkt. Du brauchst es momentan ja eh nicht, und falls ich mal ein Standalone-Modul daraus machte, gebe ich Laut.

[mlweb]

Ja, super danke.