- Betroffene App
- WoltLab Suite Core
Kein Fehler und auch kein zwingendes Problem, aber ich hätte gerne einen EL beforProcess@HtmlInputProcessor mit der Möglichkeit dort das HTML zu bearbeiten bevor es verarbeitet wird.
Kein Fehler und auch kein zwingendes Problem, aber ich hätte gerne einen EL beforProcess@HtmlInputProcessor mit der Möglichkeit dort das HTML zu bearbeiten bevor es verarbeitet wird.
Welche Form von Veränderung willst du denn vornehmen, so dass beforeProcess@HtmlInputNodeProcessor keine Option darstellt?
Ich will html-code in eigenen metacode umwandeln ohne dafür explizit in den redactor eingreifen zu müssen um das zu tun.
Nutze ich beforeProcess@HtmlInputNodeProcessor muss ich zunächst den purifyer alle attribute schützen lassen obwohl es genügen würde dies nur für meine eigenen meta codes zu tun.
Im Grunde stört mich nur dass ich keine Möglichkeit habe etwas zu unternehmen bevor der Purifyer alles zerlegt (denn das hat er mir viel zu häufig bei meinen bisherigen Tests)
Dir steht es frei per Event-Listener die Filter von HTMLPurifier anzupassen um deine Vorstellung umzusetzen.
Das weiß ich, muss ich ja auch tun für meine meta tags.
Nur ist es deutlich komplexer verschiedene attribute zuerst zuzulassen und dann erst alles zu validieren und dann nochmals selbst alles wieder zu entfernen was nicht valide war, als zunächst alles zu validieren und dann purifyer alles rauswerfen zu lassen was ich nicht umgewandelt habe.
Der von mir aufgezeigte Weg ist bewusst so gewählt, er mag zwar an einigen Stellen je nach Vorhaben etwas umständlicher sein, sorgt aber für eine saubere und vorhersehbare Verarbeitung. Ein zusätzliches Event um dies alles zu umgehen wird es daher nicht geben, das ist es schlicht nicht wert.
Und an welcher Stelle würde man dann reinen text am besten in meta code umwandeln ?
Denn das ist mir dann bisher nicht ganz klar, bei dem Event hab ich ja, soweit ich das sehe, nur Zugriff auf den Dom, kann zwar das HTML auslesen aber nicht direkt manupulieren oder hab ich da etwas übersehen ?
Klar, du kannst das DOM so manipulieren wie du lustig bist, es verhält sich sehr ähnlich wie die Interaktion mit dem DOM in JavaScript. Ganz am Ende wird aus dem DOM wieder ein HTML-String erzeugt der dann in der Datenbank gespeichert wird.
Gibt es eigentlich im WSC einen RecursiveDOMIterator oder etwas vergleichbares ?
Nein, wofür bräuchtest du denn einen?
Naja, ich stehe noch immer vor der frage wie ich am effizientesten nach einem String im Dom suchen kann.
Die eine Variante wäre es den Dom als string ausgeben zu lassen, alles zu ersetzen, neu zu parsen und dann den neu original dom durch den neu geoparsten zu ersetzen was ich aber als unschön empfand.
Also dachte ich darüber nach über den dom zu iterieren und in allen text nodes danach zu suchen und dann nur dort den dom zu manipulieren wo ich auch wirklich meinen gesuchten string finde.
Ein entspechender iterator wäre da hilfreich, auch wenn mir klar ist dass man dies auch über eine reguläre rekursion lösen kann, fand die lösung nur unschön und hätte daher einen iterator gewünscht.
OK, hab die Lösung gefunden, hatte nicht an xpath gedacht, $this->htmlInputNodeProcessor->getXPath()->query('//text()') löst mein Problem
@Morik Korrekt, du kannst dir auch den HtmlInputNodeTextParser anschauen, der nutzt genau das.
Jap, genau so nen Beispiel habe ich gesucht, stand wie gesagt etwas auf dem schlauch da ich mich zu sehr auf die normalen Dom möglichkeiten versteift hatte und an alternativen nicht gedacht hatte.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!