Zukunft des Stylings: Regions+Blocks oder Display Suite oder Panels ?

Ich habe mich das auch schon gefragt und einiges verglichen und ausprobiert. Neben dem genannten gibt es auch noch context, das von einigen Leuten auch dafür verwendet wird, das Blocksystem flexibler zu nutzen.

Mittlerweile nehme ich meist Panels auch für einfach strukturierte Websites, weil

• das Standard Blocksystem einfach unübersichtlich ist
• panels übersichtlich ist
• panels mit views panel panes am flexibelsten ist
• der anfängliche Konfigurationsmehraufwand sich bei späterem An-/Umbau und Funktionszuwachs unbedingt lohnt. Einige Male hatte ich mir gedacht: Hätte ich das gewusst, hätte ich gleich panelsverwendet.

Ich baue meist node Panel Varianten für die unterschiedlichen Inhaltstypen u.a. und lasse Redakteure nicht an die Panels Konfiguration.
Um redaktionsfreundliche Blocks in die Panels zu bringen, nutze ich bean und einen views pane, der die bean blocks dynamisch in der gewünschten region zeigt.

Im Core ist Panels nicht enthalten, es gibt aber eine Alpha Version von 02/2015 https://www.drupal.org/project/panels

Ich habe mal vor 3 Jahren Panels kurz genutzt und fand es auch sehr spannend, bin aber irgendwie davon weg, die Block Geschichte ist allerdings bei grossen Seiten wirklich unübersichtlich.

Überlege mich auch nochmal näher mit Panels und Page Manager zu beschäftigen, könnt ihr mir aus Erfahrung 2 Fragen vorab beantworten bevor ich mich da nochmal reinhänge?

1. Ist Panels performance technisch gesehen ein Overkill bzw. zieht es sehr viel Performance?

2. Kann man es problemlos mit responsive Sites verwenden (Beispiel Bootstrap Theme)?

Danke vorab, grüße Jenna

Am besten gar nicht. Ein Redakteur möchte sich einloggen, auf einen Link klicken und dann losschreiben bzw. seine Inhalte aus einem Textverarbeitungsprogramm reinkopieren. Ein Redakteur möchte sich nicht mit der Struktur einer Website auseinander setzen müssen, um Inhalte online zu bekommen. Erfahrungsgemäß sind viele Angehörige der schreibenden Zunft völlig überfordert und angenervt, wenn sie mit Dingen wie Display Suite, Panels, Panes oder auch nur Blöcken hantieren müssen. Diese Dinge sind eher etwas für Sitebuilder, aber nicht für Anwender. Guck dir mal das Paragraphs Modul an. Dies ist meiner Meinung der bessere Weg für Redakteure, Inhalte im Rahmen ihrer Möglichkeiten flexibel zu erstellen.

ich finde die normalen mittel wie views, fieldcollection etc. und css langen voll auf. man kann ja alle inhalte als blocks anzeigen und diese auch überall positionieren und das natürlich noch per css.
also damit ist alles machbar

So seh ich das auch. Gerade mit Eva, fieldcollections / fieldgroups und etwas CSS kann man auch dynamische Inhalte frei nach Gusto positionieren. Code- Monster wie Display- Suite, Panels etc. sind in meist gar nicht nötig und gehen nur auf die Performance.

Ich selber verwende bei komplexeren Layouts Display Suite mit eigenen Displays und Overrides. Damit kann man schon viel anstellen :-)

Ich finde dieses Modul auch ganz spannend, wurde mal hier bei einer ähnlichen Frage im Forum vorgeschlagen:
https://www.drupal.org/project/content_nodes

@glycid, genau diese Performance Frage hat mich bisher auch immer davon abgehalten Display Suite oder Panels zu nutzen, dann bleibe ich auch weiterhin bei meinen jetzigen Lösungen wenn du es auch als Codemonster beschreibst, genau das waren auch meine Bedenken sich zuviel Krams raufzuladen der auch anders lösbar ist.

Grüße Jenna

Wenn man über Drupal liest ist das erste was immer in Erscheinung tritt die Performence.

Entweder hat man nun in kein Geld für ordenliche Server oder Drupal ist wirklich lahm.

Ich finde es eigentlich eine tolle Eigenschafft die immer so beschrieben wird.

Also ich glaube schon ich bekomme doch eines Tages meine Zweifel.

Also ich muss schon sagen Drupal ist ja fast das erste CM/ CMF bei dem man nichts von deren Stärke anwenden sollte weil es sonst eben nicht mehr rennt.

Das würde ich nicht so pauschal sagen. Wenn ich keine Ahnung von CSS, HTML und vielleicht auch PHP habe und mir trotzdem eine Website bauen will, nehme ich natürlich Module wie Display Suite, Panels und so weiter. Sind ja auch fürs Sitebuilding gemacht. Views erspart mir manuelle Datenbankabfragen und das Rendern selbiger. Benutze ich auch, ist schön bequem. Aber bei größeren Datenmengen nur bedingt geeignet. Aber wenn ich eine Site für einen Kunden baue, muss ich diesen als Endanwender stets vor Augen haben und mich immer wieder fragen: "Kann der /die das auch bedienen?". Was Contrib- Module angeht, hat sich für mich die Taktik: So viel wie nötig, so wenig wie möglich, letztlich bewährt.

Das modulare Konzept von Drupal und die daraus resultierende Flexibilität sind im Grunde ein Segen. Wenn Module jedoch unbedacht eingesetzt werden, kann es zum Fluch auswachsen. Mal ein Beispiel: Ich habe gerade eine Anfrage, um eine größere Drupal Website umzustrukturieren. Die Seite wurde von einer rennomierten Werbeagentur erstellt, die jedes Jahr zig Preise für ihr creatives Schaffen abräumt. Beim Sitebuilding waren sie auch sehr creativ. Verschachtelte Inhaltstypen, Panels, Panes, Display Suite, Page Manager, Node Block u.s.w. Das ganze auch noch Multisite und mehrsprachig. Die haben wirklich alles reingeworfen, was Drupal so an contrib- Modulen zu bieten hat. Das Resultat:

Keiner der Inhaltsverantwortlichen kommt mit der Erstellung und Verwaltung des Contents klar
Riesen Probleme bei Updates
Schlechte Performance trotz leistungsfähigem Server

Das ganze hätte man mit Drupal "Bordmitteln", CSS und vielleicht zwei custom- Modulen wesentlicher schlanker, einfacher und übersichtlicher regeln können. Das dumme ist, dass solch "verbaute" Projekte erstmal negativ auf Drupal zurückfallen. Da musst du den Leuten erstmal klar machen, dass ihr Projekt "ein wenig unglücklich konzipiert wurde" und nicht das Framework schuld an der Misere ist.

Noch kurz zum Thema Performance:

Immer wenn viel Funktionalität und große Contentmengen gehändelt werden müssen, muss du als Entwickler die Performance, die Update- und Upgradefähigkeit und natürlich die Sicherheit im Auge haben. Das gilt für Drupal genauso wie für Ruby, Typo3, ..... und komplette Eigenentwicklungen.

Auch wenn jetzt D8 das Maß der Dinge ist: Panels in D7 kann Caching auf jedes einzelne Pane anwenden, was diese Seiten sogar deutlich performanter macht. Auch die Übergabe von Werten an Views, die aus dem Kontext gefischt werden können, ist mit händischer Programmierung deutlich aufwändiger. (glycid: ich weiß, dass du das damals nicht wusstest)
Für den Redakteur ist Paragraphs (tuts auch in D8 super) genial, weil der Sitebuilder hier viel vorgeben kann.
Panels/Page-Manager in D8 ist immer noch in den Kinderschuhen und macht überhaupt keinen Spaß, wenn die Panel-Seiten sehr dynamisch sein sollen.
Display-Suite oder nicht: bei bestimmten Projekt-Größen kann es von Vorteil sein, alle Ausgaben über eigene Entity-Templates zu machen und überhaupt keine Settings in den Nodeausgaben und deren Varianten zu machen. Vorteil: das Wissen ist nur im Code und erleichtert das Deployment, grad wenn mehrere Entwickler arbeiten. Diese Methode wird deshalb gern von größeren Agenturen genutzt.