Grundsätzlich kann eine Extension als gecachtes USER-Objekt oder als ungecachtes USER_INT-Objekt eingebunden werden. Prinzipiell kann das für jede Extensions sowohl im PHP-Code wie auch über Typoscript bestimmt werden.
Zunächst erhalten Sie folgenden Eintrag in der ext_localconf.php. Die “1” am Ende steht für aktivierten Cache:
t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_myExtension_pi1.php’,‘_pi1’,‘list_type’,1);
Zusätzlich muss innerhalb der Extension der cHash aktiviert werden, indem eine Klassenvariable definiert wird:
var $pi_checkCHash = true;
Die Ausgabe des cHash ist nötig, damit für jede Paramter-Kombination ein eigener Cache-Eintrag angelegt wird. Ohne cHash wird jeweils der erste Seitenaufruf für die gesamte Seite gechachet und die weiteren Parameter-Kombinationen ignoriert. Der cHash ist ein Hash-Wert, der aus den Parametern und dem Encryption key des Install-Tools errechnet wird. Er soll verhindern, dass über zufällig aufgerufene Parameter der Cache überflutet wird – was einer DOS-Attacke gleich käme. Nur gültige Parameter erzeugen einen Cache-Eintrag.
Natürlich müssen die Links entsprechend erstellt werden, sinnvollerweise über die TypoLink-Funktionen von TYPO3:
tslib_pibase.pi_linkTP (
$str,
$urlParameters = array(),
$cache = 1,
$altPageId = 0
);
Weitere Beispiel im Artikel Links in Extensions.
Extensions, die z. B. mit Formularen umgehen oder aktuelle Daten liefern sollen, dürfen nicht gecached werden. Allerdings sollte natürlich trotzdem der Rest der Seite gecachet werden, nur eben rein der Code der Extension nicht. Das kann so erreicht werden:
t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_myExtension_pi1.php’,‘_pi1’,‘list_type’,0);
Damit wird die Extension als USER_INT – also als nicht cachende Extension – eingebunden.
Es ist ohne weiteres möglich, Plugins über Typoscript umzustellen von USER auf USER_INT. Mit
plugin.tx_myExt_pi1 = USER_INT
[globalVar = TSFE:id = 100]
plugin.tx_tx_myExt_pi1 = USER_INT
[global]
Tipp: Diese Einstellung in der main-Function:
function main($content, $conf) {
$this->pi_USER_INT_obj = 1;
}
Wird oft zusätzlich empfohlen, um ein USER_INT-Plugin anzulegen. Meines Wissens schreibt sie auch der Extensions-Manager entsprechend rein. Ich würde das nicht empfehlen, da dadurch der TypoScript-Umschalter natürlich deaktiviert wird und die oben erwähnten Methoden nicht mehr funktionieren.
Das ist nicht so einfach und setzt einen entsprechenden PHP-Code im Plugin selbst voraus. Ausserdem ist es erst ab TYPO3 4.3 möglich. Dieser Code in der main-Function des (USER-)Plugins:
switch ($this->conf['code']) {
case 'FORM':
$this->cObj->convertToUserIntObject();
$content .= 'Bin jetzt ein USER_INT-Objekt und cache nicht.';
break;
default:
$content .= 'Bin ein USER-Objekt und cache. ';
break;
}
schaltet automatisch bei der Auswahl von FORM in den Flexforms um auf ein USER_INT. Hier ist noch eine andere Variante, welche die USER/USER_INT-Eigenschaften abhängig macht von der TypoScript-Variablen “allowCaching”:
if ($this->cObj->getUserObjectType() == tslib_cObj::OBJECTTYPE_USER) {
$content .= 'Ich bin ein USER Objekt.<br>';
if (!$this->conf['allowCaching']) {
$this->cObj->convertToUserIntObject(); return '';
}
} else {
$content .= 'Nun bin ich ein USER_INT Objekt<br>';
}
Quelle: USER to USER_INT conversion. Aber Achtung: dort stimmt die Syntax nicht! Meine hier ist richtig.
Machmal besteht die Notwendigkeit, innerhalb einer gecachten Extension eine einzelne Ausgabe ungecached machen zu lassen – z. B. die Ausgabe einer Zeit. Das kann man über ein kleines zusätzliches Plugin lösen, das im eigentlichen Plugin aufgerufen wird:
$content .= 'Normale, gechachte Ausgabe. <br>';
$cObj = t3lib_div::makeInstance('tslib_cObj');
$cObj->start(array());
$conf2 = $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_myExt_pi2.'];
$conf2['includeLibs'] = 'EXT:myExt/pi2/class.tx_test_pi2.php';
// ungecachte Ausgabe aus einem anderen Plugin:
$content .= $cObj->cObjGetSingle('USER_INT',$conf2);
$content .= '<br> und wieder die gecachte Ausgabe ... ';
Quelle: das Buch “Extension entwickeln” von Dimitry Dupolev, S. 129.
Eine Lösung mit einem modifizierten PHP-Skript ist im Beitrag Typoscript Konfiguration zu finden.
Offensichtlich gibt es einen TypoScript-Parameter, der das doppelte Setzen des L-Parameters verhindert.
config.linkVars = L
config.uniqueLinkVars = 1
Noch nicht getestet, aber sollte wohl funktionieren.
Laborenz et. al: Typo3 4.0. Kapitel Mehrsprachige Websites, ab S. 435.
Artikel von Steffen Kamper, Sprachumschaltung mit TypoScript
Sprach-Menü vom Typo3 Blogger
Tip-A-Friend link generated using Typoscript
Es ist wesentlich sinnvoller und auch einfacher, ein Sprachmenü aufzubauen. Siehe Artikel Sprachmenue.
]]>
temp.nav_top_intern {
20 = HMENU
20 {
special = language
special.value = 1,0
1 = TMENU
1 {
NO = 1
NO.linkWrap = | |
NO.stdWrap.cObject = TEXT
NO.stdWrap.cObject {
value = Englisch || German
}
USERDEF1 < .NO
USERDEF1 {
doNotLinkIt = 1
stdWrap.typolink.parameter = 399
stdWrap.typolink.additionalParams = &L=1
}
}
}
}
Dieses Menü hat den Vorteil, dass bei einer fehlenden Übersetzung einer Seite auf eine selbst zu definierende Startseite gesprungen werden kann.
Man kann es auch so aufbauen, dass ein Wechsel zwischen den Textausgabe erfolgt, also in den deutschen Seiten wird nur Englisch als Link ausgegeben und umgekehrt.
temp.nav_top_intern {
20 = HMENU
20 {
special = language
special.value = 1
1 = TMENU
1 {
NO = 1
NO.linkWrap = | |
NO.stdWrap.cObject = TEXT
NO.stdWrap.cObject {
value = English
}
USERDEF1 < .NO
USERDEF1 {
doNotLinkIt = 1
stdWrap.typolink.parameter = 399
stdWrap.typolink.additionalParams = &L=0
}
}
}
}
[globalVar = GP:L = 1]
# Kopfmenü mit Sprachumschaltung.
temp.nav_top_intern {
20.special.value = 0
20.1.NO.stdWrap.cObject.value = Deutsch
20.1.USERDEF1.stdWrap.typolink.additionalParams = &L=0
}
[global]
'file' => array (
'exclude' => 0,
'label' => 'LLL:EXT:MyExtension/locallang_db.xml:tx_myExtension.file',
'config' => array (
'type' => 'group',
## hier umstellen von file auf file_refence: ######
'internal_type' => 'file_reference',
'allowed' => '',
'disallowed' => 'php,php3',
'max_size' => $GLOBALS['TYPO3_CONF_VARS']['BE']['maxFileSize'],
'uploadfolder' => 'uploads/myExtension',
'size' => 1,
'minitems' => 0,
'maxitems' => 1,
)
),
Dadurch wird nicht mehr der reine Dateiname in der Datenbank gespeichert sondern der komplette Pfad auf die Datei. Natürlich muss das bei der weiteren Verarbeitung der Datei auch entsprechend berücksichtigt werden.
Generell sollte die TYPO3-API für alle Datenbankzugriffe verwendet werden. Diese sorgt unter anderem für das nötige Quotieren der Eingaben.
Wichtig sind hier vor allem diese beiden Methoden:
$GLOBALS['TYPO3_DB']->fullQuoteStr( $str, $table )
$GLOBALS['TYPO3_DB']->fullQuoteArray( $arr, $table, $noQuote = FALSE );
Näheres im Abschnitt Datenbankabfragen.
Die Methoden der Klassse t3lib_div werden statisch aufgerufen.
// Entfernt gefährlichen Code, Rückgabewert der bereinigte String
t3lib_div::removeXSS($string)
// Gültige E-Mail: Rüpckgabewert true/false
t3lib_div::validEmail($email)
// Testet auf gültige URL, Rückgabewert tru/false
t3lib_div::isValidUrl($sanitizedUrl)
Alle GET- und POST-Variablen sollten über die entsprechenden Funktionen der TYPO3-API angesprochen werden:
// Übernahme der Parameter mit Namensindex der Extension:
$this->piVars['parameter'];
// Wenn das nicht möglich ist, dann so:
t3lib_div::_GP ( $var );
// oder getrennt nach GET / POST
t3lib_div::_GET ( $var );
t3lib_div::_POST ( $var );
// Kürzen eines UTF-8-Strings
mb_substr( $string, 0, 50 );
// Länge eines UTF-8-Strings prüfen
mb_strlen( $string );
// Integer erzwingen
intval( $this->piVars['wert'] );
// Alle Tags aus einem String entfernen:
strip_tags( $string );
// einige Tags erlauben (Achtung: die erlaubten Tags können Parameter enthalten!)
strip_tags( $this->piVars['wert'], '<em><i>' )
// Tags in Entities umwandeln:
htmlspecialchars( $this->piVars['wert'])
Diese Datenfilter werden in TYPO3 seit einigen Versionen ebenfalls eingesetzt. Einige kleine Anwendungsbeispiele:
// Test auf korrekte URL
$url = 'http://www.lisardo.de';
if ( @filter_var($url, FILTER_VALIDATE_URL) === FALSE) {
echo $url.' falsch';
} else {
echo $url.' korrekt';
}
// oder ein Test auf korrekte E-Mail:
if(!filter_var("someone@lisardo...de", FILTER_VALIDATE_EMAIL)) {
echo("E-mail falsch");
}
else {
echo("E-mail korrekt");
}
// Oder ein Test ob eine POST-Variable namens "mail" eine gültige E-Mail enthält:
if (!filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL)) {
echo "E-Mail ist falsch";
}
else {
echo "E-Mail korrekt";
}
Ein schöner Überblick über alle Filter mit Beispielcode ist bei w3schools, PHP Filter Functions zu finden. eine genaue Erläuterung im offiziellen PHP-Manual, Datenfilterung
In der Grundkonfiguration entfernt der RTE alle nicht erwünschten Tags. Um eigene Tags zu ermöglichen, muss der Konfiguration des RTE folgendes hinzugefügt werden:
RTE.default.proc.allowTags := addToList(sondertag)
RTE.default.proc.allowTagsOutside := addToList(sondertag)
RTE.default.proc.entryHTMLparser_db.allowTags < RTE.default.proc.allowTags
Anstatt der Schreibweise := addToList(sondertag) können natürlich auch alle Tags aufgeführt werden, z. B. so:
RTE.default.proc {
allowTags (
a,abbr,acronym,b,bdo,blockquote,br,cite,code,col,colgroup,del,dfn,div,em,
h1,h2,h3,h4,h5,h6,hr,i,img,li,ol,p,span,strike,strong,sub,sup,
table,thead,tbody,tfoot,td,tr,th,ul,sondertag,
)
}
Das ist natürlich umständlicher, aber man weiss genau, was man erlaubt hat und was nicht.
Damit der Tag im Frontend ausgegeben wird, muss zusätzlich im TypoScript des Templates noch folgendes hinzugefügt werden:
lib.parseFunc_RTE.allowTags := addToList(sondertag)
Beziehungsweise für alle Texteingabefelder, die nicht den RTE benutzen:
lib.parseFunc.allowTags := addToList(sondertag)
In der Regel wird man aber den eigenen Tag nicht im Frontend ausgeben wollen, sondern man möchte ihn auf eine bestimmte – individuelle – Art parsen. Das kann mit Hilfe eines eigenen PHP-Skripts erfolgen oder über eine TypoScript-Konfiguration.
Für ein eigenes PHP-Skript kann man eine eine Extension anlegen und das hier ins Setup des TypoScript-Templates schreiben:
# eigenes PHP-Script:
lib.parseFunc.tags.sondertag = < plugin.tx_eigenExtension_pi1
Man kann aber auch im Kickstarter eine Extension anlegen, die sich im das Parsen eines einzigen Tags kümmert. In der Auswahl der Frontendplugins gibt es am Ende der Liste die Option, einen Custom Tag zu verarbeiten. In diesem Fall muss nichts mehr ins Setup geschrieben werden, da die Einbindung das localconf der neuen Extension übernimmt.
Oder man geht komplett über TypoScript, zum Beispiel so:
# über TS
lib.parseFunc_RTE.tags.myTag = TEXT
lib.parseFunc_RTE.tags.myTag {
# mit current=1 enthält man den aktuellen Inhalt des Tags
current = 1
# eigenes wrap, z. B. für Boxen
wrap (
<div class="box">
<div class="top"></div>
<div class="center">|</div>
<div class="bottom"></div>
</div>
)
# Leerzeilen vor und nach dem Inhalt des Tags entfernen
stripNL = 1
}
Eigene HTML-Tags zu erlauben ist natürlich nur der erste Schritt – wir müssen es den Redakteuren noch ermöglichen, diese auch einzugeben. Normalerweise werden diese Tags nämlich bei der Eingabe bereits in Entities umgewandelt. Man könnte natürlich auf die HTML-Eingabe umschalten oder den RTE vorübergehen deaktivieren, aber das ist eigentlich nicht zumutbar.
Wir können es aber über eine eigene Bibliothek mit User-Elementen ermöglichen.
Zuerst muss das »user«-Werkzeug erlaubt werden. Dazu muss es entweder unter »showButtons« hinzugefügt oder bei »hideButtons« ausgelassen werden. Je nachdem, wie man prinzipiell den RTE konfiguriert hat. Ich gehe über hideButtons und lösche dort »user« aus der Liste:
RTE.default {
hideButtons (
lefttoright, righttoleft, formattext, bidioverride, big,
citation, definition, insertedtext, italic, keyboard,
monospaced, sample, small, span, strikethrough,
variable, bold, underline, fontstyle, fontsize,
blockquote, insertparagraphbefore, insertparagraphafter, inserthorizontalrule,
spellcheck, emoticon, inserttag, copy, cut, paste,
justifyfull, textcolor, bgcolor,
)
}
Danach sollte im RTE ein Werkzeug auftauchen mit dem Tooltipp »Insert custom element«. Bei Klick öffnet sich ein Dialog, mit dem die neuen Elemente eingefügt werden können. Damit die Elemente zur Vefügung stehen, müssen diese noch konfiguriert werden:
RTE.default {
userElements {
10 = Eigene Sondertags
10 {
1 = Sondertag
1.description = Der ausgewählte Text wird umschlossen von <sondertag></sondertag>
1.mode = wrap
1.content = <sondertag>|</sondertag>
}
}
}
Dabei bildet »10« eine Kategorie mit der Bezeichnung »Eigene Sondertags« und »1» ist das erste Element. Die folgenden Elemente dieser Kategorie beginnen mit »2«, »3« und so weiter. Wichtig ist die Angabe des Modus – damit wird erreicht, dass der markierte Text vom Content umgeben wird.
Mit dieser Technik können nicht nur Tags ermöglicht werden, sondern es können Bilder oder Textbausteine zur Verfügung gestellt werden oder auch weiterführende Formatierungen mit <div>-Containern. Es können sogar PHP-Skript darüber aufgerufen werden, die markierte Inhalte vor der Übergabe verarbeiten.
Bei uns tauchte gelegentlich das Problem auf, dass bei <div>-Containern, die auf diese Art in den RTE eingefügt wurden, bei der Ausgabe ins Frontend der äusserste Container in einen p-Tag umgewandelt wurde. Da in einen p-Tag kein <div> geschachtelt werden darf, hat das unangenehme Konsequenzen – unter Umständen auf das Rendering der gesamten Seite. Dieser Fehler ist ein Feature und kann abgeschaltet werden durch diesen Eintrag ins TypoScript Setup:
### das hier verursacht den Fehler:
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.remapTag.DIV = P
### so abschalten:
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.remapTag.DIV >
Dieser Eintrag soll eigentlich dafür sorgen, dass versehentlich eingefügte <div>-Tags durch Absätze ersetzt werden. Bei einigermaßen guter Konfiguration des RTE ist dieses Feature aber überflüssig und kann abgeschaltet werden.
Zuerst muss die Spracheinstellung (Modus) aus config im Setup ausgelesen werden, am besten in der main()-Funktion oder in einer speziellen init()-Funktion, die aus main() ausgerufen wird:
$this->sys_language_mode = $this->conf['sys_language_mode']?$this->conf['sys_language_mode'] : $GLOBALS['TSFE']->sys_language_mode;
#####
# Mögliche Werte:
#
# [leer]: Das System fällt in die Standardsprache zurück,
# wenn keine Übersetzung vorliegt.
#
# "content_fallback": Es wird immer mit der Übersetzung gearbeitet,
# auch wenn eine Seite nicht übersetzt
# wurde. Dadurch fallen die Menüs nicht immer
# auf die Standardsprache zurück.
#
# "strict": Bei fehlenden Übersetzungen wird nichts gezeigt,
# auch nicht die Standardsprache.
#
#########
Der Wert für $this->sys_language_mode wird entweder aus der lokalen Konfiguration der Extension entnommen oder aus den config-Einstellungen im Setup.
Bereits bei der Datenbankabfrage muss die Sprache berücksichtigt werden, da sich die Übersetzungen in der gleichen Datentabelle befinden wie die Defaultsprache, nur mit einer anderen uid und der uid der Sprachversion im Feld “sys_language_uid”.
$where = 'pid = ' . $pid . ' AND sys_language_uid IN (-1,0) '. $this->cObj->enableFields('tt_content');
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
'*',
'tt_content',
$where ,
'',
'',
''
);
Dadurch wird sichergestellt, dass immer nur die Datensätze der Default-Sprache ausgelesen werden, nicht die Übersetzungen. Diese werden im nächsen Schritt geholt.
Über eine spezielle Abfrage wird die Default-Sprache überschrieben:
while (($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res))) {
// wenn eine andere als die Defaultsprache gewählt wurde
if ($GLOBALS['TSFE']->sys_language_content) {
// Daten mit Language-Overlay überschreiben
$row = $GLOBALS['TSFE']->sys_page->getRecordOverlay('tt_content', $row, $GLOBALS['TSFE']->sys_language_content, $this->sys_language_mode == 'strict' ? 'hideNonTranslated' : '');
}
}
Dieser Aufruf bringt die neue Sprache zurück, falls eine vorhanden ist und solange der Modus nicht ‘strict’ lautet. Wenn keine Übersetzung vorhanden ist, wird die Defaultsprache zurückgeliefert, wenn jedoch zusätzlich sys_language_mode = ‘strict’ ist, dann wird ein leeres Array zurückgeliefert.
Der obige Weg muss immer eingeschlagen werden, wenn sich die Sprachversionen in der gleichen Datentabelle befinden, wie üblich in tt_content oder in Extensions. Bei den Seiten ist es allerdings etwas anders, da es hier eine eigene pages_language_overlay-Tabelle gibt. Folglich muss bei der Datenbankabfrage nicht die language_uid berücksichtigt werden, da immer nur die Seite in der Defaultsprache gefunden wird.
Es muss nur im Anschluss an die Abfrage erneut der Language-Overlay aufgerufen werden:
while ($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
if ($GLOBALS['TSFE']->sys_language_content) {
$row = $GLOBALS['TSFE']->sys_page->getPageOverlay($row);
}
}
Wie man sieht, funktioniert es etwas anders als bei normalen Content-Elementen.
Absicherung von Downloadbereichen, so dass kein direkter Link mehr möglich ist. Für verschiedene Dateitypen und unterschiedliche Ordner. Erzwungener Download möglich.
Statistik für das oben beschriebene Secure Downloads (Backend-Modul)
Downloadbereich mit Kategorien und Listen; ausserdem Community-Funktionen wie Bewertungsmöglichkeiten, am häufigsten Heruntergeladen, sponsored Downloads und statistische Auswertung. Ermöglicht vor allem Front-End-Usern einen Upload bzw. Upload-Vorschläge.
Dateiliste für Download, wobei die Dateien wahlweise in der DB oder als Datei zur Verfügung stehen. Front-End-User können eigene Kriterien für Downloadlisten erstellen (Subscribe-Funktion). Extension kann ich andere Extensions intergriert werden. indexed_search kann den Inhalt durchsuchen.
Berechtungen für versch. Frontend-Usergruppen möglich, allerdings wird bei fehlender Berechtigung der Datensatz gar nicht gezeigt. Anzeige + Verweis auf Login ist nicht möglich.
Integration mit der Extension link_handler; also Verlinkung aus dem RTE möglich.
Man kann Downlaoddateien per E-Mail bestellen. Darstellung der Dateien wie in einem Shop. Enthält keinerlei Bezahlmodul und keinen Warenkorb.
Downloadlisten mit (ausführlichen) Beschreibungen, Click-counter, Dateigrößen und Vorschau.
Erstellen von Downloadlinks mit jeweils eigenem Click-Counter.
Erstellen von Downloadlisten für unterschiedliche Dateiarten. Kann Quelltext als Text darstellen. Ausführliche Statistik. Suche. Listen können echte Downloads enthalten oder externe Links.
Passwortschutz für Downloads als eigenes Inhaltselement. Der Besucher muss ein Passwort eingeben, dann kann er downloaden. Keine Lokalisierung!
Erlaubt einen passwortgeschützten Download. Mit Statistikfunktionen im Backend.
Passwortgeschützte Downloads als neues Inhaltselement. Kann ergänzt werden um eine Liste von Usern, die downloaden dürfen. Leider als kommaseparierte Liste und nicht als Gruppe … kann aber wahrscheinlich leicht angepasst werden.
]]>Allerdings muss er sichtbar sein beim Einrichten der Benutzergruppen, sonst ist es ja nicht möglich, ihn den Gruppen zuzuweisen; man muss diese Option also öfter an- bzw. wieder ausschalten.
Ausserdem benötigen die Redakteure Schreibzugriff auf die Tabelle »Medien«.
DAM-Extension für Redakteure einrichten
TCEFORM.[tablename].[field] {
# Feld komplett entfernen:
disabled = 1
# Item entfernen
removeItems = 1,2,3
# Item hinzufügen (Achtung: erfordert für das Frontend noch TypoScript im Template!)
addItems.[itemValue] = 100,101
# Umbenennen
altLabels.[item_value] = ein ganz neuer Name
}
Leider gibt es keine Dokumentation, welche Optionen für welches Feld zur Verfügung stehen und wie diese im Frontend ausgegeben werden. Das kann man wohl am einfachsten aus dem Quelltext des Eingabeformulars im Backend entnehmen. Für das Frontend kenne ich im Moment nur die Möglichkeit, es auszutesten bzw im Falle von tt_content das TypoScript von css_styled_content durchzusehen.
Ins TSconfig der der Seite folgendes eintragen:
TCEFORM.tt_content {
# ausblenden
header_layout.removeItems = 1,4,5,100
# mit anderem Namen versehen
header_layout.altLabels.0 = Ebene 1, H1
header_layout.altLabels.2 = Ebene 2, H2
header_layout.altLabels.3 = Ebene 3, H3
}
Falls H1 nicht genutzt werden soll, muss die Default-Einstellung noch geändert werden, bzw. die Ausgabe für header_layout.altLabels.0. Das geht über folgende Eingabe im Constants-Bereich des TypoScript-Templates:
# Voreinstellunge auf Headline <h3>
content.defaultHeaderType = 3
TCEFORM.tt_content {
# Rahmenoptionen im Bereich Typ
section_frame {
# neue Labels
altLabels {
10 = Kasten
5 = Linie davor
6 = Linie danach
11 = BoxBlau
12 = BoxGrau
}
# ausblenden
removeItems = 1, 20, 21
}
}
Das ist etwas aufwändiger, da hierzu auch das TypoScript von tt_content verändert werden muss. Erster Schritt im TSconfig der Seite:
# neuer Rahmen dazu
TCEFORM.tt_content.section_frame {
addItems.100 = Mal ganz anders
}
Danach im TypoScript-Template:
tt_content.stdWrap.innerWrap.cObject = CASE
tt_content.stdWrap.innerWrap.cObject {
100 = TEXT
100.value = <div class="mal-ganz-anders">|</div>
}
Danach ganz normal in der CSS-Datei formatieren.
ACHTUNG: Das funktioniert seit TYPO3 4.3 nicht mehr; hier wurde css_styled_content etwas verändert. Man kann zwar die alte Fassung als static_content in das Template laden, aber besser ist es, es auf die neue Art zu machen:
tt_content.stdWrap.innerWrap.cObject {
# Definitionen zuweisen
100 =< tt_content.stdWrap.innerWrap.cObject.default
# Klasse zuweisen
100.15.value = mal-ganz-anders
}
Das hat auch den Vorteile, dass die Abstände oben und unten funktionieren.