Schnellnavigation:

Kategorien

« März 2024»
S M T W T F S
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Letzte Nachrichten

DSGVO
26.05.2018 18:39
Trackingtools und Datenschutzerklärung
14.03.2014 23:07
1:n und n:1 Relationen in Extbase
06.12.2013 12:04
Erste Abmahnungen wegen Google Analytics
04.10.2013 12:11

Kopieren Sie diesen Link in Ihren RSS-Reader

RSS 0.91Nachrichten
RSS 2.0Nachrichten

In eigener Sache

Peter Linzenkirchner, Lisardo EDV Beratung in Augsburg. Freelance und Partner für Design- und Webagenturen in Augsburg und München. Pixelgenaue Templates, valides HTML, barrierearm. TYPO3-Projekte, Extension-Programmierung und mehr ... 

Zur Zeit wird gefiltert nach: rte
Filter zurücksetzen

Es ist prinzipiell möglich, den RTE in Flexforms – und damit auch in FCEs – zu konfigurieren. Wie das geht, wird  im Wiki auf typo3.org beschrieben, oder in der API-Dokumentation (nach »defaultExtras« suchen). Mit diesem Eintrag in den defaultExtras wird der RTE z. B. beschränkt auf fett, kursiv und Links:

  1. <defaultExtras>richtext[bold|italic|link]:rte_transform[mode=css]</defaultExtras>

Oder vielmehr sollte ... es funktioniert nämlich nicht mehr. Es gibt einen Bug-Report dazu, dem auch ein Patch für die Core-Klasse class.t3lib_tceforms beiliegt. Nach dem Einspielen des Patch funktioniert es wieder. 

Kategorien: API/Tipps  Kommentare 0
Tags: rte, fce

Zumindest in den neueren Versionen von tYPO3 (meines Wissens ab 4.3) ist es möglich, in den normalen Menüs eine interne oder externe Seite in ein Popup-Fenster zu laden, ohne dazu eine zusätzliche Extension bemühen zu müssen. Dazu bekommt die betreffende Seite (egal ob Standard oder Link to external URL) einfach die Fenstergröße mitgeteilt.

Dazu wird in das Feld »Target« anstatt den üblichen Angaben wie »_blank« in den Seiteneigenschaften einfach die Fenstergröße geschrieben, z. B. so:

500x600 - das ergibt ein Fenster in Standardeinstellungen mit der Größe 500x600 Pixel.

Es können aber noch mehr Angaben eingefügt werden, die im wesentlichen die Darstellung des Browserfensters regeln, also Scrollbalken ja/nein, Fenster-Zoom ja/nein, Werkzeugleiste ja/nein und so weiter:

500x600:status=1,menubar=1,scrollbars=1,resizable=1,location=1,directories=1,toolbar=1

Man beachte den Doppelpunkt zwischen der Größenangabe und dem Rest. Damit sind alle Einstellungen möglich, die Typoscript über die typolink-Funktion erlaubt. (Dort zu finden unter den Stichworten »parameter« und »JSwindow_params«)

Popup-Links im RTE

Natürlich geht das ganze auch im RTE.

Tipp: Bei internen Seiten muss natürlich darauf geachtet werden, dass die Inhalte auch im Popup-Fenster Platz haben. Also muss entweder das Fenster entsprechend groß engstellt werden, oder der Admin / Entwickler muss ein eigenes Template für derartige Popp-Fenster vorsehen. Dieses Template muss der Seite dann noch zugewiesen werden. 

Weiterführende Links:

Kategorien: Anleitungen  Kommentare 0
Tags: popup, rte

Im RTE kann man horizontale Linien einfach mittels Blockstilen zur Verfügung stellen, die einem Absatz zugewiesen werden können. Diese Stile müssen allerdings vom Entwickler zur Verfügung gestellt werden. 

Dieser Absatz hat z. B. eine Linie oberhalb, die auf diese Art eingefügt wurde. 

Der RTE kann allerdings auch das HTML-Element <hr /> einsetzen, das unabhängig ist von den Blockelementen bzw. Absätzen.

Standardmäßig macht der RTE dabei leider einen Fehler: er packt die Linie in einen Absatz: <p><hr /></p>, was beim Validieren der Seite zu einem Fehler führt. Dieser Fehler stört allerdings die optische Darstellung nicht, wer also mit einem Validierungsfehler leben kann, muss nichts weiter unternehmen. 

Der Fehler kann eleminiert werden, wenn in das TypoScript-Template der Seite diese Zeilen eingefügt werden:

  1. lib.parseFunc_RTE.externalBlocks := addToList (hr)
  2. lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1

Leider hat das aber andere negative Konsequenzen. Wenn ich z. B. hier so eine Linie einfüge:


werden die folgenden Absätze nicht mehr richtig geparst. So werden z. B. in meinen Code-Snippets der <pre>-Tag nicht mehr korrekt von  tx-vjrtecodesnippets erkannt und geparst: 

lib.parseFunc_RTE.externalBlocks := addToList (hr)
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1


Ausserdem werden offensichtlich Links nicht mehr geparst. Das ganze ist ein Problem, das offenbar seit 2007 im Bugtracker steht, aber bis heute nicht wirklich gelöst wurde (hier sollte eigentlich ein Link stehen, der aber nicht geparst wird. Er folgt im nächsten Absatz, den ich in ein neues Inhaltselement packe.) 

Fazit:

Ich empfehle die Verwendung von Blockstilen wie ganz oben beschrieben. Wenn man unbedingt <hr /> verwenden muss, so sollte der Workaround gründlich getestet werden. Wenn – wie bei mir hier – die Fehler nicht gefixt werden können, dann muss man wohl oder übel mit dem Syntaxfehler des RTE leben. Wie gesagt: die Darstellung ist ja korrekt, es gefällt nur den Validatoren nicht.

Und hier ist der Link in den Bugtracker nochmals ...

[Update]
Für den Bug gibt es seit kurzem einen Fix im Bugtracker von Stanislas Rolland, der das Problem behebt. (Vielen Dank an Stanislas!)

Also Patch einspielen, oder aufs nächste Update von TYPO3 warten, dann wirds wohl dabei sein. 

[Update 2]

In Version 4.4.6 funktioniert es jetzt. 

Kategorien: Tipps/Typoscript  Kommentare 0
Tags: rte

Seit Version 4 von Typo3 ist der Rich Text Editor »htmlArea RTE (rtehtmlarea)« fester Bestandteil der Typo3-Installation. Ich beziehe mich im folgenden auf diesen RTE, nicht auf den älteren.


[mehr]
Kategorien: Backend  Kommentare 0
Tags: htmlarea, rte
01September2010

Custom Tags im RTE

In der Grundkonfiguration entfernt der RTE eine Reihe von nicht erwünschten Tags. Je nach eingestellter Grundkonfiguration erhält er eigene Tags, löscht diese oder wandelt sie in Entities um. Um eigene Tags zu ermöglichen, sollte deshalb der  Konfiguration des RTE einiges hinzugefügt werden. 

  1. RTE.default.proc.allowTags:=addToList(sondertag)
  2. RTE.default.proc.allowTagsOutside:=addToList(sondertag)
  3. 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:

  1. RTE.default.proc {
  2.         allowTags(
  3.             a,abbr,acronym,b,bdo,blockquote,br,cite,code,col,colgroup,del,dfn,div,em,
  4.             h1,h2,h3,h4,h5,h6,hr,i,img,li,ol,p,span,strike,strong,sub,sup,
  5.             table,thead,tbody,tfoot,td,tr,th,ul,sondertag,
  6.         )
  7. }

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:

  1. lib.parseFunc_RTE.allowTags:=addToList(sondertag)

Beziehungsweise für alle Texteingabefelder, die nicht den RTE benutzen:

  1. 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:

  1. # eigenes PHP-Script:
  2. 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:

  1. # über TS
  2. lib.parseFunc_RTE.tags.myTag=TEXT
  3. lib.parseFunc_RTE.tags.myTag {
  4.     # mit current=1 enthält man den aktuellen Inhalt des Tags
  5.     current=1
  6.     # eigenes wrap, z. B. für Boxen
  7.     wrap(
  8.         <divclass="box">
  9.             <divclass="top"></div>
  10.                 <divclass="center">|</div>
  11.             <divclass="bottom"></div>
  12.         </div>
  13.     )
  14.     # Leerzeilen vor und nach dem Inhalt des Tags entfernen
  15.     stripNL=1
  16. }

Einfügen über User-Elemente

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:

  1. RTE.default{
  2.     hideButtons(
  3.         lefttoright,righttoleft,formattext,bidioverride,big,
  4.         citation,definition,insertedtext,italic,keyboard, 
  5.         monospaced,sample,small,span,strikethrough,
  6.         variable,bold,underline,fontstyle,fontsize,
  7.         blockquote,insertparagraphbefore,insertparagraphafter,inserthorizontalrule,
  8.         spellcheck,emoticon,inserttag,copy,cut,paste,
  9.         justifyfull,textcolor,bgcolor,
  10.     )
  11. }

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:

  1. RTE.default{
  2.     userElements {
  3.         10=Eigene Sondertags
  4.         10 {
  5.             1=Sondertag
  6.             1.description=Der ausgewählte Text wird umschlossen von<sondertag></sondertag>
  7.             1.mode=wrap
  8.             1.content= <sondertag>|</sondertag>
  9.         }
  10.     }
  11. }

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 sogarPHP-Skript darüber aufgerufen werden, die markierte Inhalte vor der Übergabe verarbeiten.

Fehler / Probleme

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:

  1. ### das hier verursacht den Fehler:
  2. lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.remapTag.DIV=P
  3. ### so abschalten:
  4. 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.

Weiterführende Links

  • Manual auf Typo3.org Hinweis: das Manual ist nicht auf dem üblichen Weg zu finden; die Extension gehört zwar mittlerweile zur Standardinstallation, aber sie wird in der Core-Dokumentation gelistet. Es gibt deshalb eine eigene Extension nur für das Manual von htmlArea RTE. Interessant sind hier vor allem die Abschnitte »userCategory« und »userElements«
  • Tags Der Abschnitt über eigene Tags in TSref. 
Kategorien: Backend/Typoscript  Kommentare 0
Tags: rte, tag