Aufwändige, individuelle Startseite / Landingpage

ansonsten kannst du dich auch mit Boxen austoben.
Da gibt es keine Grenzen.

Allerdings, aber das ist vielleicht etwas persönliches, ich kann Seiten nicht leiden, auf denen ich ewig umherscrollen muss.

Hi,

Ich würde das so oder ähnlich lösen:

Header = Standard-Logo + Menüblock

Block Views, Kontaktformular als Block anlegen und einbinden

Blöcke für die versch. Divs mit individual Inhalt.
Wenn der Kunde keine Blöcke pflegen darf, dann kann man für diese Inhalte auch Seiten anlegen und eine View erstellen, die über den Body der Seite einen Block ausgibt mit der ID des Nodes als Argument.
Ich erstelle dann Blöcke mit folgender PHP-Ausgabe:

Dafür gibt es auch ein Modul https://drupal.org/project/nodeblock , mit dem habe ich allerdings noch nicht gearbeitet.

Für Akkordeons gibt es diverse Module, einfach mal schauen, welches am Besten passt.
Es gibt auch ein Modul für Views-Inhalte, die als Akkordeon gehandelt werden.

Wir verwenden für die Umsetzung das HTML5-Template Omega, das auch Werkzeuge für Responsive Design liefert.
Da kann man dann einfach die Blöcke in die verschiedenen Regionen schieben.
In Deinem Fall wäre das Header, Content mit sidebar_first, content und sidebar_second.
Wo drei Divs nebeneinander in den Contentbereich sollen, kann man das mit CSS lösen und den Containern eine prozentuale Breite geben.
Im kleinen Bildschirm (Smartphone) brechen die dann um.

Aber die Darstellung für kleine Bildschirme können ja vielleicht auch abweichen, weil man nicht alle Inhalte zeigen will.
Das ist dann noch mal ein anderes Thema, wie man das am Besten löst.

Wie meinst Du das "mit Boxen austoben"? Panels wäre für mich nur eine Notlösung, weil da responsive natürlich gar nichts mehr funktioniert und der code nicht ordentlich ist!

anlegen und in entsprechende Ranges des Themes legen.
Es können auch mehrere Boxen in einem Range liegen.

Nimm ein adaptive theme, damit das auch auf mobile devices funktioniert, und dennoch auf großen Bildschirmen gut aussieht.

Du wirst nicht umhin kommen, dich ein wenig mit der Drupal Technologie und dem Theming zu beschäftigen.

Hallo Ronald,

ich habe schon so viel zu Drupal Theming gelesen und auch schon so viele Videos gesehen (v2b, drupalize.me) und nie eine Antwort auf diese Frage gefunden, wenn ich sie ohne Panels lösen möchte. Wie also funktioniert das genau mit diesen Boxen. Ist das ein Modul und wie lege ich die an. Meinst Du mit Boxen "div container"?

Bei meiner Beschreibung gehe ich von Blöcken aus. Das wären dann die Boxen, die ja auch als DIV-Container zu stylen sind.
Im Omega Theme (und anderen auch), hast Du Zonen und innherhalb der Zonen Regionen und in der Blockverwaltung kannst Du die Blöcke bestimmten Regionen zuweisen.

Welche Regionen es gibt, kannst Du z.B. hier sehen:
http://radarearth.com/content/beginning-drupal-7-theming-omega

Das ganze ergibt im Code eine verschachtelte DIV-Container-Struktur die Du beliebig stylen kannst.
Und zwar recht einfach für Mobil, normal und breite Bildschirme.

ich meine natürlich Blöcke.
Ja das sind viereckige DIV-Container.

Du musst vom starren HTML-Denken weg, und in Objekten denken.

Natürlich ist eine starre HTML-Seite, die man von Hand gepinselt hat, optimaler strukturiert, als es eine dynamisch erzeugte Seite aus einem Template und verschiedenen Inhalten wahrscheinlich sein kann.

Wenn du nur eine Seite mit festen Inhalten machen willst, bist du mit Handarbeit besser dran.

Wenn du aber etwas dynamisches willst, ist ein CMS sicher der richtige Ansatz.

Und wenn du ein hochflexibles und unendlich erweiterbares Framework mit CMS-Grundlagen suchst, bist du bei Drupal richtig.

Nun, wenn es mehrere Seiten sind, dann ist ein CMS wo man CSS ect. zentral an einer Stelle pflegt, auch bei festen Inhalten die bessere Wahl.
Manchmal habe ich noch mit handgestrickten Kunden-Websites zu tun...das ist Tierquälerei. ;-)

Ich weiß :D

Die one page auftritte sind auch selten geworden.

Ich weiß :D

Die one page auftritte sind auch selten geworden.

Also bei meinem Projekt geht es um eine relativ große Website mit mehreren 100 Seiten. Die Startseite jedoch sollte bis auf einige kleine Views, statischen Content aufweisen, den der Kunde aber ebenfalls über Drupal editieren können soll. Ich will letztendlich nur wissen, wie ich ohne Panels und mit sinnvoller Nutzung des Blöckesystems eine Startseite aufbauenkann, die so umfangreich ist, wie ich es in der Grafik dargestellt habe.

Klar, ich kann für alles eine eigene region anlegen und dann im blocksystem blöcke dort zuweisen. Aber das ist extrem unübersichtlich! Eine jetzige Überlegung ist, das ganze mit Context zu machen... und im Notfall dann halt Panels. Aber nur, wenn es nicht anders geht...

Warum mußt Du für alles eigene Regionen anlegen?
Welches Theme verwendest Du?
Omega z.B. (bei anderen Themes kenne ich es auch) bietet doch schon so ein flexibles Regionen-System, daß man nur bei den Blöcken die entsprechende Region wünschen muß.

Du musst nicht für jeden Block einen Range anlegen.
Wenn die Blöcke unter oder nebeneinander in einem Range platz haben, ist es kein Problem, mehrere Blöcke in einem Range zu haben.

Du machst alles mit CSS.

Panels würden es nur nochmals komplexer werden lassen können.

Ja, das ist klar! Aber wie bekomme ich die Blöcke am komfortabelsten dort angezeigt. Wenn ich das über das Backend in der Blockliste mache, wird das doch sehr unübersichtlich und der Kunde kann nicht selbstständig editieren...

Deshalb war mein Vorschlag den Kunden Nodes zum jeweiligen Block pflegen zu lassen.
Da muß er sich halt einmal den Titel merken und wissen, was wo hin soll. Ohne dieses Wissen wird es nicht gehen.

Damit ein Node zu einem Block wird, kann man entweder eine BlockView erstellen, die nur Titel und Body (oder was der Node halt braucht) ausgibt und diese Blöcke baut man dann als Admin mit PHP in der Blockverwaltung ein.
Oder Du testest das Modul, das Nodes in Blöcke wandelt (siehe oben).
Bei Webform-Formularen kann man sowieso schon wünschen, daß sie als Block zur Verfügung stehen sollen.

Mach es doch so wie montviso schreibt und benutze in der Ansicht Contextual Links. Der Kunde kann so jeden Block (Node) bearbeiten und brauch nicht in die Blockverwaltung.

g. nick

Ich verstehe Dein Problem mit Panels überhaupt nicht... Du kannst doch für Panels eigene Templates anlegen - Panels ist nur eine andere Möglichkeit bei Drupal, Inhalte zu strukturieren und zu verwalten, den Output kann man doch wie eigentlich überall selber steuern (https://www.drupal.org/node/495654)

Bei so einer Startseite muss sowieso ein eigenes mobiles theme gebildet werden.
Normalerweise werden die sidebars unterhalb des contents dargestellt im mobile theming. Bei wenigen auch ganz verschluckt (meist hidden).
Aber selbst wenn nur und ausschließlich her der main content dargestellt würde, will ich DIe Umsetzung gerne mal mobil sehen.
Meiner Meinung nach wäre da das Service Modul mit REST API, eine Filterung der Inhalte und eine eigene mobile Darstellung von nöten.

Somit wäre es egal, ob panel oder nicht panel.

Ich denke auch, daß ein eigenes mobiles Theme in den Fällen besser ist, wo viele Inhalte in der mobilen Ansicht ausgeblendet werden.
Mit CSS Hidden wird die Performance ja dennoch belastet.

Welche Vorteile hätte die REST-Api gegenüber sonstigen Methoden, unterschiedliche Themes zu zeigen?

Aufwand ist es natürlich immer....und das wird gerne im Vorfeld unterschätzt.

Serverseitiges filtern, so dass der Datenstrom begrenzt wird. Trennen von Inhalt und Darstellung, so dass man als themer sich nur um die Darstellung kümmern muss, sobald die Inhaltsfrage geklärt ist.

Da gibts ganz gute Fachliteratur zu. Ich selbst habe es bisher nur in Testumgebungen gemacht, da die meisten meiner Projekte mit responsive design auskommen.

Der Aufwand ist natürlich sehr viel höher!

Wenn es sinnvolle Filter-Möglichkeiten gibt für Inhalte, die nur im PC od. nur im mobilen Bereich gezeigt werden sollen, dann macht der Aufwand evt. Sinn.
Aber dann kann man evt. auch einen Viewblock erzeugen, den man nur im Theme für PC / Mobil anzeigt.
Deswegen fällt mir kein Anwendungsfall für REST speziell für mobile Bedürfnisse ein.

Aber ich hatte so eine Anwendungsfall auch noch nicht, daß die Inhalte für Mobil stark abweichen.
Ich habe dazu mal in einem Buch über Responsive Webdesign gelesen:
Wenn ein Inhalt so unwichtig ist, daß man ihn in der mobilen Ansicht weglassen könnte, sollte man ernsthaft drüber nachdenken, ob man ihn nicht generell weg lassen kann.

Das finde ich einen sehr guten Tipp, an den ich mich immer häufiger halte bzw. meine Kunden dazu ermuntere, weil er viel Aufwand und den Besuchern der Webseite u.U. einige Zumutungen in Punkto Lesbarkeit erspart. ;-)

Angenommen ich habe 10 Blocks, die nur auf der pc Seite angezeigt werden sollen, und 10 Blocks, die nur auf der mobilen Seite angezeigt werden sollen.

Bsp: Select last 5 active Users für PC, select last 3 active Users für Mobil. Selber Zweck, aber wegen Design Berücksichtigung dass weniger Platz da ist.

Jetzt habe ich die Möglichkeit bei responsive Design diesen per views erbrachten Inhalt zu berücksichtigen.

Ich sage per CSS hide oder display:none den jeweils anderen Block.
Negativ: Nicht nur das der view vorher gepullt wird, er wird auch noch übertragen, er wird lediglich nicht angezeigt.

Ich sage per browscap serverseitig den brauchen wir nicht.
Negativ: Es fällt zwar wenigstens die Übertragung nicht statt, die Abfrage wird aber dennoch generiert. Wenn dann noch das Caching aus irgendwelchen Gründen (such Dir welche aus) nicht benutzt werden kann, schrubbst Du doppelt sooft die Festplatte wie Du musst!

Gehst Du via Rest, wird nur abgefragt was Du brauchst. Das wird dann am besten per json übertragen und dann dargestellt.

Für kleinere Seiten ist sowas völlig egal, hier geht es um performance Aspekte, die zum tragen kommen wenn man Portale entwickelt.

Aber dann sind ja noch zusätzlich das caching der render arrays etc. wichtig.

Danke mean,

ja das mit den zusätzlichen Abfragen ist ein Argument für größere Seiten...

Ein Modul für Conditions unter welchen Umständen eine View ausgeführt wird, oder nicht (unabhängig von der tatsächlichen Auslieferung des Blocks) gibts wohl noch nicht, oder?

aufgrund der bootstrap Reihenfolge kann ich mir solch ein Modul auch nicht vorstellen.

Ja, hast recht.