Wofür braucht man eigene Seitentypen?

In TYPO3 sind Websites (oder was immer man eigentlich mit Inhalt befüllen möchte) immer in Seiten struktiert. Das macht es auch ungeübten Redakteuren einfach, sich auf der Website zurecht zu finden - auch wenn sie größer wird. Diese Seiten werden im Backend im Seitenbaum dargestellt und bilden in der Regel die Struktur im Frontend 1:1 ab. Der Redakteur kann damit sehr einfach an der korrekten Stelle eine neue Seite einfügen oder Inhaltselemente auf einer Seite ändern. 

TYPO3 bringt von Haus aus einige Seitentypen mit. Mit Seiten vom Typ "Standard" werden die normalen Seiten einer Internetpräsenz aufgebaut. Der Seitentyp "externe URL" kann z.B. verwendet werden, um Links zu externen Websites in der Hauptnavigation darzustellen. Und "Systemordner" werden im Menu nicht dargestellt, eignen sich aber sehr gut dazu, um z.B. Footer-Menus zu strukturieren oder als Datenspeicher für Nachrichten oder andere Datensätze bereitzustellen. 

Wofür braucht man nun also noch mehr Seitentypen?

Ich bin ein Freund davon, möglichst wenig Abhängigkeiten in sein System zu bringen. Eine großartige Extension, die in vielen TYPO3-Systemen im Einsatz ist (und definitiv ihre Daseinsberechtigung im TYPO3-Universum hat) ist news (hier im TER) von Georg Ringer. Leider wird diese Extension oft dafür verwendet, wirklich alles in einen News-Datensatz zu quetschen, auch Dinge die da wirklich nicht hineingehören. Oftmals wird dies von unerfahrenen Integratoren gemacht, die auf diese Weise Übersichtsseiten zusammenstellen wollen. Bitte vergesst das sofort wieder: ihr tut damit Redakteuren keinen Gefallen. 

Ich habe unlängst für einen großen Kunden am Relaunch einer Website des Konzerns gearbeitet. Auf dieser Website gibt es verschiedene Inhalte, z.B. "Artikel" die wiederum an anderen Stellen angeteasert werden sollen. Eine Aufgabe für news? Vielleicht. Ganz sicher hätte man dies mit news lösen können; aber wir sind einen anderen Weg gegangen und die Redakteure waren begeistert. 

Übersicht im Backend

Die verschiedenen Beiträge hatten unterschiedliche Anforderungen. Bei einigen Typen waren GPS-Koordinaten notwendig, andere haben Daten für die Zusammenarbeit einer externen API angefragt und wiederum andere konnten z.B. farblich gekennzeichnet werden. Wir haben uns entschieden, all dies mit einzelnen Seitentypen zu realisieren. Für den Redakteur ist das sehr übersichtlich: er sieht direkt im Seitenbaum, um was für einen Typ Seite es sich handelt. Eine neue Seite kann wie gewohnt einfach in den Seitenbaum eingefügt werden. Und jeder Seitentyp fragt genau die Informationen ab, die benötigt werden - und nichts mehr: Alle anderen Felder sind ausgeblendet.

Datenaggregation leicht gemacht

Bei den gewünschten Inhaltselementen, die einen oder mehrere Teaser anzeigen, kann der Kunde nun frei entscheiden, welche Seitentypen berücksichtigt werden sollen und welche nicht. Da alle Seitentypen echte TYPO3-Seiten sind, kann der Redakteur diese ganz einfach im Hauptmenu verwenden, ganz ohne Verrenkungen und ohne einen Entwickler fragen zu müssen. 

Einfache Erweiterbarkeit

Jeder Entwickler kennt das: Kaum ist die Spezifikation aufgeschrieben, ändern sich die Anforderungen. In unserem konkreten Beispiel kam der Wunsch auf, auch Links auf externe Seiten in die Teaser einstreuen zu können. Diese Anforderung war sehr leicht umzusetzen, weil "Link zu externer URL" ein bereits von TYPO3 mitgelieferter Seitentyp ist, und wir daher nur die benötigten Felder (z.B. ein Vorschaubild für den Teaser) als Pflichtfeld für diesen Seitentyp definieren und in der Abfrage einen zusätzlichen Seitentyp konfigurieren mussten. 

Da alle Seitentypen in derselben TYPO3-Tabelle pages gespeichert werden, können wir darüber alle Datenbankmagie anwenden, die uns so einfällt. Wir wollen alle Artikel und externe URLs einer bestimmten Kategorie, nach Datum aufsteigend sortiert? Kein Hexenwerk - so sei es! 

Lasst uns einen Seitentypen bauen

Nachdem unsere Entscheidung also getroffen wurde und wir neue Seitentypen verwenden wollen, ist es nun an der Zeit, einen solchen zu entwickeln. Ich gehe davon aus, dass wir nach Best-Practice eine Extension haben, die unser Template beinhaltet und die wir für unsere Zwecke erweitern können. Ich nenne diese Extension sitepackage, aber natürlich ist jede Extension dafür geeignet.

Alle Informationen, die TYPO3 zu Seiten speichert, landen in der Datenbank in der Tabelle pages. Und genau diese Konfiguration passen wir in typo3conf/ext/sitepackage/Configuration/TCA/Overrides/pages.php an: 

<?php
defined('TYPO3_MODE') || die();

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTcaSelectItem(
    'pages',
    'doktype',
    [
        'LLL:EXT:sitepackage/Resources/Private/Language/locallang_be.xlf:pagetype.article',
        90,
        'actions-newspaper'
    ],
    '6',
    'after'
);


$fields = [
    'reading_time' => [
        'exclude' => true,
        'label' => 'LLL:EXT:sitepackage/Resources/Private/Language/locallang_be.xlf:pages.reading_time',
        'config' => [
            'type' => 'input',
            'size' => 30,
            'eval' => 'int,trim'
        ],
    ],
];

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns(
    'pages',
    $fields
);

\TYPO3\CMS\Core\Utility\ArrayUtility::mergeRecursiveWithOverrule(
    $GLOBALS['TCA']['pages'],
    [
        'ctrl' => [
            'typeicon_classes' => [
                90 => 'actions-newspaper',
            ],
        ],
        'types' => [
           
            // Article
            90 => [
                'showitem' => '
                    --div--;LLL:EXT:sitepackage/Resources/Private/Language/locallang_be.xlf:pages.tabs.article,
                        --palette--;;article,
                        --palette--;;headlines,
                        --palette--;;teaser_image,
                    --div--;LLL:EXT:frontend/Resources/Private/Language/locallang_tca.xlf:pages.tabs.access,
                        slug, --linebreak--,
                        starttime, endtime,--linebreak--,
                        --palette--;;visibility,
                        no_search,
                    --div--;LLL:EXT:core/Resources/Private/Language/Form/locallang_tabs.xlf:extended,
                    '
            ],

hier am Beispiel des doktypes 90 (von mir gewählt) für den neuen Seitentyp "Artikel". Dieser erhält ein eigenes Icon, ggf. werden ein oder mehrere neue Felder (hier: reading_time) definiert und anschließend abhängig vom Seitentyp zugeordnet. Damit sehen die Redakteure nun nur noch die Felder, die für diesen Seitentyp relevant sind. 

Wenn wir neue Felder einfügen, müssen wir diese natürlich auch in der Datenbank definieren. Das machen wir in der ext_tables.sql

CREATE TABLE pages (
    reading_time int DEFAULT '0' NOT NULL  
);

Bei der Installation der Extension wird die Tabelle entsprechend erweitert: während der Entwicklung können wir das z.B. mit

vendor/bin/typo3cms database:updateschema

forcieren. 

Damit die Redakteure den neuen Seitentyp wie alle anderen auch per Drag'n'Drop verwenden können, fehlt noch eine TSconfig-Einstellung:

options {
  pageTree {
    doktypesToShowInNewPageDragArea := addToList(90)
  }
}

Nun können die Redakteure Seiten des Typs Artikel an die gewünschte Stelle ziehen und die Seiteneigenschaften zeigen nur noch die Felder, die wir benötigen. Soweit so gut. :-) 

Darstellung im Frontend anpassen

Vielleicht möchten wir einzelne Seitentypen im Frontend anders darstellen. In unserem Anwendungsfall wurden neben der Lesedauer noch zahlreiche andere Felder eingefügt, so können Redakteure z.B. einzelne Seitentypen farblich kennzeichnen und vieles mehr. Mit den im Backend durch die Redakteure abgespeicherten Werte wollen wir natürlich im Frontend arbeiten. Hierfür können wir z.B. ein anderes Template für das Rendering ansteuern: 

page {
  10 = FLUIDTEMPLATE
  10 {
    layoutRootPaths {
      10 = EXT:sitepackage/Resources/Private/Layouts/
    }
    templateRootPaths {
      10 = EXT:sitepackage/Resources/Private/Templates/
    }
    partialRootPaths {
      10 = EXT:sitepackage/Resources/Private/Partials/
    }

    file.stdWrap.cObject = CASE
    file.stdWrap.cObject {
      key.data = levelfield:-1,doktype
      1 = TEXT
      1.value = EXT:sitepackage/Resources/Private/Templates/Default.html
      90 = TEXT
      90.value = EXT:sitepackage/Resources/Private/Templates/Article.html
    )
}

Falls nötig, können wir die Daten noch mit DataProcessors anreichern, z.B. wenn wir Informationen aus anderen Datenbanktabellen benötigen, die mit unserem Datensatz verknüpft sind: 

page.10 {
  dataProcessing {
    900 = TYPO3\CMS\Frontend\DataProcessing\DatabaseQueryProcessor
    900 {
      if {
        isEqual {
          field = doktype
          value = 90
        }
        isTrue {
          field = related_tags
        }
      }
      selectFields = pages.uid, pages.byline, pages.title
      table = pages
      join = tx_sitepackage_domain_model_tag_mm as mm ON mm.uid_local=pages.uid JOIN tx_sitepackage_domain_model_tag as tag ON mm.uid_foreign=tag.uid
      where {
        field = related_tags
        dataWrap = doktype=90 AND pages.deleted=0 AND pages.hidden=0 AND tag.uid IN (|)
      }
      groupBy = pages.uid
      orderBy = pages.crdate DESC
      max = 5
      pidInList = 1
      recursive = 99
      as = relatedArticles
      dataProcessing {
        10 = TYPO3\CMS\Frontend\DataProcessing\FilesProcessor
        10 {
          references.fieldName = media
          as = media
        }
      }
    }
  }
}

Hier im Beispiel holen wir uns verwandte Artikel aus der Datenbank und übergeben diese dem View, der diese dann weiterverwenden kann: 

<f:if condition="{relatedArticles}">
  <f:for each="{relatedArticles}" as="relatedArticle">
    <div class="col-12">
     <f:link.page pageUid="{relatedArticle.data.uid}">
       <picture class="teaser__image">
          <f:for each="{relatedArticle.media}" as="image">
            <f:image image="{image}" />
		  </f:for>
	   </picture>
       <p>{relatedArticle.data.title}</p>
	 </f:link.page>
    </div>
  </f:for>
</f:if>