Hallo Bastian.
Zunächst möchte ich auf die Aussage von Mark kontern, TYPO3 wäre dazu da,
Redakteuren Freiheiten zu geben anstatt sie zu beschränken. "Der Form nach"
hat Mark natürlich Recht. Würden wir Kasper fragen geht es sicherlich um
Freiheit. Aber meine persönliche Erfahrung zeigt, und damit bin ich nicht
alleine, dass man Redakteuren Grenzen setzen muss. Die Schwierigkeit bei
der Umsetzung von Webseiten mit TYPO3 liegt nicht im HTML, nicht in
TypoScript, nicht in Fluid und nicht in Plugins. Es geht vielmehr darum,
ein sinnvolles Zusammenspiel aller Möglichkeiten die TYPO3 bietet in einer
Form zu konfigurieren, sodass einerseits dem Redakteur die notwendigen
Freiheiten für seine Arbeit zur Verfügung stehen, andererseits aber alle
Regeln des Layouts eingehalten werden, mitsamt der dadurch definierten
"dont's".
Es geht also *doch* darum, dass der Redakteur eben nicht H1 bis H5 zur
Verfügung hat sondern nur "fett", "fett und unterstrichen" und "blinkend".
Was das in Markup bedeutet oder im CSS spielt keine Rolle, wenn der
Styleguide vorgibt dass auf allen First-Level-Seiten nur diese drei
Überschriftstypen zur Verfügung stehen dürfen dann dürfen da nur die zur
Verfügung stehen. Es ist weder die Aufgabe des Integrators noch die von
TYPO3 zu bestimmen, was der Designer sich gedacht hat.
Jetzt ein paar Gedanken zur Umsetzung.
Deine Fragen sind einerseits sehr konkret, sodass ich erstens eine konkrete
Antwort geben möchte und zweitens Du auch eine konkrete Antwort erwartest,
auch wenn Du das schon verneint hast.
Auf der anderen Seite kann man ohne eine wirklich konkrete Vorgabe leider
überhaupt nicht konkret antworten, ich muss jetzt also ein Bisschen raten.
Wenn das in die falsche Richtung geht oder wenn Du gerne mehr Details
wissen möchtest musst Du auch mehr Vorgaben verraten.
Dieter hat ja bereits erzählt, dass Du sowohl den "doktype" als auch das
Seitenlayout verwenden kannst, um die globale Gestaltung einer Seite zu
bestimmen. Inhaltlich wird es bei Dir dann sowas wie "Starteseiten",
"Landing Pages", "Kategorie-Seiten" oder sowas geben. Vielleicht gibt es
auch eine Seiten-Vorlage "Event" die eine Struktur zur ansonsten
redaktionell pflegbaren Gestaltung für Veranstaltungen definiert. Welche
Typen es geben soll hängt von Dir ab, bzw. von Deinen Layoutvorgaben. Und
ebenso hängt es von den Layoutvorgaben ab, ob das Wording dazu optisch
orientiert ist (Einspalter, Zweisplter mit automatischem Menü links,
Onepager, Teaser als vollbreiter Slider) oder inhaltlich (Event, Job,
Startsite, Mitarbeiterprofil oder Produkt).
Es ist letztendlich Geschmackssache, ob Du den "doktype" erweiterst oder
das Seitenlayout dafür nutzt. Möglich ist beides.
Ein technisches Argument für den Doktype und gegen das Seitenlayout ist,
dass über dem Pagetree jeder Doktype mit seinem Icon als
"Quick-Create-Icon" aufgeführt werden kann. Redakteure können so über das
Schnellmenü direkt eine Seite des Typs "Onepager" in den Seitenbaum ziehen,
oder eben eine Seite des Typs "Teaser als vollbreiter Slider".
Ein technisches Argument gegen den Doktype und für das Seitenlayout ist,
dass das der Doktype seine ursprüngliche Funktion als inhaltliche
Unterscheidung weiterhin und unabhängig vom Layout erfüllen kann. Wenn ich
einen Doktype "Event" anlege habe ich Events mit einem fixen Layout, alle
Events müssen dem folgen. Wenn ich ein Seitenlayout "Event" anlegen kann
ich sowohl den Doktype "Page" verwenden als auch den Doktype "Shortcut"
wenn ich Events pfegen möchte deren Inhalt gar nicht auf meiner Seite
liegt.
Es ist eben einerseits Geschmckssache und hängt andererseits von den
Anforderungen ab.
Du hast von Seiten gesprochen, die Teile ihres Inhalts von Unterseiten
beziehen. Das ist problemlos möglich. Und schon gibt es Spielraum.
Soll dieser Seitetyp *immer* seinen gesamten Inhalt von
Unterseiten beziehen? Dann braucht dieser Seitentyp überhaupt keine
Möglichkeit der Inhaltspflege im TYPO3-Backend.
Oder soll auf diesem Seitentyp möglicherweise ein redaktioneller
Einleitungstext vor dem automatischen Teil und ein weiterer redaktioneller
Schlusstext nach dem automatischen Teil erlaubt sein?
Dann kannst Du entweder ein Backend-Layout mit den zwei Zeilen "Content
Before" und "Content After" anlegen und in der Mitte den Automatismus
rendern.
Oder Du kannst eine einzige Zeile und eine einzige Spalte anlegen (es
handelt sich dabei also optisch erst mal um eine Standardseite) und dafür
ein Plugin/FCE/Grid-Element/Content-Element bauen, das vom Redakteur frei
positioniert werden kann und das im Frontend-Rendering selbständig
Textfragmente von Unterseiten bezieht.
Ich würde die zweite Version bevorzugen. Dadurch bleibt es dem Redakteur
überlassen, ob er als Seiten-Layout jetzt den Einspalter, den Zweispalter
mit automatischem Menü links oder den Onepager verwendet, auf all diesen
drei Seitentypen kann er an einer beliebigen Stelle das Element "Render
description content of all headlines of first level children pages of this
page" platzieren.
Man kann mit Backend-Layouts auf Seiten im Backend auch Inhalt platzieren
der auf dieser Seite überhaupt nicht im Frontend verwendet wird.
Ich kann zum Beispiel eine Seitenlayout "Blog Page" anlegen das im Backend
eine Zeile "Teaser" und eine Zeile "Content" hat. Innerhalb von "Teaser"
erlaube ich Headlines, Texte und Texte mit Bildern. Innerhalb von Content
erlaube ich alles. Wenn sich die Seite im Frontend rendert beachte ich nur
die Zeile "Content" und ignoriere die Zeile "Teaser". Diese Seite ist also
für den Redakteur ohne Einschränkung frei gestaltbar und im Frontend nicht
zwangsweise als Blogbeitrag zu erkennen. Und dazu baue ich ein Plugin
"Teaser for Blog Page" dem ich als vom Redakteur wählbares Argument via
Dropdown (bzw. Popup-Wizard oder Autosuggester, je nach Geschmack) eine
bestimmte Seite mitgebe. Dieses Plugin soll im Frontend den
Seiten-Datensatz laden und alle Inhaltselemente aus der Teaser-Zeile
rendern.
Dieses Vorgehen hat dann unmittelbar den Vorteil, dass auf diesen gerade
von mir beschriebenen Blogseiten eben alle Plugins erlaubt und einsetzbar
sind die der Redakteur zur Verfügung hab. Du musst Dich eben nicht
entscheiden, auf welchen Seitentypen jetzt Galerien erlaubt sind und wo
genau die hin gehören. Natürlich könntest Du diverse Bilder im Seitentyp
"Galerie" direkt in den Seiteneigenschaften pflegen und eine fixe Position
vorgeben wo im Frontend Thumbnails hingehören. Wenn Du aber stattdessen ein
Galerie-Plugin baust das der Redakteur frei platzieren kann und in dem der
Redakteur die anzuzeigenden Bilder wählt, dann kann der Redakteur nicht nur
die Position der Galerie auf der Galerieseite wählen (vor, nach oder
zwichen Text oder innerhalb einer Spalte, evtl auch verschachtelt zwischen
Textblöcken in einer Spalte eines mehrspaltigen Inhaltselements) sondern
das exakt gleiche Element auch auf diversen anderen Seiten einsetzen wenn
es da sinnvoll ist.
Es gehört deshalb zu den wichtigen Aufgaben bei der Erstellung von Seiten
mit TYPO3, anhand von Layoutvorgaben und Anforderungsdokumenten zu
erarbeiten, welche Features der Seite generalisiert werden müssen um sie
mehrfach zu verwenden und welche spezifisch nur an bestimmten Stellen
verwendet werden dürfen.
Die Umsetzung ist natürlich nochmal eine Nummer für sich. Nicht nur die
Anzahl der Features treiben den Aufwand in die Höhe sondern auf der
Anspruch an eine sinnvolle Benutzerführung. Ein Seitenlayout mit ein paar
Inhaltsbereichen ist schnell gebaut. Wenn dann unterschiedliche Bereiche
nur bestimmte Inhaltstypen tragen dürfen muss man schon mehr Dokumentation
lesen. Und wenn dann Container-Inhaltstypen dazu kommen und z.B. in der
linken Spalte des Zweispalter auf einer Startseite andere Inhaltselemente
erlaubt sein sollen als in der linken Spalte des Zweispalters auf einer
Seite des Typs "Seite mit automatischen 3-Level-Menü links" (vielleicht aus
Platzgründen) sollte sich der Integrator schon etwas auskennen.
Von Redakteuren jedenfalls darf niemand erwarten dass sie sich an solche
inhaltlich komplexen Layoutvorgaben halten. Ich würde mir zwar wünschen
diesen Anspruch an Redakteure haben zu dürfen. Die Erfahrung zeigt aber,
dass früher oder später Redakteure die Kombinatorik auf Basis ihrer
Berechtigungen vollständig erschöpfen und damit weit über das hinaus gehen,
was das Layout als sinnvoll definiert.
Beste Grüße,
Stephan.
Am 8. Februar 2017 um 22:17 schrieb Bastian Fenske <
Post by Bastian FenskeQuote: TYPO3 - Dr Dieter Porth wrote on Wed, 08 February 2017 18:50
----------------------------------------------------
Post by Dr. Dieter PorthHallo Mark,
Post by Bastian FenskeAuf der Homepage sollen die Taesertexte von verschiedenen
Unterseiten angezeigt werden - je nach Seitentyp unterschiedlich und auch
nicht von allen Unterseiten. Meine spontane Herangehensweise wäre jetzt
halt gewesen (ohne die Möglichkeiten von Typo3 zu kennen), auf der
jeweiligen Unterseite zu sagen: Ja, zeig von mir auch einen Teasertext
(oder auch einen gesondert einzugebenden Text) auf der Homepage an - bzw.
das eben durch den Seitentypen festzuschreiben. Aber ich kann die
entsprechenden Inhalte natürlich auch auf der Homepage selbst einbinden,
falls Du das meinst und Du denkst, dass das in Typo3 der geschicktere Weg
ist.
Du zäumst das Pferd von hinten auf, weil sich deine Website nach TYPO3
richten soll. Das ist der gedanklich falsche Weg. Der richtige Weg fängt
bei den Anforderungen an, also ich möchte dies so und so haben. Dann
überlegt man,
1. ist der Wunsch aus Sicht des Redakteurs bzw. aus Sicht des zukünftigen
Surfer sinnvoll? (Man kann dies schön an einer Pinnwand ausprobieren. Wo
soll der Redakteur welche Informationen pflegen. Wo wird der unbedarfte
2. Wie setzt man den gewünschten Workflow am geschicktesten mit TYPO3 um.
Bislang habe ich noch keinen Workflow kennengelernt, der sich mit TYPO3
sinnvoll abbilden lässt.
Das Konzept ist von einem Kommunikationsdesigner ausgearbeitet und vom
Kunden abgenommen. Und ich finde es (es geht um zwei Websites) bei beiden
Websites stimmig. Mein Job ist, das so umzusetzen, dass es für die
Autoren/Redakteure möglichst einfach bedienbar ist und hilfreich wäre jetzt
halt, dass man das Konzept so einkonfigurieren könnte, damit ein Autor
keine zusätzliche Information braucht, um das erarbeitete Konzept nicht zu
zerschießen - schlechtestenfalls sogar technisch zerschießen. Das geht aber
nach Euren Auskünften ja nunmal in Typo3 nicht oder nur mit sehr viel
Aufwand, daher such ich jetzt halt nach Kompromissen - Typo3 ist
vorgegeben, aber ich hab nochmal in den Raum geschmissen, das nochmal zu
überdenken. Mal sehen.
Ich hab vor etwa 10 Jahren für genau diese Fälle ein eigenes CMS
entwickelt. Das hat diese Aufgabe prima erfüllt und war superleicht zu
bedienen (wenn das Konzept konfiguriert ist, fliegen im Backend einfach
ganz viele Optionen raus). Ist halt eine andere Herangehensweise: Das
Konzept wird von den Entwicklern im Code konfiguriert und die Redakteure
etc. können nix außer Inhalte erstellen/bearbeiten, Seiten rumschieben im
Rahmen den die Seitentypen und Berechtigungen zulassen und Benutzerrollen,
Rechte und sowas. Will man das Konzept ändern/erweitern, muss man eine
Entwicklerin bezahlen und warten, bis sie fertig ist, dafür ist das Backend
super-simpel - ich hab nie eine Schulung machen müssen (allerdings auch nur
ein, zwei Dutzend Websites damit umgesetzt). Aber, natürlich kann das
System nicht mit etablierten Systemen wie Typo3 mithalten. Ich hatte gerade
erstmal ein paar Jahre Erfahrung in Programmierung und Architektur,
folglich steckt es voller Altlasten (ich hatte z.B. MVC (bzw. HMVC) noch
nicht wirklich gut verstanden und die Controller stecken voller Model-Code
- die üblichen Anfänger-Fehler halt). Es gibt keine Community, keine
Plugins (außer die, die ich selbst geschrieben habe), für den Kunden keine
Sicherheit, dass das Ding weiter entwickelt wird und eben volle
Abhängigkeit von mir. So hab ich hab die aktive Weiterentwicklung schon vor
Jahren aufgegeben.
Alles, was ich damit ausdrücken will ist: Wie man sowas umsetzt, dass es
für den Redakteur/Autor optimal einfach zu bedienen ist (wie der Besucher
der Website das Ding bedient, steht eben eh fest und ist von mir auch
revidiert worden), weiß ich ganz genau :) (natürlich gibt es immer viele
Wege und auch sicher noch einfachere Lösungen). Nur, mit Typo3 scheint das
so ja nunmal nicht zu gehen. Daher ist jetzt mein Rangehen zu schauen, wie
man das in Typo3 halbwegs vertretbar umsetzen kann. Hilft ja nix, wenn ich
jetzt auf meinem Standard bleibe und dann Monate dran sitze, das ganze in
Typo3 reinzukriegen und dabei dann die ganzen Vorzüge von Typo3 verliere,
weil keine Extensions mehr gehen, ich das Ding nicht upgraden kann etc.
Oder eben noch länger dran zu sitzen, mit dem Anspruch nur die Peripherie
anzufassen.
Ich hab jetzt einen groben Überblick. Ich werd, wenn es soweit ist, Typo3
installieren, mir das Backend mal anschauen (mit überkreuzten Findern, dass
sich da hoffentlich ganz viel getan hat in den letzten Jahren) und dann
nach Wegen suchen, es den Autoren möglichst leicht zu machen und dann
anfragen, ob die jeweiligen Schritte gehen und wie ich rangehen müsste -
falls ich die Infos nicht selber finde.
Vielen Dank jedenfalls für Eure Hilfe. Das waren wirklich gute Einblicke
und Tipps für mich!
Und nochmal explizit: Ich will mich hier nicht hinstellen als: "Ich hab
vor 10 Jahren ein CMS programmiert, das viel besser war; Typo3 ist Scheiße,
aber ich muss halt". War halt ein anderer Ansatz und in Typo3 werden andere
Sachen superleicht gehen, erwarte ich, für die ich in meinem CMS viel Code
hätte schreiben müssen oder die vielleicht dort vom Konzept her nicht
gegangen wären. Ich wollte nur sagen, dass ich genau weiß, wie ein leicht
zu bedienendes Backend (bzw. vieles wurde auch im Frontend bearbeitet) geht
und eben schon von dieser Seite aus ran gehe.
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german