Workflow mit Inhaltstypen bei statischen Seiten

Hmmm, irgendwie verstehe ich nicht, was Du hier beabsichtigst.
Wenn ich eine statische Seite habe, dann baue ich "etwas HTML-Code" in das Body-Feld, auch Tabellen, wenn's sein muss.
Wofür benötigst Du denn weitere Felder?

Hallo Leda,

ich möchte mir ein Feedback einholen, wie Ihr solche statischen Seiten zusammen baut. Du würdest also alles in HTML umsetzen und in ein Text-Feld "body" setzen. Das ist natürlich flexibel für jemanden der mit HTML umgehen kann und dieses war auch mein erster Ansatz. Würdest Du denn Nachteile in meiner Vorgehensweise sehen? Für jeden Inhalts-Typen ein eigenes Formularfeld...

Gehe ich zu kompliziert an die Sache heran?

Die zusätzlichen Feld-Typen erlauben:
1. Inhalte können auch ohne HTML Kenntnisse leicht geändert werden.
2. Mit verschiedenen Erweiterungen - Picture Modul - können z.B. eingefügte Bilder (mittels verschiedener Feld-Typen) durch das System manipuliert werden. Die Vorgaben für die Bilder definiert der Ersteller der Seite.

Mir ist klar, dass beide Ansätze zum gleichen Ziel führen. Die Arbeitsweisen für zukünftige Seiten die hinzugefügt werden sind jedoch unterschiedlich und ich bin nun in der Situation mir die günstigste Herangehensweise zu erarbeiten.

Macht meine Herangehensweise noch Sinn, wenn das Projekt grösser wird?

Also zunächst bedeutet jedes zusätzliche Feld in einem Inhaltsytyp irgendwie gearteten zusätzlichen Themingaufwand, weil das Feld will ja auch dargestellt werden.
Wenn Du sooo komplexe statische Seiten hast, dann solltest Du vielleicht wirklich für jede einzelne Seite einen eigenen Inhaltstyp und für jedes Fitzelchen Inhalt ein eigenes Feld machen. Dazu jeweils ein eigenes Seitentemplate und die Felder manuell designen (alternativ die Display Suite benutzen).

Ich glaube, und das ist meine persönliche Meinung, man kann sich bei statischen Seiten diesen Aufwand sparen. Obiges Verfahren brauche ich nur, wenn ich mehr als einen Node pro Inhaltstyp erwarte, z.B. News. Bei Bedarf wird ausgebaut, aber keine Felder auf Halde produziert.

Falls Du aber irgendwelche tabellarischen Daten auf den statischen Seiten einbauen möchtest, dann könntest Du tatsächlich genau diese Daten über einen separaten Inhaltstyp dynamisch und mit den genau passenden Feldern pflegen (lassen), und diese dann über eine View in Deinen statischen Node einbauen.

Nachtrag: Du kannst auch das Bodyfeld mit einem Editor belegen, dann kann auch der HTML-Unkundige dort etwas pflegen, wenns nur um das geht...

Hallo Leda,

Du hast 100% in schwarze getroffen. Stichwort: " Felder auf Halde". Genau das ist mein Dilemma. Mein Inhaltstyp "Seite" sieht aktuell so aus:

Angenommen ich brauche 10 Tabellen, dann müßte ich den Inhaltstypen "Seite" weiter ausbauen. Das ist natürlich quatsch.

Wenn ich deinen Vorschlag richtig deute, dann erstelle ich 2 Inhaltstypen...

1. Seite
2. Tabelle

Dann baue ich mir z.B. folgende Nodes:

- Meine Seite 1
- Meine Seite 2
- Meine Tabelle 1
- Meine Tabelle 2

Nun führe ich die benötigten "Bausteine" über einen View zusammen. Am Ende hätte ich dann auf einer Seite z.B.

- Meine Seite 1
- Meine Tabelle 1
- Meine Seite 2
- Meine Tabelle 2

Nun zur Umsetzung. Ich habe schon mit Views gearbeitet und verstehe auch die Funktionsweise. Kann ich mein Vorhaben denn mit Views derart umsetzen, dass ich angebe in welcher Hirachie die nodes zusammengeführt werden? Dann bräuchte ich für jeden "Node Block" einen eigenen View und diese werden dann verbunden. Richtig? Auf der Views Config Seite würde dann jeder View einen eigenen Tab belegen.

Das Prinzip, wie man die Daten ablegen kann, hast Du verstanden.
Aber damit bewegen wir uns überhaupt nicht mehr auf dem Niveau einer statischen! Seite...

Und zusammenfügen solltest Du das nicht über Views, sondern entweder manuell über ein Template oder über die Display Suite, Panels, Page-Manager, oder auch kontext-abhängige Blöcke.

Du solltest Dir dringend hierzu noch mehr Kenntnisse aneignen, bevor Du ein kompliziertes Datenmodell zusammenstellst, weil, um die Darstellung kommst Du dann im Detail nicht drumrum.

Das alles ist leider nicht ganz trivial, aber voll ausgefahren ungeheuer flexibel.

...ah...ich denke Panels ist eine nette Sache um eine Landing Page in beschriebener Weise zusammen zu basteln. Flexibel bis hinten gegen. Danke an dieser Stelle...ich baue das bei mir mal ein wenig um und schaue dann ob es passt.

@leda

Kurze Rückmeldung von meiner Seite. Ich habe jetzt doch alles als HTML in den body geschrieben und meine Tabellen responsive gestaltet. Deine Anmerkungen haben wirklich geholfen. So kompliziert muss ich eine einfache Page bzw. meine Basis für das Erstellen von Seiten nicht konstruieren. Das Ergebnis ist einfach zu verwalten, flexibel und Zukunftssicher. Einzig ein Header Image für die Page verwalte ich noch über ein eigenes Feld. Danke Dir!

Fein, das freut mich. Ich denke, man merkt irgendwann schnell, wenn man das Datenmodell ausbauen muss. Das mit dem separaten Bild mache ich übrigens auch so :-)