Typo3 RTE mal wieder, denyTags veraltet ?

[FipsTheThief]

Seit 2 Tagen probiere ich nun schon Tags davon abzuhalten in die DB geschrieben zu werden die ich nicht sehen möchte.

Generell kann ich sagen

RTE.default.proc.allowTags = liste meiner Tags
RTE.default.proc.denyTags = liste unerwünschter Tags

Dabei soll die denyTags liste angeblich alle Tags aus der allowTags liste entfernen, also die Schnittmenge bilden. PHP print_r besagt mir, das er das auch tut, die Tags aus denyTags sind in allowTags nicht mehr vorhanden.

Aber mir scheint das ist dem vollkommen egal, die Konfigurationen über die man stößt oder Tutotrials die man liest sind 4 bis 6 Jahre alt oder noch älter. Da steht das überall drinnen mit der Begründung , Tags die ich nicht möchte mit denyTags rauswerfen.

In der Offiziellen TSConfig für den Editor steht es auch dabei das denyTags eine Liste von unerwünschten Tags angibt. Überall lese ich nun das sie in jeden HTMLparser , egal ob entryHTMLparser_db, exitHTMLparser_db oder einen anderen HTMLParser den Typo3 zu bieten hat die Eigenschaft RTE.default.proc.denyTags dort mit bekannt gemacht wird. Sogar die Standard Konfiguration hat das mit dabei von Typo3 hat dies mit dabei.

Aber ein Blick in die Core API vom RTE sagt mir das HTMLparser Object hat gar keine Eigenschaft für denyTags vorgesehen, sondern arbeitet alles das stur ab was in allowTags steht. Einzelne Ausgaben im Quelltext haben dies auch belegt aber dennoch ab und zu scheint denyTags Wirkung zu zeigen.

denyTags = article wird komplett ignoriert das darf nicht einmal in allowTags stehen damit das rausgeworfen wird erst ein explizietes keepNonMatchedTags = 1 oder protect sorgt dafür das man den kompletten Tag bzw nur noch die Reste davon sieht. Aber im Gegenzug denyTags=u zum Beispiel in RTE.proc , ja da ersetzt er tatsächlich die < und > in &lt und &rt, aber in die Datenbank wandert es dann dennoch und zwar mit < und >.

Also eventuell kann mir einer von euch das genaue Verhalten bzw den Sinn von denyTags sagen wenn es mir Augenblicklich so erschneit das es gar keine Rolle spielt ob ich das einsetz.

 

[FipsTheThief]

Inzwischen hab ich wohl eine eigene Erklärung für mein Problem gefunden, denyTags ist nicht veraltet.

Generell greift denyTags an 2 Stellen, das erste mal wenn der Inhalt aus der DB an den RTE geschickt wird, jeder Tag der da drinnen steht wird ab jetzt geschützt dargestellt, also die < und > werden in &lt; und &gt; umgewandelt, es sei denn es wird explizit ausgeschalten. Dabei ist es vollkommen unnötig ob ich nun noch denyTags in den jeweiligen Parsern angebe.

Das 2. mal wenn der entryHTMLparser_db anspringt, genauer genommen bereitet dieser nur eine Konfiguration für den HTMLCleaner vor welcher dann den Code der gleich vom RTEParser übernommen werden soll schon einmal bereinigt. Dabei arbeitet er dort stur die allowedTags ab, die nicht erlaubten sind ihm erst einmal vollkommen egal. Zwar kann auch hier noch eingestellt werden ob tags gleich rausfliegen oder bestehen bleiben. Aber denyTags wird hier nicht berücksichtigt.

Erst wenn es in den eigentlichen Parser geht wo der Code für die DB aufbereitet wird wird der Content in Blockelemente zerlegt und die Blockelemente in Zeilen und jede Zeile wird noch einmal durch den HTMLCleaner geschickt und dort werden auch die Tags behandelt die behalten werden sollen und welche nicht , dabei werden die aus denyTags nun auch wieder berücksichtigt.

Somit versteh ich die ganzen Konfigurations Beispiele nicht wo in jeden entryHTMLparser und exitHTMLparser , das denyTags hinterlegt ist wenn es eh keine Rolle spielt dort.