Feature Request: Eigene Layoutbereiche an unterschiedlichen Position im Layout

[fabian_perrey]

Hallo,

ich weiß nicht man so etwas besser bei github anfragt oder hier? Naja ich hoffe jedoch, dass man auf jeden Fall etwas Feedback bekommt.

Ich nutze Contao nun selbst seit einigen Jahren und bin vom Konzept, der Technik und der Richtung, in die sich das CMS entwickelt, überzeugt.

Vor einigen Versionen kam nun die Möglichkeit eigene Layoubereiche in den Seitenlayouts zu definieren hinzu. Das ist super, da man hierdurch viel flexibler beim Einrichten der Layouts ist, ohne gleich am fe_page schrauben zu müssen.
Es können hierbei zwar mehrere eigene Layoutbereich definiert werden, die Position, an der diese Bereiche im Layout eingesetzt werden sollen, lässt sich nur einmal für alle festlegen.

Besser wäre doch, weil noch flexibler, man könnte die Position im Layout für die eigenen Layoutbereiche unabhängig voneinander festlegen. So dass man z.B. einen Bereich "vor dem umschließenden Element" und noch einen "in der Hauptspalte" definieren kann.

Fände ich ne tolle Sache. Meinungen?

Grüße FP

[webstar]

Gibt es schon als Feature Request (derzeit für 4.1 geplant):
https://github.com/contao/core/issues/6630

Als Extension (über Composer installierbar) schon für Contao 3 (ab 3.2):
https://github.com/netzmacht/contao-flexible-sections

[soweit_ok]

... ohne gleich am fe_page schrauben zu müssen.
...
Besser wäre doch, weil noch flexibler, man könnte die Position im Layout für die eigenen Layoutbereiche unabhängig voneinander festlegen. So dass man z.B. einen Bereich "vor dem umschließenden Element" und noch einen "in der Hauptspalte" definieren kann.

Vielleicht verstand ich Dich falsch, aber die müssen doch auch im fe_page Template positioniert werden. Sie in dem Feld einzutragen allein reicht natürlich nicht.

Ein "eigener Layoutbereich" ist ja nichts weiter als ein DIV-Element mit einer gleichnamigen CSS-Id. Mir ist nicht so recht klar, was genau Du eigentlich meinst. HTML-Elemente lassen sich ja auf diverse Arten erzeugen. Per HTML-Inhaltselement, per HTML-Modul, mit Javascript direkt im DOM - fix oder event-getriggert, oder mit PHP. Musst es noch nichtmal in einem Stück machen. Beispielsweise kann man aus mehreren Elementen bestehende Bereiche zusammenfassen und statisch oder beim Feuern von Events dynamisch mit speziellen CSS-Formatierungen beglücken, wenn als einfach als HTML-Inhaltselement das öffnende TAG davor und das schließende dahinter platziert wird. Dafür kann´s verschiedene Anlässe geben, die ich jetzt nicht aufzähle.

Meine pers. Meinung dazu ist jedenfalls, die bestehenden Formatierungsstandards scheinen mir bei Contao völlig ausreichend und es bestehen daneben zig Möglichkeiten zur komfortablen Layout-Individualisierung. Was dies angeht, bleiben da bei mir jedenfalls, so wie es ist, keine Wünsche offen.

[tab]

Naja, möglich wäre sowas jedenfalls, die fe_page gibt das ja schon jetzt her. Nur, dass halt in der tl_layout momentan keine Möglichkeit besteht, den eigenen Layoutbereichen individuelle Positionen zuzuweisen. Ich denk mal die Namen sind einfach eine kommagetrennte Liste, dann müsste man das bei den Positionen eventuell genauso machen. Das Anlegen der eigenen Layoutbereiche im Seitenlayout könnte man dann besser so ähnlich wie bei den Frontend-Modulen gestalten. Ein Ticket kann also nicht schaden. Ob es dann realisiert wird, ist eine andere Frage. Aber schlecht fände ich das nicht.

Momentan geht das zwar auch, aber halt nur über Änderung der fe_page, indem dort eben die Layoutbereiche an der gewünschten Stelle einzeln über ihren Namen ausgegeben werden. Das ist dann allerdings auch nochmal eine Nummer flexibler, weil ich die Layoutbereiche so wirklich überall ausgeben kann, notfalls sogar im Header, Footer oder den Seitenspalten. Oder sogar ineinander verschachtelt. Auch wenn ich das bisher wirklich noch nie gebraucht habe.

[soweit_ok]

Tja hm, wenn´s denn wohl einige User so gerne haben wollen, nichts dagegen. Ich seh darin trotzdem keinen Vorteil, weil Contao-Einsteiger, die das Layout-Framework noch garnicht verstanden, auch damit vermutlich erstmal nichts anzufangen wüssten und eher verwirrt. Und wenn man es verstand, bräuchte man es eigentlich nicht mehr.

[be-tina]

... nur taucht der Layoutbereich, den man direkt im fe_page Template einträgt nicht im Seitenlayout auf, damit man dort Artikel etc. platzieren kann.

Ich brauche das ständig, weil ich gerne Kopf und Fuß über die volle Browserbreite gehen lasse und dem wrapper eine Maximalbreite zuweise. Meine Lösungen bisher sind hochkompliziert.

Wenn mir also jemand sagen könnte, wie ich es schaffe, den eingefügten div-Kasten im fe_page auch im Seitenlayout auswählen zu können, wäre das echt super.

Noch besser wäre es natürlich, das gleich so zu regeln, wie Fabian das vorgeschlagen hat.

[Spooky]

... nur taucht der Layoutbereich, den man direkt im fe_page Template einträgt nicht im Seitenlayout auf, damit man dort Artikel etc. platzieren kann.

Du musst die eigenen Layoutbereiche im Seitenlayout eintragen und im fe_page Template an der gewünschten Position ausgeben. Die im Seitenlayout angegebenen eigenen Layougbereiche sind dann auch in der Auswahl für die Artikelpositionierung etc. vorhanden. Per langconfig.php kannst du diesen Layoutbereichen für die Ansicht im Backend auch sprechendere Namen geben.

[be-tina]

Im Seitenlayout habe ich aber schon einen eigenen Layoutbereich "oben", der über dem umschließenden Element erscheinen soll.

Wenn ich jetzt noch einen Layoutbereich "unten" einfügen will - wie kann ich im fe_page angeben, dass dieser Layoutbereich unter dem umschließenden Element, also nach dem wrapper, ausgegeben werden soll? Da gibt es zwar die php-Zeile mit der section "bottom" aber wie bekomme ich meinen "unten" Bereich dort ausgegeben?

Ich kann leider kein php und bastle da immer ziemlich laienhaft drin rum.

[be-tina]

Diese php-Zeile mit "bottom" habe ich jetzt kopiert, darüber noch einmal eingefügt und statt "bottom" einfach "unten" hingeschrieben.

Jetzt kann ich "unten" im Seitenlayout auswählen. Der Bereich taucht aber trotzdem noch über dem wrapper auf. Jetzt müsste ich noch die Datei finden, in der dem "unten" Element "top" zugewiesen ist. Oder kann ich das per php im fe_page ändern, also sagen "gib dem eingenen Layoutbereich "unten" statt "top" ein "bottom"".

[Spooky]

Ich kann leider kein php und bastle da immer ziemlich laienhaft drin rum.

Das ist natürlich hinderlich . Ich gehe immer folgendermaßen vor:

Angenommen man will, wie du zB, einen Layoutbereich "Oben" und "Unten" jeweils vor und nach dem #wrapper.

Du gibst dazu im Seitenlayout im Feld "Eigene Layoutbereiche" bspw. "top,bottom" an.

Du editierst die fe_page und entfernst alle

<?php $this->sections('…'); ?>

Anweisungen.

Danach fügst du folgendes vor bzw. nach dem #wrapper in der fe_page ein:

<?php if ($this->sections['top']) $this->section('top'); ?>

<?php if ($this->sections['bottom']) $this->section('bottom'); ?>

Du editierst die langconfig.php und fügst folgendes ein:

$GLOBALS['TL_LANG']['COLS']['top'] = 'Oben';
$GLOBALS['TL_LANG']['COLS']['bottom'] = 'Unten'; 

[tab]

Danach fügst du folgendes vor bzw. nach dem #wrapper in der fe_page ein:

<?php if ($this->sections['top']) $this->section('top'); ?>

<?php if ($this->sections['bottom']) $this->section('bottom'); ?>

Du editierst die langconfig.php und fügst folgendes ein:

$GLOBALS['TL_LANG']['COLS']['top'] = 'Oben';
$GLOBALS['TL_LANG']['COLS']['bottom'] = 'Unten'; 

[/indent]

Das verstehe ich noch nicht so ganz, ist aber sehr interessant! Was genau ist der Unterschied zwischen $this->sections['top'] und $this->section('top')?
Im Standard fe_page Template wird ja einfach $this->sections['top'] ausgegeben. Das habe ich immer so verstanden, dass hier alle Layoutbereiche ausgegeben werden, die als "Vor dem umschliessenden Element" im Seitenlayout angelegt sind. Da 'top' und 'bottom' für mich ausgesehen haben wie spezielle Namen für diese vorgegebenen Positionen, habe ich es bisher immer vermieden, meine Bereiche so zu nennen.

Und dann, vielleicht hängt es ja damit zusammen, warum benennst du die Layoutbereiche erst ausgerechnet 'top' und 'bottom' und änderst dann die Bezeichnung in der langconfig.php? Ich hätte jetzt aus bisheriger Sicht einfach die Bereiche gleich im Seitenlayout 'Oben' und 'Unten' genannt und sie dann mit $this->section('Oben') und $this->section('Unten') ausgegeben.

[Spooky]

Was genau ist der Unterschied zwischen $this->sections['top'] und $this->section('top')?

<?php $this->sections('top'); ?>

Gibt alle eigenen Layoutbereiche an der Stelle 'top' aus. Wo deine eigenen Layoutbereiche ausgegeben werden, stellst du im Seitenlayout ein.

Im Standard fe_page Template wird ja einfach $this->sections['top'] ausgegeben. Das habe ich immer so verstanden, dass hier alle Layoutbereiche ausgegeben werden, die als "Vor dem umschliessenden Element" im Seitenlayout angelegt sind.

Genau.

Und dann, vielleicht hängt es ja damit zusammen, warum benennst du die Layoutbereiche erst ausgerechnet 'top' und 'bottom' und änderst dann die Bezeichnung in der langconfig.php? Ich hätte jetzt aus bisheriger Sicht einfach die Bereiche gleich im Seitenlayout 'Oben' und 'Unten' genannt und sie dann mit $this->section('Oben') und $this->section('Unten') ausgegeben.

'top' und 'bottom' ist quasi die "interne" Bezeichnung, das was du in der langconfig.php dann einträgst ist die im Backend sichtbare Bezeichnung. Ist im Prinzip egal, finde es so aber ästhetischer/sauberer/schöner .


Übrigens mein Code bezieht sich auf Contao 3.5. Deine Beispiele scheinen noch von Contao 3.2. zu stammen.

[be-tina]

@spooky
Das hat geklappt. Aber das div hat nicht das gewohnte Muster mit inside etc. Jetzt müsste ich noch wissen, wo ich dieses Muster eingeben soll.

<?php $this->block('oben'); ?>
<?php if ($this->oben): ?>
<header id="oben">
<div class="inside">
<?= $this->oben ?>
</div>
</header>
<?php endif; ?>
<?php $this->endblock(); ?>


Besser wäre, wenn ich etwas eingeben könnte, dass die Positionierung im Seitenlayout "Eigener Layoutbereich" eliminiert. Dann hätte ich diese custom-divs und könnte diese aber platzieren, wo ich will. Leider muss ich ja eine Platzierung eingeben bei "Eigener Layoutbereich".

Ich müsste also sagen:
Lösche bei "oben" das "top" und füge "obenplatzieren" ein.
Lösche bei "unten" das "top" und füge "untenplatzieren" ein.

Dann könnte ich bei fe_page über dem wrapper einfügen: <?php $this->sections('obenplatzieren'); ?>

und unter dem wrapper: <?php $this->sections('untenplatzieren'); ?>

Geht das irgendwie?

[Spooky]

Du musst es so machen wie ich beschrieben habe... was genau funktioniert da nicht?

// achso, weil .inside fehlt, dann statt

<?php if ($this->sections['top']) $this->section('top'); ?>

folgendes schreiben:

<?php $this->block('top'); ?>
  <?php if ($this->sections['top']): ?>
    <div id="top">
      <div class="inside">
        <?php echo $this->sections['top']; ?>
      </div>
    </div>
  <?php endif; ?>
<?php $this->endblock(); ?>

(Die Block Definition brauchst du nicht zwingend, schadet aber auch nicht.)

Besser wäre, wenn ich etwas eingeben könnte, dass die Positionierung im Seitenlayout "Eigener Layoutbereich" eliminiert. Dann hätte ich diese custom-divs und könnte diese aber platzieren, wo ich will. Leider muss ich ja eine Platzierung eingeben bei "Eigener Layoutbereich".

Nein, musst du nicht. Das war ja der Sinn meiner Anleitung: damit positionierst du die eigenen Layoutbereiche wo du willst. Die Angabe der Positionierung im Seitenlayout ist nach dieser Änderung unerheblich.

[be-tina]

Spooky – Du bist mein Held des Tages !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ich bin begeistert, alles klappt !!!!!!!!!!

Vielen vielen Dank !!!!!!!!!!!

[Grossvater]

Zurück zum Thema:
kann man das ganze auch zeitgesteuert umsetzen? Also ein Layout mit Veröffentlichungsdatum ? Oder ist das zu astronomisch?

[Spooky]

Zurück zum Thema:
kann man das ganze auch zeitgesteuert umsetzen? Also ein Layout mit Veröffentlichungsdatum ? Oder ist das zu astronomisch?

Im fe_page Template kannst du per PHP machen was du willst

[fabian_perrey]

Hallo,

Ich war im Urlaub, deswegen kein Wort die ganze Zeit.

@webstar:
Danke für die Links! Gut zu wissen, dass auch andere das als sinnvoll erachten.

@soweit_ok:
Man kann die Position für custom Bereiche in den Layouteinstellungen aber nur genau einmal für alle Bereiche bestimmen, sie also nicht differenzieren. Das eingangs genannte Szenario von mir (1x "vor dem umschließenden Element" und 1x "in der Hauptspalte") ist nicht möglich ohne "hacks" in der fe_page (sehr gut von Spooky beschrieben). Solche Änderungen am fe_page sollte man meiner Meinung nach, wenn möglich, vermeiden. Außerdem, wenn Contao schon eine Konfiguration für die Seitenlayouts mit custom Bereichen liefert, ist es ja nur logisch, dass das dort auch entsprechend konfigurierbar ist. Der request bei github zeigt ja, dass ich das nicht alleine so sehe.

Beste Grüße
Fabian

[Spooky]

Man könnte sowas durchaus in einer eigenen Extension umsetzen. Mir schwebt da vor die vorgegebene Eingabemöglichkeit von Eigenen Layoutbereichen und deren Position zu entfernen und stattdessen per MultiColumnWizard eine dynamische Eingabe zu machen, wo man beliebig neue Layoutbereiche erzeugen und pro Layoutbereich auch festlegen kann, wo der sein soll - mit den bestehenden, vorgegebenen Positonen.

Das ist zwar immer noch nicht zu 100% flexibel, würde aber ohne viel Aufwand schon die Anpassung einfacher Fälle (wie zB zwei eigene Layoutbereiche an verschiedenen Stellen) ermöglichen.

[webstar]

Man könnte sowas durchaus in einer eigenen Extension umsetzen. Mir schwebt da vor die vorgegebene Eingabemöglichkeit von Eigenen Layoutbereichen und deren Position zu entfernen und stattdessen per MultiColumnWizard eine dynamische Eingabe zu machen, wo man beliebig neue Layoutbereiche erzeugen und pro Layoutbereich auch festlegen kann, wo der sein soll - mit den bestehenden, vorgegebenen Positonen.

Das ist zwar immer noch nicht zu 100% flexibel, würde aber ohne viel Aufwand schon die Anpassung einfacher Fälle (wie zB zwei eigene Layoutbereiche an verschiedenen Stellen) ermöglichen.

Etwa wie das hier oder noch anders/weiter? https://github.com/netzmacht/contao-flexible-sections

[Spooky]

Ah lol, ganz darauf vergessen

[soweit_ok]

Hallo,
Man kann die Position für custom Bereiche in den Layouteinstellungen aber nur genau einmal für alle Bereiche bestimmen, sie also nicht differenzieren. Das eingangs genannte Szenario von mir (1x "vor dem umschließenden Element" und 1x "in der Hauptspalte") ist nicht möglich ohne "hacks" in der fe_page (sehr gut von Spooky beschrieben). Solche Änderungen am fe_page sollte man meiner Meinung nach, wenn möglich, vermeiden.

Stimmt, jeweils nur einmal. Allerdings beliebig viele und wozu ich mehrere gleichnamige brauchen sollte, kann ich momentan nicht erkennen. Mehr als einmal macht ja nur für Elemente Sinn, die keine Id benötigen, denn man kann auf einer Seite mit CSS und JS bloß ein bzw. nur das erste Element einer Id ansprechen. Und Layoutbereiche sollten m. E. eindeutig sein, also eine Id haben und Klassen halt je nach Bedarf. Freie Positionierung hingegen, na klar. Mir reicht dafür halt die Möglichkeit im Template - reine Geschmacksache. Auch weil kaum eine Klick-Klack-Lösung so flexibel sein kann wie Code.
Deine Meinung, Änderungen an fe_page möglichst zu vermeiden, teile ich mithin nicht. Templates sind doch dafür da, sie updatefähig anpassen und erweitern zu können.

Außerdem, wenn Contao schon eine Konfiguration für die Seitenlayouts mit custom Bereichen liefert, ist es ja nur logisch, dass das dort auch entsprechend konfigurierbar ist. Der request bei github zeigt ja, dass ich das nicht alleine so sehe.

Seh ich genauso. Mir persönlich wären zwar eher andere Sachen wesentlich wichtiger, doch weil grundsätzlich eine gute Idee, finde ich ebenfalls einen Feature-Request gut und Diskussion der machbaren Optionen.

[tpk]

Hi,
krieg ich denn das hier

https://github.com/netzmacht/contao-flexible-sections

in ein 3.5er rein, und wenn ja, wie?

[lucina]

Entweder via Composer, oder aber den Modulteil unter https://github.com/netzmacht/contao-.../master/module in den ordner /system/modules/flexible-sections/ packen. Sollte alles sein.

[tpk]

Das mit dem Modul-Ordner hatte ich eigentlich probiert, aber ich teste es nochmal.

Gibt es irgendwo eine Anleitung zum Composer für 3.5? Mein letzter Stand war, dass der noch buggy ist, oder kann man den mittlerweile entspannt produktiv einsetzen?

[lucina]

Ich setze den seit bald zwei Jahren entspannt ein - es hängt aber von Deinem Hosting bzw. Server ab. Auf Standardhostings bei df.eu läuft das komplett stressfrei.

Das ist ja nicht buggy, es braucht halt in komplexen Installationen viel RAM ... ;-)

[Spooky]

Das mit dem Modul-Ordner hatte ich eigentlich probiert, aber ich teste es nochmal.

Wenn du die Extension manuell installierst, musst du auch die Abhängigkeiten (und deren etwaige Abhängigkeiten) manuell installieren.

[tpk]

Wenn du die Extension manuell installierst, musst du auch die Abhängigkeiten (und deren etwaige Abhängigkeiten) manuell installieren.

Merke ich gerade. Mindestens meta-palettes-master. Aber jetzt ist gerade der Server down ...

[tpk]

Das ist ja nicht buggy, es braucht halt in komplexen Installationen viel RAM ... ;-)

Was meinst Du damit?

[Spooky]

Die

composer update

Operation braucht je nach Situation sehr viel RAM. Kann sogar tlw. 2 GiB sprengen, wenn sehr viele, sehr komplexe Abghängigkeiten aufgelöst werden müssen.

[tpk]

Das bedeutet dann was konkret? Dass ein Shared-Host das schlicht nicht packt? Kann ich das vorher rauskriegen, oder nur durch ausprobieren?

[tab]

Im Zweifel durch ausprobieren, es hängt halt auch von den konkreten Erweiterungen ab. So richtig explodiert der RAM-Bedarf erst, wenn man entweder Contao 4.x verwendet, weil da wohl Symfony noch als Abhängigkeit drin ist. Oder eben, wenn man viele Erweiterungen hat mit vielen Abhängigkeiten und vor allem auch mit vielen in Frage kommenden Versionen. So habe ich es jedenfalls verstanden. Wenn du dich z.B. auf "stabile" Versionen beschränkst, wirst du viel weniger RAM brauchen als wenn du Entwickler-Versionen zulässt. Auch die Zwischenschritte bringen (Alpha, Beta, RC) bringen meist schon einiges. Entwicklerversionen gibt es halt die meisten.