Hallo, wie in Makeshift but working flarum import script erwähnt, habe ich von Flarum zu Discourse migriert. Meine erste Seite, und ich bin total begeistert von eurer Arbeit – ein großes Lob an euch alle.
Etwas, das auf den ersten Blick in der Entwicklung perfekt zu sein schien, war die Art und Weise, wie alle Beiträge migriert wurden. Im Browser sehen die meisten gut aus, aber unter der Oberfläche gibt es viele veraltete HTML-Tags, die Probleme beim Laden von Bildern und beim Importieren in den lokalen Speicher usw. verursachen.
Gibt es eine clevere Möglichkeit, das HTML-Markup nach der Migration aller Beiträge zu bereinigen?
Eine weitere Frage: Ich muss auch viele URLs von http auf https korrigieren.
Danke für eure Hilfe. Übrigens sollte das makeshift-Skript, das ich bereitgestellt habe, definitiv angepasst werden, um die Beiträge besser im Discourse-Beitragsformat zu verarbeiten (das liegt nicht in meinem Kompetenzbereich)…
Am einfachsten lassen sich diese Probleme im Importer beheben. Wenn ihr bereits live geschaltet habt und das keine Option ist, wird es schwieriger. Ihr müsst dann einfach Code schreiben, um den Roh-Text zu ändern und die Beiträge neu zu rendern. Es gibt keinen Zaubertrick, fürchte ich.
Es klingt so, als hättest du das Problem, das hier beschrieben wird: Fix broken images for posts created by the WP Discourse and RSS plugins. Meine erste Antwort in diesem Thema gibt einige Details dazu, was das Problem verursacht. Das Problem betrifft Bilder in Beiträgen, die mit HTML erstellt wurden. Ich werde den Titel des Themas aktualisieren, um klarzustellen, dass es nicht nur Beiträge betrifft, die mit dem WP Discourse-Plugin oder einem RSS-Feed erstellt wurden.
Idealerweise könnte der Discourse-Markdown-Parser HTML-Bild-Tags verarbeiten, die in andere HTML-Tags eingebettet sind. Ich denke, es ist jedoch ein schwieriges Problem zu lösen.
Ja, genau dieses Phänomen tritt bei meinen defekten Bildern innerhalb anderer HTML-Tags auf.
Ich habe begonnen, dies manuell zu korrigieren, aber das ist mühsam und wird dadurch erschwert, dass der Beitrag dadurch wieder ganz oben in der neuesten-Liste erscheint. Das erfordert ein manuelles Zurücksetzen des Bumpings usw.
Ich werde mich nun daran machen, die Logik zum Entfernen der HTML-Tags herauszufinden, indem ich mir ein paar besonders problematische Beiträge anschaue. Anschließend könnte ich Hilfe benötigen, um diesen Prozess für die gesamte Datenbank zu automatisieren. Ich werde versuchen, Data Explorer zu nutzen, um diesen Teil zu lösen. Erlaubt Data Explorer, als IDE für solche Post-Transformationen zu fungieren?
Hallo, ich habe herausgefunden, wie man manuell aufräumt und kaputte Bilder repariert. Allerdings möchte ich das automatisiert erledigen.
Ich möchte eine Möglichkeit finden, alle HTML-Tags wie [P] und [/P] sowie [BR/] zu entfernen.
Ich habe im Forum gesucht, aber nichts Passendes gefunden. Auch die Import-Skripte enthalten keinen Discourse-zu-Discourse-Importer, von dem man ausgehen könnte. Ich gehe davon aus, dass ich ein Skript brauche, das:
auf die posts-Tabelle zugreift,
durch alle Posts iteriert,
durch jeden Post iteriert:
–> P-Tags komplett entfernt,
–> BR/ durch einen Zeilenumbruch ersetzt,
–> etwas Sinnvolles mit URLs macht,
–> etwas Sinnvolles mit Bildern macht,
und wahrscheinlich alle Posts neu rendert.
Kann mich jemand zu einer relevanten Diskussion auf Discourse führen, oder hat jemand ein Skript oder Code-Snippets, mit denen ich starten kann? Ich bin kein erfahrener Entwickler, aber ich kann funktionierende Dinge anpassen…
Sobald ich mein Ziel erreicht habe, werde ich die Ergebnisse mit der Community teilen.
Hier ist ein Code-Beispiel, das Ähnliches bewirkt:
posts=Post.where("raw like '%Sent from%using Tapatalk'")
posts.each do |post|
post.raw.gsub!(/^Sent from my.+?using Tapatalk$/,"")
post.save
post.rebake!
end
Als wir unser Forum migriert haben, hatten wir unzählige Probleme mit BBCode und Tags aus fast zwei Jahrzehnten Forumsposts.
Wir haben die rake-Remap-Funktion dafür nicht verwendet und haben in allen Fällen die Technik angewendet, die @pfaffman in seinem Code-Snippet beschreibt:
Das obige Code-Snippet mit gsub() fasst eine der besten Methoden zusammen, um die Rohpostings nach (oder noch besser: während) der Migration zu bereinigen.
Stellen Sie sicher, dass Sie Ihre REGEX-Ausdrücke TESTEN, BEVOR Sie sie tatsächlich auf der Datenbank implementieren, und haben Sie vor solchen direkten Operationen an Ihrer Datenbank ein vollständiges Backup.
Hallo, unten findest du den Inhalt meines Skripts cleanup.rb, das ich mit folgendem Befehl starte: RAILS_ENV=development bundle exec ruby script/cleanup.rb
Inhalt der Datei:
require_relative '../config/environment'
pm = 0
Post.find_each do |test|
test.raw.gsub!(/<(.|\/.)>/i,"")
test.save
test.rebake!
pm = pm + 1
end
puts "cycled through #{pm} posts"
Ich habe rake posts:rebake ausprobiert, was 1757 Beiträge neu verarbeitet hat. Das Skript durchläuft jedoch nur 1712 Beiträge, was dem importierten Inhalt mit HTML-Tags entspricht, während der Rest neue Beiträge ist, die in Discourse erstellt wurden.
Ich glaube, ich bin fast soweit, aber wenn ich den rohen Inhalt in der Benutzeroberfläche überprüfe, sehe ich weiterhin alle HTML-Tags.
Ich habe versucht, die Umgebung neu zu starten und Unicorn erneut zu starten, aber das hat nichts gebracht. So nah dran… so nah dran ;o)
Deinen Vorschlag aus Rubular habe ich verwendet, und jetzt zeigt regexr.com das untenstehende Screenshot. Ich habe vorerst nur die p- und r-Tags ausgewählt und diese erst einmal sortiert, bevor ich die komplexeren hinzufüge.
Als ich eine put-Anweisung zu meiner kleinen cleanup.rb hinzufügte, um den Rohinhalt der Beiträge in der CLI auszugeben, fiel mir auf, dass überhaupt keine HTML-Tags ausgegeben wurden.
Wenn ich jedoch einen Beitrag bearbeite, sehe ich Folgendes, wobei die HTML-Tags auf der rechten Seite angezeigt werden. Das scheint nicht der Normalfall zu sein, denn wenn ich zurückkomme, um den Beitrag zu bearbeiten, den ich gerade bearbeite, sehe ich keine HTML-Tags…
Dieses gsub benötigt ein g nach dem /i, um mehrere Tags zu matchen. Wenn das, was du in deinem puts siehst, jedoch anders ist als das, was nach dem Ausführen des Skripts zu sehen ist, habe ich keine Erklärung dafür.
Es scheinen jedoch zwei Dinge zu geben, die ich mit diesem Skript nicht erklären kann:
# So rufst du es auf:
# RAILS_ENV=development bundle exec ruby script/cleanup.rb -> cleanup.log
require_relative '../config/environment'
pm = 0
Post.find_each do |test|
puts test.raw
test.raw.gsub!(/<(.|\/)>/im,"")
test.save
test.rebake!
pm = pm + 1
end
puts "#{pm} Beiträge durchlaufen"
Nach mehrmaligem Ausführen enthält die cleanup.log weiterhin 10 Instanzen von <p> in etwa 21.000 Zeilen rohen Beitragsmaterials. Diese werden seltsamerweise nie entfernt.
Noch seltsamer (für mich) ist, dass ich, wenn ich Unicorn starte und die Site auf meinem lokalen Computer aufrufe, immer noch die HTML-Tags in allen Beiträgen sehe, die ich in der Rohansicht des Editors überprüfe.
Mir scheint, ich schaue vielleicht nicht in dieselbe Umgebung? Schaut d/Unicorn auf eine lokale Produktionsumgebung, während mein Skript Änderungen auf dev anwendet?
Ich versuche zunächst, dies mit der Docker-Anleitung für die Entwicklungsumgebung lokal zum Laufen zu bringen, bevor ich zu meiner Live-Site gehe.
Es muss etwas Großes sein, das ich als Anfänger übersehe.
