Was taugen die Themes auf contao.org technisch?

[stefan-at-work]

Wenn ich zum Mercedeshändler gehe und er mir ein offizielles Ersatzteil für meinen Wagen verkauft, erwarte ich, dass es funktioniert und ich nicht selbst den Lötkolben schwingen muss.

Ich kenne jetzt das Theme nicht, aber ich frage mich jetzt, funktioniert es jetzt nicht ohne das Du den Lötkolben ansetzt? Sprich, ist es so "out of the box" nicht funktionsfähig oder entsprecht es einfach nur nicht Deinen Vorstellungen eines korrekten Aufbaus?

In den Beschreibungen zum Theme steht eindeutig, das es angepasste Templates und ein externes CSS Framework verwendet.

Gruß
Stefan

[ciaobello]

Hi,

Ich denke meine Aussage war klar: Nämlich dass ich im offiziellen Contao-Store Themes erwarte, die ich nicht recherchieren muss. Genau dazu gibt es einen offiziellen Theme Store doch. Wenn er das nicht leistet, was dann?

Wenn ich zum Mercedeshändler gehe und er mir ein offizielles Ersatzteil für meinen Wagen verkauft, erwarte ich, dass es funktioniert und ich nicht selbst den Lötkolben schwingen muss.

Jan

Hallo Jan,

Danke das die Diskusion hier jetzt auf einer Sachlicheren Ebene abgeht.
Ich habe von Anfang an nicht die Qualitätsfrage Angeprangert. Was mich gestört hat ist die Art und Weise wie Du Deinem Ärger hier Luft gemacht hast.

Zudem Gab es schon Foren Einträge über diese Thematik. Nina hat im Februar darauf hingewiesen. Wenn Dir schon so viel an Qualität liegt, wieso hast Du dann nicht auch ein Bestehendes Thema wo es um Rock-Solid/Offizieller Themen Store ging weitergeführt und Dein Anliegen da Sachlich dargelegt?

dr.ed hat meines Erachtens seine "Schlechte Erfahrung" auch treffend und Sachlich formuliert. Danke dr.ed.

Es ist einfach mit dem Finger auf Schwachstellen zu zeigen. Viel schwieriger wird es beim umsetzen und "es" selber besser machen (Du formulierst es ja im selber im Schlusssatz treffend). Ich denke Neulinge schauen darauf was solche tun die schon länger dabei sind. Wenn man denen dann auf die Finger kloppt aber es selber nicht besser macht kommt das irgendwie auch Schräge rüber.

Der Vergleich mit Mercedes und Contao-Core gefällt mir. Von der Qualität stimmt es ungefähr
Dass Du aber Contao-Theme mit offiziellen Ersatzteilen vergleichst kann ich nicht nach vollziehen.

Bei den Themen handelt es sich eher um ein Sonder-Zubehör, und solches wird bei vielen Autos auch von anderen Firmen zugeliefert oder über eine Generalagentur weiter vertrieben, weil man dem Kunde einen erweiterten Service bieten will. Aber schlussendlich wenn das Radio oder der Sportheckspoiler einen defekt aufweist, wird man auf die Garantie des Zulieferers verwiesen. Und das wird dann meistens auch so von den Autofirmen vorab kommuniziert.

Übrigens habe ich nichts "persönliches" gegen irgend jemand hier im Forum. Und schon gar nicht gegen "die drei Musketiere" (Die Formulierung von Tril ist mir ein bisschen so vorgekommen

Zitat von tril
Die Front die Missstände zu beheben versucht und entsprechend Ihren Missmut gegen die Projektführung äußert, dazu gehören bspw. Jan, AndreasI und ich.

Kritisch sein ist gut. Alles hat irgendwie seine Grenzen. Zumal hier ein großer zustrom von verschiedenen neuen Leuten herrscht.
Schlussendlich geht es doch um die Sache "mit und für Contao" und nicht um "Gladiatoren Kämpfe" die mit geschlossenen Themen enden.

Also ist die Frage: Wie bekommen wir optisch und technisch hochwertige Themes, die wirklich für Contao gemacht sind, in den offiziellen Store.

Genau ... und dafür eine Lösung zu finden, wäre es doch noch Wert zu diskutieren.

[tril]

Was mich gestört hat ist die Art und Weise wie Du Deinem Ärger hier Luft gemacht hast.

Jan war doch friedlich
kA wie man sich an der Art und Weise stören kann.
Jan war halt - zurecht - frustriert, ja und?

Danke das die Diskusion hier jetzt auf einer Sachlicheren Ebene abgeht.

Hättest du dir diesen Kommentar:

... aber Du solltest hier nicht wieder eine Grundsatzdiskussion losbrechen die eh nichts bringt.

einfach gespart, wären wir bereits 10 Beiträge früher dort gelandet

Eine Grundsatzdiskussion bringt immer etwas und wenn es nur ist, dass man feststellt "hoppla, die Diskussion ist jetzt schon zum 10. mal ausgebrochen, jetzt müssen wir irgendwas machen".
Eine Diskussion abbrechen kann man nur in 2 Fällen:
1. die Diskussion wird an anderer Stelle geführt
(trifft hier nicht zu, denn der andere Thread ist bereits out of date)
2. es wird bereits an einer Lösung gearbeitet
(trifft ebenfalls offensichtlich nicht zu)

Also, versuche schlichtweg nächstes mal nicht, eine Diskussion abzubrechen, nur weil dir der Tonfall des Autors nicht passt. Gerade ein negativer Tonfall ist oft Indiz für die Wichtigkeit des Themas.
In meinen Augen hast du den Gladiatorenkampf angefangen und nicht Jan, AndreasI oder ich.

Zumindest hast du selbst eingesehen, dass die Diskussion doch notwendig ist, aber das musste trotzdem nochmal gesagt werden

So long, tril the third musketeer

[jan.theofel]

Hi Stefan,

Ich kenne jetzt das Theme nicht, aber ich frage mich jetzt, funktioniert es jetzt nicht ohne das Du den Lötkolben ansetzt? Sprich, ist es so "out of the box" nicht funktionsfähig oder entsprecht es einfach nur nicht Deinen Vorstellungen eines korrekten Aufbaus?

In den Beschreibungen zum Theme steht eindeutig, das es angepasste Templates und ein externes CSS Framework verwendet.

Um mal bei dem Mercedes-Vergleich zu bleiben: Ja der fährt auch noch, wenn man ihm den Motor rausnimmt und statt dessen Pedale einbaut. Aber die wesentliche Funktion - ein leistungsstarker Motor - fehlt.

Jan

[jan.theofel]

Hi,

Bei den Themen handelt es sich eher um ein Sonder-Zubehör, und solches wird bei vielen Autos auch von anderen Firmen zugeliefert oder über eine Generalagentur weiter vertrieben, weil man dem Kunde einen erweiterten Service bieten will. Aber schlussendlich wenn das Radio oder der Sportheckspoiler einen defekt aufweist, wird man auf die Garantie des Zulieferers verwiesen. Und das wird dann meistens auch so von den Autofirmen vorab kommuniziert.

Ich habe mein Sonderzubehör aber nicht bei irgend einem Schrauber um die Ecke besorgt. Sondern in der eigenen Niederlassung.

Und da achten die hochspenibel darauf, dass das alles in Ordnung ist. Denn alles was sie verkaufen und nicht tut, fällt auf sie zurück, schadet der Marke. Völlig egal, das der Fehler bei einem Hersteller liegt auf den man mit dem Finger verweisen kann.

Etwas offiziell zu verkaufen hat nun mal einen anderen Charakter und genießt ein Vertrauen bei den Käufern. Und dieser Verantwortung sollte man sich bewusst sein und ihr gerecht werden.

Jan

[dackelchen]

https://community.contao.org/de/show...l=1#post227200

Da habe ich schon mal was zu Rock-Solid-Themes gesagt, aber das nur am Rande. Vor allem aber war das zu der Zeit als der Offizielle Themeshop ewig lange nicht erreichbar war. Inzwischen habe ich einige Kaufthemes (nicht nur RST und nicht nur aus dem Offizellen Shop) für andere nach deren Wünschen angepasst.

Vor dem Kauf habe ich RST kontaktiert, und wusste genau, was ich bekommen würde. Aber, hätte ich das Theme im offiziellen Themeshop gekauft, hätte ich mich vermutlich schwarz geärgert.

Denn mal im Ernst Leute, da sind Themes im Shop, wo eine Navi entweder hardgekodet in der fe_page steht oder Die Startseitenmodule fast alle in Modulen mit eigenem html liegen.

Und das ist einfach nicht das, was ich erwarte. Zumindest nicht im Offizellen Shop eines CMS (auch außerhalb von Contao)
Leos Shop verstehe ich als Plattform. Wenn es da beispielsweise einen Link zum Ersteller des jeweiligen Themes gäbe, dann könnte man da mal direkt nachfragen…

Aber gerade deshalb finde ich, dass es in der Pflicht des Theme Shop Betreibers liegt, zu prüfen in wie weit sich die Themes vom Contao vorgegebenen Weg distanzieren oder eben nicht. Vor allem für einen Anfänger muss es frustrierend sein, der gerade das Buch vom Peter "Websites erstellen mit Contao" durchgearbeitet hat und anschließend ein Theme installiert, wo er 66% des Buches wegschmeißen kann.

Und genau hier sehe ich den Kern des Problems: Alle wie wir uns hier im Thread tummeln, wissen wir… hoffe ich zumindest… wovon wir reden, Was aber ist denn mit weniger versierteren Contaousern?

Wenn zur Anpassung der Themes an Contao (sodass später ein „normaler Administrator“ damit arbeiten kann, vorher sehr gute Kenntnisse und überdurchschnittliche CSS-Kenntnisse notwendig sind… und vor allem Zeit, dann tut das Contao nicht wirklich gut meine ich. Ich finde es einfach wichtig, auch die mit ins Boot und in die Community zu holen, die neu zu Contao dazustoßen und erst Noch „Contaoprofis“ werden wollen.

Schade übrigens, dass sich von denen keiner hier im Thread tummelt. Denn um die geht es ja eigentlich…

[Nina]

Ich denke, dass es keinen Sinn macht, sich hier die Köpfe einzuschlagen. Viel wichtiger wären konkrete Vorschläge, wie die Situation für Kaufende klarer/besser werden könnte. Ob Leo diese dann integriert, ist natürlich seine Sache, aber konstruktives Ideensammeln macht auf jeden Fall mehr Sinn als wildes Missverstehen/Frustschieben

Hier mal meine - natürlich nicht "offizielle Team-" - Meinung zu Themes im Contao-Themestore:

Ich denke, dass es aktuell eine zu geringe Unterscheidbarkeit in Bezug auf Template-Modifizierungen gibt. Es gibt nur schwarz (modifiziert) oder weiß (unmodifiziert). Bei modifizierten Templates gibt es aber riesige Bandbreite:

• Der eine arbeitet basierend auf dem Contao-Framework und schreibt minimal das Navigations-Template um oder ergänzt ein einzelnes DIV im fe-Template. Bei zukünftigen Contao-Updates ist das eine Kleinigkeit die nur minimalste Handarbeit beim Update bedeutet. Zudem basiert es auf den üblichen Herangehensweisen die in Büchern, Videos, etc rund um Contao propagandiert werden, was den Einstieg oder Änderungen erleichtert.
• Der andere arbeitet nicht auf dem Contao-Framework und strickt Templates radikal (wie oben beschrieben) um. Bei zukünftigen Contao-Updates könnte das extrem viel Handarbeit bedeuten bzw. es könnte sehr schwierig sein sich in sowas reinzuarbeiten.

Deshalb plädiere ich da für eine klarere Unterscheidbarkeit bei den Filtern im Theme-Shop, z.B. nach diesem Schema:

Templates:

• Unmodifizierte Standard-Templates
• Leicht modifizierte Standard-Templates
• Stark modifizierte Templates

Framework:

• Contao-Framework
• XYZ-Framework
• Sonstiges

Natürlich müsste es dann z.B. in den FAQ eine Erläuterung geben, was diese Unterteilung in Hinsicht auf Standardaufbau, Wartbarkeit, etc. voraussichtlich bedeutet.

Eine Kommentarfunktion fände ich auch für Kunden zur Orientierung sehr hilfreich. Es müsste halt sicher gestellt werden, dass da nur Kommentare reinkommen, die sachliche Informationen zum Theme bieten. Das wäre aber mit einem "externen" Moderationsaufwand verbunden, denn eine einfache Übergabe in die Hände des Theme-Anbieters würde sicher bedeuten, dass der eine oder andere Anbieter dazu neigen würde, kritische Stimmen generell zu löschen und somit der eigentliche Sinn der Kommentarfunktion hinfällig wäre.

Eine Sternchen-Bewertungsfunktion o.ä. finde ich hingegen schwierig, da die Maßstäbe unklar sind. Ein völlig unerfahrener Erstnutzer von Contao scheitert möglicherweise an jedem Theme, weil er einfach keinen Plan und keine Lust zur mindesten Einarbeitung hat. Er würde dann vielleicht eine ungerechtfertigte Abwertung geben - wenn diese im schlimmsten Fall noch ohne Kommentar, nur via Sternchen erfolgt, wäre das eine fatale Fehlinformation.

[Nina]

Damit keine Missverständnisse aufkommen:

Ein starkes Abweichen vom Contao HTML-Framework ist NICHT "furchtbar", sondern ein Zeichen dafür wie flexibel Contao ist, weil man das damit machen kann. Wenn also Agenturen Websites für Kunden bauen und dafür z.B. im Framework auf Boilerplate, YAML, o.ä. ausweichen, weil sie diese Frameworks bevorzugen, ist das natürlich völlig in Ordnung und nachvollziehbar. Diese Agenturen haben etwaigen Mehraufwand bei Updates gegen die Vorteile eines anderen Frameworks abgewogen und wissen (im Idealfall) genau was sie da tun.

Bei Kauf-Themes sehe ich die Sache skeptischer. Als Kunde würde ich im Theme-Shop des offiziellen Projekts auch erwarten, dass die Themes auf dem Core-System basieren und nur dann abweichen, wenn es halt wirklich nötig ist ... weil ich davon ausgehe, dass die Masse der Käufer eines Themes nicht automatisch das nötige Hintergrundwissen hat um ernsthaft abschätzen zu können, was der Einsatz eines anderen HTML-Frameworks bedeutet.

Realistischer Weise wird es aber natürlich Anbieter geben, die auf einem anderen HTML-Framework arbeiten und ihre Themes dennoch anbieten wollen. Dass diese im Theme-Shop auf contao.org angeboten werden, ist Leos Entscheidung als wirtschaftlicher Anbieter hinter der Shop-Plattform, die er natürlich genau so treffen kann und es auch legitimer Weise getan hat. Wie oben geschrieben und mit Vorschlägen unterlegt, fände ich es aber hilfreich, wenn dann für solche Themes dem möglicherweise unerfahrenen Kunden durch standardisierte Filter und Informationen dazu die Unterschiede zwischen Themes besser klargemacht werden.

[ciaobello]

Deshalb plädiere ich da für eine klarere Unterscheidbarkeit bei den Filtern im Theme-Shop, z.B. nach diesem Schema:

Das könnte man dann auch noch farblich abgrenzen:
grün = 100% Contao
gelb = leicht angepasst
rot = vorsicht ... da wird mit anderen Techniken gearbeitet welche nicht standardmäßig in Contao angeboten werden.

Der Knackpunkt wird wohl nicht die Unterscheidbarkeit sein, ich denke vielmehr, wer sich die Zeit nimmt so ein Whitepaper (oder wie man das nennen soll), erstellt und es dem Leo präsentiert damit er es absegnen und beim Shop einbauen kann.

Hier mal meine - natürlich nicht "offizielle Team-" - Meinung zu Themes im Contao-Themestore:

<humor> Ich schlage mal vor, dass Du die Avatar Überschrift von den neuen Team Mitgliedern anpasst ... die kriegen sonst noch ein Kompex wenn sie nicht auch dementsprechend angespochen/angezeigt werden hier im Forum </humor>

[jan.theofel]

Hi Nina,

Templates:

• Unmodifizierte Standard-Templates
• Leicht modifizierte Standard-Templates
• Stark modifizierte Templates

Dazu noch eine Überlegung:

Als Grundlage auch stark modifizierter Templates dienen aus meiner Sicht ja dennoch immer jene vom Contao Core. Diese müssten somit unter die LGPL fallen. Wir sollten diese also im Shop veröffentlichen dürfen - schon vor dem Kauf. Dann könnte sich jeder selbst ein Bild davon machen, wie viel modizifiert wurde und ob die Modifikationen dokumentiert sind. (Ich mache das z.B. über einen PHP-Kommentar im Template.)

Beim CSS hilft ein Blick in die Demo um dessen Qualität in etwa Abschätzen zu können.

Jan

[Jens_]

Ein kurzer Einwurf, auf die Gefahr hin, dass das hier nicht mehr ganz passt: Aus Sicht eines Content-orientierten Contao-Nutzers breche ich eine Lanze für Themes, die gut funktionieren und für breite Einsatzzwecke geeignet sind. Die technische Umsetzung ist für viele sehr relevant, für mich nur vom Ergebnis her: Wenn meine Einsatzwünsche und der Output (das, was hinten rauskommt an Usability, Konfigurierbarkeit, validem Code und Ladezeitrelevanz) passt, nehme ich auch ein Theme, das vielleicht nicht alle Core-Funktionen nutzt. Entscheidend ist auch dabei für mich, wie es in der Praxis dann mit Updates und Anpassungen läuft. Nachdem ich das Projekt "eigene Themes" erstellen einmal leidlich erfolgreich durch habe und dadurch ein halbes Jahr keinen Content erstellen konnte, bin ich aktuell mit dem Angebot von Rocksolidthemes (trotz der berechtigten Hinweise auf die technischen Einschränkungen) sehr zufrieden.

Weswegen ich das hier schreibe: Mir wären in einem Theme-Shop Bewertungskriterien wichtig, die differenziert bewerten und dabei die technische Core-Nähe als einen Punkt einschätzen. So wie die Vorschläge, die hier schon genannt wurden: Nutzung des Frameworks, CSS-Bearbeitbarkeit, html-Anpassungen. Außerdem sind Punkte wie "updatesicherheit" noch in harte Kriterien zu fassen, also z.B. die Bereitstellung von Updates in einem definierten Zeitraum nach einem Contao-Release. Das ist bei den Erweiterungen auch immer so ein Problem, wo man sich aber noch mit möglichst wenigen Erweiterungen helfen kann. Bei einem Theme wird man schnell abhängig...

Das von mir, wo ich doch einer bin, der weniger versiert ist...

[jan.theofel]

Hi,

... Usability, Konfigurierbarkeit...

Genau das ist es ja, was ich dem Template ankreide: Ein Modul in den Header einfügen (=Konfigurierbarkeit)? Vergeblich. Den normalen Contao-Workflow nutzen (=Usability)? Nicht möglich.

Jan

[Nina]

Ich habe ein Thema zu "Was erwartet ihr von Contao-Themes" gestartet. Meine Hoffnung ist, dass wir damit eine Liste von guten/weniger guten Dingen sammeln können, an denen sich Theme-Hersteller orientieren können.

[RockSolid Themes]

Hallo, liebe Contao Community,

die Diskussion rund um unser Theme 80/20 freut uns. Wir sind laufend in Kontakt mit Anwendern und anderen Experten um unsere Produkte zu verbessern. Leider wurde bei einigen Beiträgen nicht daran gedacht, dass der eigene Ansatz nicht immer das Ende der Fahnenstange ist. Deshalb möchten wir kurz Stellung nehmen und die eine oder andere technische Entscheidung erläutern.

So ist das fe_page.html5 massiv angepasst. Statt den Header wie in Contao üblich aus Modulen zusammenzusetzen wurde hier <?php echo $this->header; ?> komplett(!!!) entfernt und manuell alles von Hand reingecodet was dort hin soll. Inklusive dem Missbrauch eines eigenen Layoutbereichs.

um mich zu korrigieren: <?php echo $this->header; ?> wird eingebunden. Aber nicht im Head sondern in etwas, was sie Tagline nennen. Double-Fail. :-(

Der Header beim Theme 80/20 ist der Bereich über dem Inhaltsbereich und der Sidebar. Diese Wahl wurde getroffen, damit Artikel oder Module, die ein Benutzer in die "Kopfzeile" einfügt, dort angezeigt werden. Wir vergeben die Bereiche Kopfzeile, Fußzeile, Linke-Spalte, usw. bei jedem Theme möglichst so, dass sie für Redakteure intuitiv begreifbar sind.

Was bedeutet wir "missbrauchen" den eigenen Layoutbereich?

Die Änderungen an den Templates haben gute Gründe. Wir übernehmen etwa einige Best-Practises der HTML5-Boilerplate, die man mittlerweile als Industriestandard bezeichnen kann. Unter anderem haben wir die Technik zum Laden von Google-Fonts für IE8 optimiert, den Video-Player angepasst um variable Breiten zu unterstützen, den original YouTube-Player hinzugefügt, uvm... Dort wo es nötig war, haben uns wir bewusst für die Anpassung der Templates entschieden.

Unabhängig von den Optimierungen wäre es schlichtweg nicht möglich unsere Themes, so wie sie sind, ohne Anpassung der Templates umzusetzen. In Zeiten von Responsive Design benötigt man teilweise einen Wrapper mehr oder weniger bzw. muss auf eine sinnvolle HTML-Struktur achten. Websites die nur aus Header, Footer und zwei Sidebars bestehen sind schon lange nicht mehr die Regel. Banales Beispiel: Bei manchen Themes liegt der Footer im Wrapper, bei manchen außerhalb. Um diese Anforderung besser (bzw. Contao-konform) umsetzen zu können, müsste Contao einem mehr Kontrolle über das entstehende Markup geben.

Bisher sind keinem unserer Kunden durch die geänderten Templates Schwierigkeiten entstanden, selbst bei großen Versionssprüngen waren nur kleine Anpassungen nötig – die wir jeweils sauber dokumentiert haben.

Genau so schlimm die fe_page_home.html5. Dort wird eine Variable gesetzt um dann die fe_page.html5 zu inkludieren. Diese Variable setzt dann eine Body-Klasse für die Startseite. Statt das man sie einfach in das dafür vorgesehene Feld(!) im Seitenlayout einträgt.

Hier sollten wir nachbessern, das ist richtig. Diese Vorgehensweise wurde ursprünglich verwendet, um für das Startseitenlayout einen anderen HTML-Aufbau zu erreichen. In der nächsten Theme-Version wird dieser Teil verbessert.

Ich will gar nicht wissen, was mich in den anderen 20 Templates noch an unnötigem Code erwartet.

Wenn du noch weitere Anregungen oder Fragen zu den Anpassungen der Templates hast, freuen wir uns wenn du uns direkt kontaktierst: http://help.rocksolidthemes.com/discussion/new

Dann wirf doch mal bitte ein Blick auf das Layout 80/20 und nenn mir eine Stelle, an der ich zwingend ein angepasstes Template brauche.

Zeile 2-5: CSS-Klassen für alte Internet Explorer mit Conditional-Comments
Zeile 9: Meta-Tag zum deaktivieren der IE-Kompatibilitätsansicht
Zeile 28: verbesserte Technik zum laden von Google-Fonts für IE8: http://www.smashingmagazine.com/2012...gle-web-fonts/

Denn das hier zeigt, dass der Macher keine Ahnung von Contao hat.

Nochmals, wir freuen uns über deine Kritik. In diesem Punkt schießt du jedoch deutlich übers Ziel hinaus. Wir haben größtes Verständnis dafür, dass du überzeugt von deinem Arbeitsablauf und Ansätzen bist. Auch, dass dir die in der Contao Community üblichen Methoden bereits ins Blut übergegangen sind und du die Methoden mit Zähnen und Klauen verteidigst ist gut. Natürlich sind wir selbst Verfechter von Standards und halten uns weitgehend an die in der jeweiligen Szene üblichen Techniken. Allerdings sollte nicht jede Abweichung direkt ein Anlass für Zweifel an unserer Expertise sein. Wie gesagt: In fast allen Fällen sind neue bzw. andere Wege eine bewusste Entscheidung, die im Interesse eines Großteils unserer Kunden getroffen wurde.

Dass nur ein verschwindend kleiner Bruchteil unserer Kunden in einem derartigen Ton von unseren Themes spricht zeigt uns, dass der überwiegende Großteil unserer Kunden zufrieden mit Ihrem Theme ist. Selbst wenn der eine oder andere manches Detail vielleicht anders umgesetzt hätte.

Und übrigens: Wir sind Menschen und Teil dieser Community genau wie du, du kannst dich direkt mit uns unterhalten. Unsere Methoden sind nicht unantastbar und selbstverständlich enthalten unsere Themes den einen oder anderen Fehler. Dennoch sind wir anerkannte Contao-Experten und über eine kleine Portion Freundlichkeit freuen wir uns jeden Tag aufs Neue.

Und nur weil das Theme auch für WordPress angeboten werden soll, ist das noch lange keine Entschuldigung sich völlig an Contao Funktionen vorbei zu mogeln.

Alle RockSolid Themes sind zu 100% auf Contao zugeschnitten. Die Funktionen und Eigenheiten des CMS werden sorgfältig und bewusst einbezogen. Dennoch übernehmen wir nicht blind jede Gegebenheit, sondern wägen von Fall zu Fall ab.

Wir verstehen es als Teil unserer Leistung RockSolid Themes optimal für den Arbeitsablauf (der meisten) unserer Kunden vorzubereiten. Dabei können wir es naturgemäß nicht jedem zu 100% recht machen. Die Anpassung der Templates hat nichts mit der Verfügbarkeit unserer Themes für andere CMS zu tun – wie du an den Anpassungen leicht erkennen kannst.

Für konstruktive Kritik sind wir jederzeit offen, gerne erklären wir jedem Interessierten warum wir welche Anpassung an den Templates durchgeführt haben (einfach unter http://help.rocksolidthemes.com/discussion/new melden). Unsere Themes werden laufend weiterentwickelt und verbessert, dabei freuen wir uns herzlich über das Feedback unserer Kunden und beziehen es aktiv und rasch mit in die Weiterentwicklung unserer Contao Themes ein.

Nochmals vielen Dank für die Diskussion.

Weiterhin einen schönen Tag,
Euer RockSold Themes Support Team

[andreasisaak]

Unabhängig von den Optimierungen wäre es schlichtweg nicht möglich unsere Themes, so wie sie sind, ohne Anpassung der Templates umzusetzen. In Zeiten von Responsive Design benötigt man teilweise einen Wrapper mehr oder weniger bzw. muss auf eine sinnvolle HTML-Struktur achten. Websites die nur aus Header, Footer und zwei Sidebars bestehen sind schon lange nicht mehr die Regel. Banales Beispiel: Bei manchen Themes liegt der Footer im Wrapper, bei manchen außerhalb. Um diese Anforderung besser (bzw. Contao-konform) umsetzen zu können, müsste Contao einem mehr Kontrolle über das entstehende Markup geben.

So schön ich eure Themes vom Design auch finde, das kann ich so einfach nicht stehen lassen! Das Theme 80/20 ist ohne Probleme ohne große Eingriffe in die fe_page umsetzbar. Besonders der Header benötigt keine Anpassungen. Ich will mich nicht mit euch streiten und bin froh das ihr frischen Wind in die Themeszene wehen lässt aber bitte schreibt sowas nicht ohne bedacht zu haben das es jemand widerlegen könnte.

[RockSolid Themes]

Das Theme 80/20 ist ohne Probleme ohne große Eingriffe in die fe_page umsetzbar. Besonders der Header benötigt keine Anpassungen.

Das ist nicht richtig. Es ist nicht möglich ohne Anpassung des Templates fe_page z.B. die Tagline von 80/20 direkt am Anfang des <div id="container"> zu platzieren oder im Footer den Wrapper <div id="nav-footer-wrap"> einzufügen.

[Nina]

Ich habe das spezielle Theme nicht gekauft, so dass ich nur nach dem gehen kann, was ich in der Demo sehe (mal abgesehen davon, dass wir uns imho hier nicht auf ein spezielles Theme und/oder einen speziellen Anbieter versteifen sollten).

Meiner Erfahrung nach, kann ich z.B. den Footer den ich da sehe bauen, ohne für den grundsätzlichen Aufgbau der Rahmen davon die fe_page bearbeiten zu müssen. Ich kann die einzelnen Module in das Seitenlayout packen und auch dort zusätliches HTML für etwaige nötige Rahmen um die Module einbinden (mittels Modul "Eigener HTML-Code").

Es gibt es nur ganz wenige HTML-Rahmen die man nicht mit dieser Methode in ein Layout bekommt. Das wäre z.B.* ein <div id="container-wrapper"> um <div id="container"> herum. In 95% der Fälle bekomme ich aber den HTML-Aufbau selbst ohne Anpassungen in fe_page hin.

* Falls jemand das auch noch ohne Änderung in der fe_page oder anderen Templates und ohne Extension hinbekommt, bin ich über Anregungen dankbar.
Generell möchte ich meine Beiträge zu dieser Diskussion genau so verstanden sehen: Nicht als "an den Pranger stellen", sondern als Anregung "guck mal, mit der Methode geht es besser". Deshalb finde ich auch jeden Theme-Hersteller bewunderswert, der sich sachlich und konstruktiv in die Diskussion einschaltet, da wir gemeinsam mögliche Schwachstellen bisheriger Umsetzung erkennen und gemeinsam die Themes rund um Contao in der Qualität noch mehr verbessern können.

[andreasisaak]

Nicht falsch verstehen, mein letzter Beitrag war auch nicht als "an den Pranger stellen" gedacht aber ich bleibe erstmal bei meiner Aussage. Ich kann es gerne beweisen und das Theme nachbauen.

[jan.theofel]

Hi,

Der Header beim Theme 80/20 ist der Bereich über dem Inhaltsbereich und der Sidebar. Diese Wahl wurde getroffen, damit Artikel oder Module, die ein Benutzer in die "Kopfzeile" einfügt, dort angezeigt werden. Wir vergeben die Bereiche Kopfzeile, Fußzeile, Linke-Spalte, usw. bei jedem Theme möglichst so, dass sie für Redakteure intuitiv begreifbar sind.

Geschenkt. Aber genau so ein Standard-Layout sieht Contao vor. Das man hier und da noch ein DIV einbauen muss ok. Aber mehr auch nicht.

Und nichts, was es rechtfertigt nicht die Module der Themes zu verwenden und sie in den Header, die Sidebar, etc. einzubinden.

Was bedeutet wir "missbrauchen" den eigenen Layoutbereich?

Würdet ihr die Module wie von Contao vorgesehen verwenden solltet ihr vermutlich sogar ganz ohne eigene Layoutbereiche auskommen.

Unabhängig von den Optimierungen wäre es schlichtweg nicht möglich unsere Themes, so wie sie sind, ohne Anpassung der Templates umzusetzen.

Ein Wrapper mehr im Template, weil man es wirklich braucht ist etwas ganz anderes als den grundlegenden Modul-Mechanismus von Contao darin auszuhebeln.

Zeile 2-5: CSS-Klassen für alte Internet Explorer mit Conditional-Comments

In Contao überflüssig: https://contao.org/de/news/vergesst-...ontao-210.html Ein Blick in eine Contao-Standard-Installation hätte genügt um diese Browserklassen zu finden.

Zeile 9: Meta-Tag zum deaktivieren der IE-Kompatibilitätsansicht
Zeile 28: verbesserte Technik zum laden von Google-Fonts für IE8: http://www.smashingmagazine.com/2012...gle-web-fonts/

Auch kein Grund für eine Template-Anpassung. Themes -> Seitenlayouts -> Zusätzliche <head>-Tags.

Nochmal: Es gibt Gründe für geringfügige Template-Anpassungen. Das sind aus meiner Sicht keine haltbaren.

Oder anders: Eure Antworten bestärken mich leider darin, dass ihr euch nicht wirklich (ausreichend) mit dem Contao-System auseinandergesetzt habt.

Jan

[Nina]

Zeile 2-5: CSS-Klassen für alte Internet Explorer mit Conditional-Comments

Du meinst das hier?

<!doctype html>
<!--[if lt IE 8]>      <html class="no-js lt-ie10 lt-ie9 lt-ie8" lang="de"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie10 lt-ie9" lang="de"> <![endif]-->
<!--[if IE 9]>         <html class="no-js lt-ie10" lang="de"> <![endif]-->
<!--[if gt IE 9]><!--> <html class="no-js" lang="de"> <!--<![endif]-->
<head>

Wenn ihr das nutzen wollt, ist es imho korrekt, dass man das nur in der fe_page einstellen kann. Wenn ein Anbieter diesen Weg gehen will (wie er u.a. bei Boilerplate üblich ist), ist das seine Wahl und akzeptabel. Es gibt natürlich für den eigentlichen Ansatz dahinter auch einen "Contao-Weg", aber der ist bekanntlich kein Muss.

Zeile 9: Meta-Tag zum deaktivieren der IE-Kompatibilitätsansicht

Kann im Seitenlayout bei der Textarea "zusätzliche <head>-Tags" eingebunden werden.

Zeile 28: verbesserte Technik zum laden von Google-Fonts für IE8: http://www.smashingmagazine.com/2012...gle-web-fonts/

Dito. Einfach nicht das Google Fonts-Feld im Seitenlayout nutzen und stattdessen den Code in das Feld der zusätzlichen head-Tags im Seitenlayout einfügen.

Ein entscheidender Vorteil der zusätzlichen head-Elemente Textarea im Seitenlayout ist auch, dass man so pro Seitenlayout Angaben hinzufügen kann und nicht jeweils eine neue fe_page dafür anlegen und modifizieren muss.

[RockSolid Themes]

Ich kann die einzelnen Module in das Seitenlayout packen und auch dort zusätliches HTML für etwaige nötige Rahmen um die Module einbinden (mittels Modul "Eigener HTML-Code").

Verstehen wir dich richtig: Du schlägst vor für jeden Wrapper (oder Rahmen) zwei HTML-Code-Module anzulegen und diese dann vor und nach den gewünschten Modulen einzubinden? Damit könnte man manche Wrapper-Probleme lösen, wenngleich diese Herangehensweise aus unserer Sicht sehr unübersichtlich wird sobald man mehrere Wrapper benötigt. Bleiben die Fragen wie man Module direkt am Anfang des <div id="container"> oder den Footer außerhalb des <div id="wrapper"> bekommt.

In Contao überflüssig: https://contao.org/de/news/vergesst-...ontao-210.html Ein Blick in eine Contao-Standard-Installation hätte genügt um diese Browserklassen zu finden.

Diese Browserklassen sind uns bekannt, allerdings basieren sie auf User-Agent-Sniffing und deshalb haben wir uns gegen den Einsatz entschieden.

Auch kein Grund für eine Template-Anpassung. Themes -> Seitenlayouts -> Zusätzliche <head>-Tags.

Zeile 9: Meta-Tag zum deaktivieren der IE-Kompatibilitätsansicht
Kann im Seitenlayout bei den zusätzlichen head-Elementen eingebunden werden.

Der X-UA-Compatible-Meta-Tag muss am Anfang des Heads stehen. Das ist mit den zusätzlichen <head>-Tags nicht möglich.

Zitat von Mircrosoft:

The X-UA-Compatible header isn't case sensitive; however, it must appear in the header of the webpage (the HEAD section) before all other elements except for the title element and other meta elements.

Zeile 28: verbesserte Technik zum laden von Google-Fonts für IE8: http://www.smashingmagazine.com/2012...gle-web-fonts/
Dito. Einfach nicht das Google Fonts-Feld im Seitenlayout nutzen und stattdessen den Code in das Feld der zusätzlichen head-Elemente im Seitenlayout einfügen.

Da wir ohnehin ein angepasstes Template benötigen, haben wir uns dazu entschieden auch diesen Teil ins Template zu verlagern. Möchte ein Kunde einen anderen Google-Font verwenden, muss er nur eine Stelle bearbeiten, anstatt dieselben Änderungen in allen Seitenlayouts durchführen zu müssen.

[Nina]

Verstehen wir dich richtig: Du schlägst vor für jeden Wrapper (oder Rahmen) zwei HTML-Code-Module anzulegen und diese dann vor und nach den gewünschten Modulen einzubinden? Damit könnte man manche Wrapper-Probleme lösen, wenngleich diese Herangehensweise aus unserer Sicht sehr unübersichtlich wird sobald man mehrere Wrapper benötigt. Bleiben die Fragen wie man Module direkt am Anfang des <div id="container"> oder den Footer außerhalb des <div id="wrapper"> bekommt.

Im Grunde ja, das schlage ich vor. Wobei man natürlich bei guter Planung kombinieren kann.
Die Übersichtlichkeit erhält man dadurch, dass man die Module wirklich sinnvoll benennt und dadurch eine klare Hierarchie schafft.

The X-UA-Compatible header isn't case sensitive; however, it must appear in the header of the webpage (the HEAD section) before all other elements except for the title element and other meta elements.

Danke für den Hinweis, man lernt nie aus

[andreasisaak]

Den Metatag kann man auch alternativ via .htaccess setzen!

Header set X-UA-Compatible "IE=edge"

http://www.456bereastreet.com/archiv...ble_and_html5/

But before doing any of the above, consider whether you really need that header at all.

Nur weil es die HTML5 Boilerplate macht, muss es nicht immer richtig sein.

[RockSolid Themes]

Den Metatag kann man auch alternativ via .htaccess setzen!

Header set X-UA-Compatible "IE=edge"

http://www.456bereastreet.com/archiv...ble_and_html5/

Nur weil es die HTML5 Boilerplate macht, muss es nicht immer richtig sein.

Das ist richtig, wenn möglich sollte man diesen Header immer via .htaccess setzen, genau so macht es auch die HTML5 Boilerplate. Allerdings können wir in einem Theme keine Änderungen an der .htaccess-Datei vornehmen.

[andreasisaak]

Nein ich meine generell den Flag zu setzen.

[andreasisaak]

Da ich persönlich nicht das Gefühl habe das auf die Expertise der Community vertraut wird (die nun mal etwas mehr Websites mit Contao umgesetzt haben als eine handvoll Themes) ziehe ich mich aus dieser Diskussion zurück und entwickle bei Zeiten ein eigenes Theme. Es bringt nichts zu diskutieren wenn sich jeder nur rechtfertigt und gefühlt niemand von seiner Meinung abrücken will.

Mein Tipp ist nur - nicht alles was der liebe Paul Irish von sich gibt ist immer notwendig für ein Theme was für Leute gedacht ist, die selber keine eigenen bauen können. Sei es das erkennen der IE's anhand massiver Conditional Comments oder das deaktivieren der Kompatibilitätsansicht. Manchmal ist weniger mehr.

[jan.theofel]

Hi,

Da ich persönlich nicht das Gefühl habe das auf die Expertise der Community vertraut wird (die nun mal etwas mehr Websites mit Contao umgesetzt haben als eine handvoll Themes) ziehe ich mich aus dieser Diskussion zurück und entwickle bei Zeiten ein eigenes Theme. Es bringt nichts zu diskutieren wenn sich jeder nur rechtfertigt und gefühlt niemand von seiner Meinung abrücken will.

Jou. Ich freue mich auf Themes von euch. Die kann ich dann wenigstens ruhigen Gewissens kaufen...

Jan Theofel

[dackelchen]

Wow, könnt Ihr argumentieren...

Problem, wer kann Euch da noch folgen? Ich denke, es geht immer noch in diesem Thread um Leos Shop, vor allem aber um Contao. Wenn es "Schwächen" in Contao gibt, dann gehören die nicht in diesen Thread, sondern müssen anderswo angesprochen werden. Wer bei Leo im Shop einkauft, für den ist die Entscheidung längst gefallen. Der oder die macht eine Seite mit Contao. Und darum meine ich, die Themes im Offizieöllen Shop sollten sich möglicht nahe am Contaoweg orientieren, um es den Käufern möglicht einfach zu machen.

Wer kauft sich denn ein iphone und installiert darauf dann Andriod oder umgekehrt... falls das überhsaupt funktioniert???

[tril]

Wer kauft sich denn ein iphone und installiert darauf dann Andriod oder umgekehrt... falls das überhsaupt funktioniert???

Android auf iPhone funktioniert (zumindest mit älteren Geräten)
http://www.chip.de/news/iDroid-Andro..._56857922.html

[dackelchen]

oki, aber gib's zu. Das wäre dann doch "very special"

[MacKP]

Hmm eigentlich wollte ich ja dazu gar nichts schreiben, da ich selber glaube ich nie ein Theme anbieten werde und bisher versucht habe kein Theme zu kaufen (einmal hab ich das gemacht... aber naja...).

Ich muss sagen, das ich es unsinnig finde, den Leuten verbieten zu wollen in einem Theme die fe_page bzw. Templates anzupassen. Ich selber mache das liebend gerne und sehr umfangreich, da ich es zu schätzen weiß, wie einfach das in Contao ist und wie viel einfacher/schneller/schöner es für mich ist.
Mir ist bewußt, das vieles auch so geht mit der Contao Vorlage. Die für mich aber nichts anderes ist als eben eine Vorlage. Fangen wir mal mit Holy-Grail an. Das ist für mich wieder ein Punkt, genau deswegen nicht das Contao Framework zu nehmen und alles mögliche Umzubauen, da Holy-Grail eben nicht immer passt. Klar brauch man auch dafür noch keine Template anpassung.. aber was solls? Skiplinks bringe ich immer direkt nach dem <body> -> Template Anpassung. Wenn ich ein Theme und ein Template darin anbieten würde, dann würde ich das genau so machen. Fertig.

Wenn wir dann mal zum Offiziellen Shop kommen: Leo sagt selber: Templates sind eben zum anpassen da. Dann kann man das natürlich auch für ein Theme machen. Also wäre die sinnvolle Schlussfolgerung, das man das richtig kennzeichnet. Eventuell sogar mit Beispielen der Anpassungen vor dem Kauf (ein paar Screens von der fe_page oder so). Und gut ist die Sache. Wenn ihr Themes nicht mögt, die solche Anpassungen haben, dann braucht ihr die nicht kaufen. Leute die sich Themes kaufen wollen einfach nur was schickes haben, wo man die Farben ein wenig anpassen kann. Das geht jetzt einfacher mit den Variablen. Schön. Oder man legt eine eingene CSS Datei an, wo nur Farbdefinitionen sind.. ist vllt sogar noch einfacher, weil dann auch ein Zusammenhanb zu sehen ist, wenn die Klassen gut benannt sind (im Gegensatz zu den meisten Variablen).

Eigentlich will ich damit nur eins sagen: Alles Geschmackssache! Und Contao ist so gut, weil da jeder machen kann was er will. Also sollten auch Themes in so einer Vielfallt vorhanden sein. Ich selber würde mir wenn dann ein Theme kaufen was schon in Sass übersetzt ist ;-)

Viele Grüße

[Mag....]

@mack ich verfolge diesen verlauf nun etwas...aber besser koennte ich es nicht ausdruecken

Gesendet von meinem LG-P880 mit Tapatalk 2

[Barbfish]

Hallo,
ich darf mich mal kurz dazwischen schalten. Ich bin kein Entwickler sondern Anwender (einer der weniger versierteren Contaousern ) und bin auf der Suche nach einem responsive Theme. Bis ich diesen ganzen Thread durch hatte, bin ich davon ausgegangen, dass diese angebotenen Themes in 'Contao-Manier' erstellt wurden und wie bisher - ohne Überraschungen - einfach zu installieren und anzupassen sind. Dann lese ich plötzlich, dass das und das nicht so funktioniert, etc. pp. - ich bin ehrlich entsetzt und verunsichert. Habe dann auch mal die Filter ausprobiert - es wurde weiterhin ein Theme angezeigt, das lt. diesem Thread hier, nicht so funktioniert wie es vom User bei der Filteranwendung zu erwarten ist.

Bisher bin ich von Contao (noch) wirklich begeistert. Nachdem auch eine sehr praktikable Mehrsprachigkeits-Extension wohl nicht mehr weiterentwickelt wird, gibt mir der obige Thread zusätzlich sehr zu denken. Vielleicht gibt euch das ja zu denken. Ich möchte jedenfalls kein Theme kaufen und dann feststellen, dass es nicht in Contao-Manier funktioniert - denke nämlich nicht, dass ich irgendwie mein Geld zurückbekommen würde - und selbst wenn - wie sieht es mit dem nächsten Theme aus - funktioniert das? Ist ja wie die Katze im Sack kaufen - das enttäuscht. Ich kann Jan und Edgar nur voll und ganz zustimmen.

Barb

PS: Aber ein ganz großes Lob, dass das hier alles so offen ausgesprochen und angesprochen wird! Lieben Dank an alle für eure Konstruktivität!

[Gestalterrier]

Mich hat dieses Thema doch sehr verunsichert und ich frage mich, ob meine Entscheidung für Contao die richtige ist. Da ich bisher noch nichts damit umgesetzt habe, ist dies keine endgültige, daher überlege ich, ob ich diese nicht vielleicht überdenken sollte. Wobei mir aber eigentlich Contao noch am sympathischsten ist (siehe die Biografie in meinem Profil).

Privat fehlen mir Muße und vor allem die Zeit, ein Theme komplett eigenständig aufzubauen. Ich benötige mit meinen Kenntnissen keine Backendeinstellungen, sondern kann sehr gut auch direkt per CSS Anpassungen vornehmen. Auf der Suche nach dem passenden Theme muss ich nach dem Lesen dieser Diskussion wohl etwas vorsichtiger sein als gedacht. Und was mich auch wundert: Kann man hier echt nicht mit updatesicheren Child-Themes arbeiten?

[Nina]

Mich hat dieses Thema doch sehr verunsichert und ich frage mich, ob meine Entscheidung für Contao die richtige ist. Da ich bisher noch nichts damit umgesetzt habe, ist dies keine endgültige, daher überlege ich, ob ich diese nicht vielleicht überdenken sollte. Wobei mir aber eigentlich Contao noch am sympathischsten ist (siehe die Biografie in meinem Profil).

Was verunsichert dich daran so sehr, dass du gleich das ganze CMS in Frage stellst? Die Logik erschließt sich mir ehrlich gesagt nicht.

[MacKP]

Hallo Gestalterrier,
ich versteh das auch noch nicht so ganz.

1.
Ja, man sollte gucken was man kauft. Das hast du aber überall.
Da kann das CMS nichts für, sondern die Leute die das Theme oder das Layout erstellen.

2.
Der von dir verlinkte Thread:
Der Sprung von Contao 2 auf 3 war sehr weitreichend mit vielen Änderungen. Das erkennt man daran, das sich die erste Zahl geändert hat. Wie immer bei Software. Dabei wurde auch der HTML Code angepasst, so das nun die Holy-Grail Methode zum einsatz kommt. Da funktionieren alte Themes nicht einfach so. In der Regel bekommt man dann aber ein update von dem Theme oder kann das dann kaufen. Wenn man aber ein Theme dann auch noch extrem anpasst, dann kann man nicht erwarten, das es einfach geht, ohne das man da wieder selber ran muss.

3. Ich weiß überhaupt nicht was Child-Themes sein sollen...

4. Wenn du das ganze beruflich machst, dann wirst du dich auch damit beschäftigen müssen. Wenn du CSS schreibst (mal als vergleich) wird das auch kaum was tolles werden, wenn du nicht mal nachliest, was die Befehle so machen ;-)

5. Deine Entscheidung kann dir ansonsten keiner abnehmen. Probier es einfach aus! (und ich wünsche dir viel Spaß dabei)

Viele Grüße

[lucina]

3. Ich weiß überhaupt nicht was Child-Themes sein sollen...

Einer der vielen Wege und Irrwege des WP-Universums: ein Child-Theme überschreibt gewisse Sachen des Parent-Themes - sollte dann eigentlich besser zu pflegen sein. Siehe http://codex.wordpress.org/Child_Themes

[Nina]

ein Child-Theme überschreibt gewisse Sachen des Parent-Themes - sollte dann eigentlich besser zu pflegen sein.

Yup, das ist eine Sache die ich schon mal angesprochen hatte. Sowas wäre tatsächlich ganz praktisch, da sich manche Seitenlayouts nur in minimalen Einstellungen unterscheiden und man durch Child-Seitenlayouts (so müsste das wohl bei Contao heißen) die Sache ggf. leichter pflegbar machen könnte. Ich würde mir das so vorstellen, dass man ein Master-Seitenlayout anlegt und darin gewisse Bereiche "fixieren" kann. Wenn man dann daraus ein Child-Seitenlayout erstellt, bleiben darin alle fixierten Dinge aus dem Master-Seitenlayout erhalten bzw. aktualisieren sich automatisch, wenn sie im Master verändert werden.

Aber das wäre wohl wirklich eine Sache für ein separates Thema hier im Forum. Bei Interesse kann ich das gerne entsprechend auslagern.

[MacKP]

Ah, danke für die Erleuchtung (man lernt nie aus)!
Ich kann mir schon denken wie das dann läuft.. wo muss ich das nun ändern? äh.. ? ;-)
Naja, wird wie immer Geschmackssache sein und je nach Umsetzung besser oder schlechter zu handhaben.

Viele Grüße

[Gestalterrier]

Vielen Dank für eure Antworten :-)

Die Diskussion hat mich verunsichert, weil es mich wunderte, welche Stolperfallen es allein in diesem Bereich geben kann. Da kam ich schon ins Grübeln, wie durchdacht das nicht nur bei dem Theme-Erstellern, sondern evtl. auch direkt in Contao ist. Aber eure Irritation über meine Irritation beruhigt mich ja schon wieder :-)

Durch Joomla und WordPress habe ich mich mittlerweile daran gewöhnt, Anpassungen nur im äußersten Notfall direkt im Originalcode vorzunehmen. Und Child-Themes erleichtern updatesichere Anpassungen – vor allem, wenn sich diese nicht nur auf ein, zwei CSS-Dateien beschränken, sondern man auch in den HTML/PHP-Dateien Änderungen vornimmt. Da Contao keine Child-Themes unterstützt, bedeuten Updates bei mehr angepassten Themes also viel manuelle Arbeit, sehe ich das richtig?