Grundidee hinter den Themes?

[Bandyt]

Ich habe heute auch die Migration zu 2.9 durchgeführt und mir auch die neuen Funktionalitäten angeschaut.

Besonders hatten mich die Themes angesprochen. Leider finde ich aber entweder die entsprechenden Funktionalitäten nicht oder meine Vorstellung des Konzepts ist ein anderes.

Ich hatte gedacht, dass die Themes sich z.b. wie Stylesheet verhalten. Ich sie als erstellen, kopieren, verändern, löschen kann und dann diese meiner Webseite als Theme zu weisen kann.

Ist das nicht der Fall oder stelle ich mich gerade sehr dämlich an...

[BugBuster]

Schon gelesen?
http://www.contao.org/theme-verwaltung.html
Eigendlich ist das nur ne Gruppierung von Layouts,Css,Modulen,Templates die man dann mit einem Rutsch exportieren und importieren kann.

Die Gruppierung ist auch interessant für Multidomain Betrieb, weil man nun diese Dinge je Domain gruppieren kann.

[Bandyt]

Ja, hatte ich gelesen. Vielen Dank dafür.

Ich hatte es so verstanden, dass ich ein komplettes Theme festlege und dann schnell umstellen kann. Leider wohl falsch verstanden...

[ku-ma-122]

Wieso sollte das nicht gehen?

Im Menüpunkt Seitenstruktur kannst Du ja das entsprechende Theme beim Startpunkt auswählen und schon hast Du ein neues Design

Wenn Du natürlich unterschiedliche Seitenlayouts verwendest und die Seiten bereits unterschiedliche Layouts zugewiesen bekommen haben, dann müssen diese Seiten alle umgestellt werden. Mit "mehrere bearbeiten" geht das aber auch schnell von der Hand.

[BugBuster]

Äh, in der Startseite wie in der Seitenstruktur kann ich ein Layout aus einem Theme wählen, nicht das Theme selbst.
Was ja auch unnütz wäre, wenn darin mehrere Layouts liegen.

Das mit "mehrere bearbeiten" scheint wirklich zu gehen, dazu muss man (sollte man) alle ebenen aufklappen um wirklich alle Seiten markieren zu können.

[ku-ma-122]

Schon klar, sollte aber wirklich nur ein Seitenlayout vorhanden sein, ist es ja genau das was gefragt wurde. Nur dass eben nicht direkt das Template X zu Y wird, sondern Layout von Template X zu Layout von Template Y

Ist wohl einfach eine Verständnisfrage.

[uliverse]

Was mich etwas verwundert hat - man kann nun im Multidomain-Betrieb Stylesheets und Module nicht mehr gemeinsam verwenden, wenn man diese sauber in Themes geordnet hat. Das wäre aber doch oft ganz praktisch. Einziger Ausweg ist, Kopien zu erstellen und das ist auch nicht ideal... Oder kapiere ich da was nicht?

[BugBuster]

Richtig erkannt, das ist einer der Nachteile wenn man mit mehreren Themes arbeitet.
Wobei das ja bei Multidomain ja eigendlich ein Vorteil ist das sauber trennen zu können.

[uliverse]

Eigentlich schon. Aber es kommt doch oft vor, dass bestimmte Module oder Stylesheets wiederverwendet werden sollen, weil den die Wartungsaufwand niedriger hält.
Bestehende Installationen auf die neue Theme-Stuktur umzubauen, kann viel Arbeit bedeuten und ist anfällig für Fehler. Zumindest ist das mir passiert, dass plötzlich einiges nicht mehr ging, weil ich die entsprechenden, gemeinsam genutzten Resourcen nicht kopiert hatte.

[serienjunky]

Ich bin jetzt auch auf 2.9 umgestiegen und frage mich auch ein wenig, was die neue Funktion Themes für Vorteile hat.

Vorallem weiss ich nicht ganz wie ich das jetzt handhaben sollte. Für mich ist jetzt einfach einen Klick mehr um zu den Modulen zu kommen.

Wann sollte man mehre Themes haben? Wenn man verschiedene Layoute hat? Wenn man verschiedene Sprachen hat?

Ich hoffe jemand kann mich da aufklären

[mariusssl]

Für mich ist jetzt einfach einen Klick mehr um zu den Modulen zu kommen.

offtopic: hahahahaha recht haste ^

[BugBuster]

Ich denke mal die Hauptidee dahinter war die export / import Funktion in der Styles,Layout,Templates,Frontend Module gebündelt mit enthalten sind.
Siehe das Video dazu.

Auch für Multidomain Installationen ist das durchaus sinnvoll. Vorher hatte man eine Liste von Modulen und konnte nur durch geschickte Namensvergabe sehen in welcher Domain die verwendet werden.

Es gibt auch Nachteile, der eine Mausklick mehr ist dabei der kleinste.
(wobei man den Dank easy_theme eliminieren kann)

[pcartist]

Wieso werden denn nun die vorhandenen Stylesheets nicht mehr beim Import überschrieben?

Das erhöht den Wartungsaufwand meines Erachtens ungemein.
Zumindest ein Abfragedialog, ob "Neu anlegen" oder "Überschreiben" wäre doch ein Schritt in die richtige Richtung gewesen.

[BugBuster]

Wieso werden denn nun die vorhandenen Stylesheets nicht mehr beim Import überschrieben?

Im selben Theme? Hmmm.
Vielleicht zu viel des Guten.
Man darf ja auch in verschiedenen Themes nicht Styles mit dem selben Dateinamen haben, da diese ja (noch) im TL_ROOT generiert abgelegt werden.
Die sollen sich da natürlich nicht gegenseitig überschreiben.

Könnte mir vorstellen, das deshalb generell der Import unter einem neuem (ergänzten) Namen abgelegt wird, sofern schon vorhanden.

[pcartist]

Nun, bei mehreren Themes lass ich mir das noch eingehen. Kann aber auch simpel vermieden werden, wenn beim generieren der Files im Root der Dateinamen durch die id ersetzt wird.

Bei vielen unterschiedlichen Layouts dann die Styles immer wieder neu zuzuweisen ist nicht besonders Benutzerfreundlich. Noch dazu, weil auch die Einstellungen (Media und Comments) nicht übernommen werden.

Das ist - bei all meiner Begeisterung für Contao - sehr lästig.

Ich kann mir gut vorstellen, daß der ein oder andere die .css direkt im Template einbinden werden.

[chrisbirne]

Äh, in der Startseite wie in der Seitenstruktur kann ich ein Layout aus einem Theme wählen

Hallo, woran könnte es eigentlich liegen, dass genau das nicht funktioniert? Wenn ich beim Startpunkt einer neuen Seite ein Layout wähle, tut sich gar nichts.

Muss ich tatsächlich auf jeder Seite ein Layout wählen?

Viele Grüße
chrisbirne

[uliverse]

Das im Root gewählte Layout wird automatisch auf alle Seiten darunter weitervererbt. Wenn dort kein Layout zugewiesen wird, kommt das Default-Layout zum Einsatz.

[serienjunky]

So habe mir jetzt ein Modul gebastelt, welches mir wieder ermöglich, mit einem Klick zu den Modulen zu gelangen.

Es gibt zwar schon easy_themes, aber bei einem Theme ist es nicht wirklich brauchbar.

[BugBuster]

So habe mir jetzt ein Modul gebastelt, welches mir wieder ermöglich, mit einem Klick zu den Modulen zu gelangen.

Es gibt zwar schon easy_themes, aber bei einem Theme ist es nicht wirklich brauchbar.

Im Mousover Modus auch mit nur einem Theme gut nutzbar.
Ansonsten gibt es custom_be_modules, damit kannste dir die Links auch wieder einbauen.

[135ti]

Wieso werden denn nun die vorhandenen Stylesheets nicht mehr beim Import überschrieben?

Gibt es eine Möglichkeit das zu deaktivieren?

Ich editiere die CSS immer lokal und beim import wurde sie früher einfach drübergebügelt und gut wars. Gerade wenn man mehr als eine Angabe ändern will ist der eingebaute CSS-Editor einfach nicht zu gebrauchen wegen der Klickerei.

Jetzt habe ich style.css, style-1.css, style-2.css und so weiter im Root rumliegen aber in keinen Seitenlayout drin. Lediglich die alte, unveränderte weil nicht überschriebene style.css ist im Seitenlayout drin. Das macht doch keinerlei Sinn?

[ku-ma-122]

Wenn Du grundsätzlich nicht mit dem internen CSS-Editor arbeitest, dann würde ich empfehlen die CSS-Dateien in einen Ordner (z.B. tl-files/css ) hochzuladen und von dort einzubinden.

Damit sparst Du Dir den Arbeitsgang jedes Mal importieren zu müssen.

[BugBuster]

Ich rate jetzt mal.
Da du ja nun mehrere Themes haben kannst, die beispielsweise auch gleichzeitig genutzt werden, darfst du auch keine CSS Files mit identischem Namen haben, da die sonst sich gegenseitig im TL_ROOT überschreiben würden.
Nun hat Leo wahrscheinlich strikt eingebaut, wenn beim Import ein gleichnamiges vorhanden ist, dann umbenennen. Egal im im selben Theme oder außerhalb.

Ob das Sinn macht? Hmm....
Kannst ja ein Feature Request ins Ticketsystem setzen.
Wenn im Theme in dem importiert wird ein gleichnamiges existiert, dann Rückfrage wie bei der 2.8 ob überschrieben werden soll.

[psren]

vllt sollte man noch beim Theme selber einen Ordner fürs CSS angeben können (wie bei den templates), dann wäre es mit der selben benennung kein Problem mehr (im selben Theme gleiche Namen führt zur altgewohnten überschreiben Warnung).

Hätte den Vorteil, dass bei vielen installierten Themes die Stylesheet-namen nicht untereinander kollidieren...
(z.B. die basic.css ist ja in den meißten Themes bestimmt vorhanden) was bisher zu hässlichen Namen führt.

2. aber meiner Meinung nach nicht so brauchbare Variante wäre, den Theme-Namen als Prefix vor den Stylesheet-Namen zu stellen. Ist aber auch hässlich.

[BugBuster]

ein eigenes CSS Verzeichnis je Theme ist meines Wissens sogar geplant für die Contao 3.0, das war wohl so schnell nicht möglich noch in die 2.9 mit reinzudrücken.
Das bedeutet ne Menge Umbau.
Siehe http://dev.contao.org/issues/1999

[psren]

ah, sehr schön, genau wie ich mir dachte.
Und wieder geht ein Wunsch in erfüllung, das hier ist ja wie Weihnachten nur öfters.

[mizoko]

Ich glaube ich habe das mit dem Themes noch nicht ganz verinnerlicht.
Ausgangslage:

• Modulerstellung nach dem CD-Collection Tutorial unter contao 2.90 und insgesamt 3 Themes (music academy, geFewo und fruitMEDIA).

• Im Themes fruitMEDIA das Modul cd_collection erstellt und einem Artikel zugewiesen.

Soweit ok. Wenn ich in der Rootseite (Startpunkt der Webseite) von music academy das Seitenlayout von fruitMEDIA auf geFewo oder auf Default music academy Layout ändere, wird der Artikel mit dem Modul korrekt angezeigt. Ich hätte erwartet, dass der Artikelinhalt nicht angezeigt wird, wenn ich das Layout (Theme) wechsle, da das hierfür notwendige Modul nur in einem Theme vorhanden ist.
Gruß mizoko

[BugBuster]

Da hast du richtig erwartet. Das man im Artikel die Module aller Themes auswählen kann ist mir auch schon aufgefallen.
Es hieße mal, für Migrationen wäre das so besser. Es funktioniert erstmal und man kann dadurch nach der Layout/Theme Umstellung die Module noch umstellen.

Aber so richtig anfreunden kann ich mich damit auch nicht, da man so nicht merkt das es noch was zu tun gibt.
Möglich, das so tief noch gar nicht drüber nachgedacht wurde und man das sogar als Bug einstufen könnte.

Das Problem was ich dabei sehe ist, die Module "denken" immernoch das sie im alten Theme sind (was ja auch stimmt, nur die Seite nicht) und holen von dort auch die Templates! Ich bin grad dabei meine Module Theme fähig zu machen und stolpere da grad drüber. Muss aber noch weiter testen.

[mizoko]

Hallo BugBuster,
da ist etwas dran, für die Migration eine Art Zwischenweg zu gehen. Nur die Realität holt uns irgendwann ein (Contao 3.0?). Schon jetzt ist die fehlende Trennung der Themes eine Herausforderung.
Wollte mal auf die Schnelle im Kalendermodul den Wochentag ändern. Tja, Auswirkungen auf der Webseite erst nach Änderung in zwei weiteren, installierten Themes, respektive deren Kalendermodulen.
Das beste ist wohl, erstmal nur das Theme installiert zu lassen, in welchen man gerade arbeitet.
Gruß mizoko

[Harry]

Die Frage nach der Grundidee der Themes ist durchaus berechtigt. Und ich glaube, genau da liegt der Knackpunkt. Gehen wir einmal davon aus, wie die Grundideee konzipiert ist. Zitat von der Projektsite: "Das Design einer Webseite besteht normalerweise aus Stylesheets, Frontendmodulen, Seitenlayouts, Dateien und Templates, die Sie im Contao-Backend verwalten können."

Der Theme-Manager gruppiert also designrelevante Ressourcen, wie Stylesheets, Module, Seitenlayouts (Datenbank) und dazugehörige Dateien wie Hintergrundgrafiken etc. und bietet das Ganze zum Import und Export an. Das Bestreben dabei ist, das bestehende Konzept der Zusammenhänge nicht zu verändern.

Damit stellt sich die Frage: "Was ist Design?". Aus der Sicht des Contao-Theme-Gedankens erscheint mir dies als ein Mittelweg zwischen Frontend-Template (komplette Website inkl. Inhalten, was es bislang schon immer gab) und einem reinen CSS-Switch (es werden nur die CSS-Anweisungen ausgetauscht). Zum Design einer Website gehört demnach auch, welche Funktion an welcher Stelle überhaupt angeboten werden. Ein Designer bestimmt also z. B. über die Module im Theme, wo welche Funktionen im Frontend angeboten werden und über die Stylesheets, wie diese aussehen sollen. Natürlich verbunden mit der Auflage, Module duplizieren und redundant pflegen zu müssen, wenn sich bei Verwendung mehrerer Themes, aber gleicher Anordnung von Funktionen, Änderungen ergeben.

Ich muss zugeben, dass ich hier noch keine ausreichende Praxis habe. Welche Auswirkungen dieses Konzept auf bestehende Projekte haben wird, wenn man für diese mehrere Themes bereitstellen will, muss ich selbst noch erfahren.

Viele Grüße
Harry

[blueamerican]

@bugbuster:

genau meine meinung!

ich kenne von drupal dass man ein theme als "aktiv" einstellen kann und dann alles darauf greift.

aktuelle habe ich genau das problem dass meine module noch auf mein altes theme zugreifen... und wahrscheinlich noch mehr als meine module...

frage: wenn es im be nicht einstellbar ist, gibt es eine möglichkeit in der datenbank einzustellen, dass mein aktuelles theme nicht mehr zb musci academy ist, sondern "neues theme"?

das wäre wichtig, weil sonst kann ich das theme nicht wirklich gebrauchen:-)

[blueamerican]

mein problem nochmal ganz konkret:

ich habe zwei identische themes mit kopierten modulen.
music academy, new_theme

im bestehenden seitenbau ist noch aus music academy die seite news, also die seite die alle news auflistet. diese seite benutzt nachwievor das modul aus music academy (heisst da nachrichtenliste).

die frage ist nun: wie kann ich das modul aus new_theme aktivieren?

[blueamerican]

upps ich hab den schalter gefunden...

ich muss im artikel wo ich die newsliste anlege das neue modul auswählen...

es geht also doch:-)

wirklich überschaubar ist das aber nicht mehr!