Linkerzeugung im SimpleMarker erweitern

[digedag]

Der SimpleMarker sollte vor der Linkerzeugung den Data-Record des aktuellen Items in das data-Attribut des cObject schreiben. Damit kann die Link-Erzeugung Bezug auf diesen Datensatz nehmen. Man kann bspw. die Zielseite ändern oder das Alt- bzw. Title-Tag mit Informationen aus dem Datensatz befüllen.
Nachteil: Man hat keinen Zugriff mehr auf das Content-Element. Da ist in aller Regel das Plugin in tt_content.

[digedag]

Ein alternative Weg wäre die Nutzung des data-Wraps im cObject. Mit einem DataWrap kann man auf Attribute eines Datensatz einer anderen Tabelle zugreifen.

.typolink.ATagParams = title="{field:uid}"
.typolink.ATagParams.insertData = 1

Damit holt der Wrap die uid aus dem aktuellen Array in cObj.data. Statt field kann man auch Schlüssel wie page, tsfe, getenv usw. verwenden. Ausgewertet wird das ganze in ContentObjectRenderer::getData()
Und diese Methode hat auch einen Hook, mit dem man eigene Schlüsselwörter nutzen kann:

        if (is_array($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getData'])) {
            foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getData'] as $classData) {
                $hookObject = GeneralUtility::getUserObj($classData);
                if (!$hookObject instanceof \TYPO3\CMS\Frontend\ContentObject\ContentObjectGetDataHookInterface) {
                    throw new \UnexpectedValueException('$hookObject must implement interface TYPO3\\CMS\\Frontend\\ContentObject\\ContentObjectGetDataHookInterface', 1195044480);
                }
                $retVal = $hookObject->getDataExtension($string, $fieldArray, $secVal, $retVal, $this);
            }
        }

Über rn_base könnten wir einen Container bereitstellen in den die Markerklassen relevante Objekt-Instanzen für den DataWrap zur Verfügung stellen können. Dann müssen wir nur noch diesen Hook implementieren und können auf die Daten zugreifen!

[oliverklee]

Falls dabei Sachen generiert werden, die auf der Seite ausgegeben werden sollen/können, ist es wichtig, dass die Daten immer per htmlspecialchars enkodiert werden, damit man kein persistentes XSS hat.

[digedag]

Es geht hier um die Bereitstellung von Daten aus den Entities, die das Plugin für die Ausgabe verarbeitet. Diese stammen aus der Datenbank und wurden in der Regel von BE-Nutzern angelegt. Wenn wir da ein RTE-Feld per htmlspecialchars bearbeiten, wäre das eher kontraproduktiv. 😉
Daten, die das Plugin in dem Aufruf aus dem Frontend vom User einsammelt, sind hier nicht gemeint.
Aber danke für den Hinweis!

[digedag]

Was mir aber natürlich gerade einfällt, speziell für die Linkerzeugung sollte man HTML-Tags natürlich entwerten. Sonst entsteht auch kein valides HTML mehr.
Da die Verwendung von getData() über diesen Weg aber allgemein mehr Möglichkeiten auch für andere Ausgaben ermöglicht (nicht nur Linkerzeugung, sondern auch bei stdWrap von normalen Markern), sollte es trotzdem von rn_base in dem Fall nicht eingeschränkt werden. Das sollte dann IMHO im typolink konfiguriert werden.

[rengaw83]

Die Idee finde ich sehr gut!
Das würde nicht nur für die Linkerzeugung sondern auch für komplexe Entityübergreifende Ausgaben im TypoScript (DCMARKER / COA) sehr hilfreich sein.
Beispielsweise die Ausgabe einer der Kategorie in abhängigkeit von Newsattributen übers TypoScript ohne Einsatz einer UserFunc oder von Hooks bzw. Xclasses.