RTE: Bereinigung des importierten Dokumentencodes

Ich verschiebe gerade Inhalte von Dokuwiki (dokuwiki [DokuWiki]) nach Discourse. Die Dokuwiki-Syntax ist kein sauberes Markdown, daher muss sie manuell bearbeitet werden. Ich benutze normalerweise den alten Editor, da ich dort alle Zeichen sehen kann. Aber mit dem alten Editor sehe ich seltsame „Sprungeffekte“: Wenn man einen Textblock markiert und versucht, ihn zu formatieren, springt der Cursor auf und ab. Das Neuformatieren von längeren Texten ist auf diese Weise kaum möglich, da man sein Bearbeitungsfenster immer wieder neu positionieren muss. Es ist schwer zu beschreiben, ich könnte es nur mit Screencasts zeigen … Der Effekt wurde bereits früher in Cursor springt im Komponisten-/Editor-Textfeld herum beschrieben.

Der RTE-Editor zeigt diesen Effekt nicht. Aber mir fehlt eine Option, um unordentlichen Code, der aus anderen Systemen importiert wurde, zu bereinigen…

1 „Gefällt mir“

Können Sie mir zeigen, wie dieser Junk-Code aussieht?

1 „Gefällt mir“

Wie viele? Zehn, Hunderte, Tausende von Beiträgen?

Wenn es mehr als ein paar sind, ist es wahrscheinlich sinnvoll, ein Import-Skript dafür zu verwenden. Wenn es nicht so viele sind, ist es wahrscheinlich immer noch sinnvoll, etwas Code zu bekommen, um das Markdown zu reparieren, anstatt zu versuchen, es von Hand zu bearbeiten. (Eine noch verrücktere Lösung wäre es, ein Plugin zu haben, das die Dokuwiki-Edits handhabt).

Es sind nicht so viele, aber vielleicht genug, um über eine skriptbasierte/programmatische Lösung nachzudenken. Das Schwierige ist, dass der Code DokuWiki-Syntax ( wiki:syntax [DokuWiki] ) plus erweiterter UI-Code von einer Bootstrap3-Vorlage (https://getbootstrap.com) ist. Es sieht gut aus, aber ich hatte keine Inhaltsmigration im Sinn, als ich es so eingerichtet habe. Das Hauptproblem ist nicht die DokuWiki-Syntax, sondern der Bootstrap <div> … Kram. Codebeispiel:

<div class="level1">&nbsp;</div> <h2 class="page-header pb-3 mb-4 mt-5">Plattenplatz ermitteln</h2> <div class="level2"> <p>Filtern auf ext4, was ist verfügbar?</p> <pre class="code"> root@tokoeka ~ # df -h -t ext4 --total Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-root 196G 39G 148G 21% / /dev/md0 486M 400M 57M 88% /boot /dev/mapper/pve-data 3.0T 560G 2.3T 20% /mnt/data /dev/mapper/pve-backup 414G 40K 393G 1% /mnt/backup total 3.6T 598G 2.8T 18% - </pre> <p>&nbsp;</p> <p>Filtern auf ext4, was wird genutzt?</p> <pre class="code"> root@tokoeka ~ # df -h -t ext4 --output=used Used 39G 400M 560G 40K 598G </pre> <p>&nbsp;</p> </div>

Ja. Das ist ein Durcheinander. Sie können wahrscheinlich etwas Zeit mit Nokogiri verbringen und es in Markdown umwandeln.

Wenn Sie eine Zwischenablage mit genau diesem text/html-Inhalt im Rich-Editor-Modus einfügen, erhalten Sie einen Inhalt, der zu diesem Markdown führt:

## Plattenplatz ermitteln

Filtern auf ext4, was ist verfügbar?

```
 root@tokoeka ~ # df -h -t ext4 --total Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-root 196G 39G 148G 21% / /dev/md0 486M 400M 57M 88% /boot /dev/mapper/pve-data 3.0T 560G 2.3T 20% /mnt/data /dev/mapper/pve-backup 414G 40K 393G 1% /mnt/backup total 3.6T 598G 2.8T 18% -
```

Filtern auf ext4, was wird genutzt?

```
 root@tokoeka ~ # df -h -t ext4 --output=used Used 39G 400M 560G 40K 598G
```

Es ist verlustbehaftet in Bezug auf Dinge, die uns nicht interessieren (divs, classes usw.), versteht aber hN, pre oder alles, was in unserem ProseMirror-Schema definiert ist, das unsere verschiedenen Editor-Erweiterungen respektiert, die parseDOM-Definitionen registrieren, die vom Parser von ProseMirror verwendet werden, einschließlich derjenigen aus Theme-Komponenten oder Plugins.

Was die ursprüngliche Frage betrifft:

Ich denke, wenn der Rich-Editor das Dokument lädt, ist es nicht mehr dasselbe HTML, oder?

Denn ein Beitrag raw, der HTML-Blöcke enthält, sollte als “Pass-Through”-Code-Editor-Knoten gerendert werden:

Dies kann dann auf die gleiche Weise bearbeitet werden wie im Markdown-Modus.

1 „Gefällt mir“