Generics gehen bei "Fix formatting post-migration: Javas, rmCRs" kaputt

ahh ok Problem ist gefunden, die kamen schon aus der anderen Datenbank mit gt lt daher sind sie hier auch wieder so

ist das korrekt? bevor ich wieder alles kaputt mache :smiley:

UPDATE  posts p SET raw =  regexp_replace(raw, '<', '<', 'gi');
UPDATE  posts p SET raw =  regexp_replace(raw, '>', '>', 'gi');

Wie sieht es denn mit anderen Codes wie & aus? Denkbar wäre noch, dass < in html-Quellcode so vorkommt und auch so stehen bleiben soll.
Wenn das & aber als & codiert ist, dürfte das kein Problem sein.

Fixed:

Genau das ist das schwierige daran. Man kann nicht einfach ersetzen. Wenn ein "String < blöde \" Zeichen & anderen Mist" enthält, muss man das erkennen…

Danke, das hatte ich auch so eingegeben, aber nicht nochmal nachgelesen, was die Software draus gemacht hat.
Test: <
Test2: <

Edit: irgendwie hat mein Edit meinen letzten Beitrag bearbeitet - jetzt habe ich den wieder zurück editiert. Alles sehr verwirrend…

das ist ein valider Punkt, sollte derjenige brav code blöcke benutzt haben sollte da das & ersetzt sein wenn nicht dann ups :smiley:
ich kann natürlich auch noch einmal die Posts zurücksetzen und gucken dass ich nen Regex bau für Postgres der abfragt nur bei nicht ``` oder code Blöcken das ersetzt

Naja, wenn man das nicht direkt auf der Datenbank, sondern skriptgesteuert mit der Editfunktion machen würde, dann hätte man den alten, fehlerhaften Beitrag immer noch verfügbar und könnte im Zweifelsfall nachsteuern.

nein da ist nix mit Script ich hab das alles auf db Ebene gemacht :wink:
aber die Sache ist die, wer will jeden einzelnen Beitrag ansehen und gucken ob was komisch gemacht wurde?

Das ist ja gar nicht erforderlich. Man sähe nur unmittelbar, dass der Beitrag bearbeitet ist und könnte in dem Fall, dass man feststellt, dass etwas merkwürdig ist, die Originalversion ansehen und den Beitrag dann manuell zurückeditieren (lassen).

„dass der Beitrag“ ?
wenn das Script los läuft und all <> fixt, wirst du 9685 Beiträge bekommen, die willst du alle durch gucken? :wink:
bzw, wenn du magst geb ich dir die alle du guckst durch und sagst mir welche IDs nicht nicht bearbeiten soll :smiley:

Vllt. habe ich mich nicht richtig ausgedrückt. Ich meinte, dass alle Beiträge editiert werden, wobei es einige false positives geben wird (siehe Beispiel oben). Wenn die Bearbeitung über die Editfunktion passiert, kann man dann, wenn man zufällig auf einen fälschlicherweise gefixten Beitrag stößt, diesen einzelnen Beitrag zurück editieren.

Alles natürlich unter der Prämisse, dass die Bearbeitung nciht direkt in der Datenbank passiert (siehe mein vorletzter Beitrag in diesem Thread).

Ich werde nicht aufhören. Dazu ist mir das Forum und seine Geschichte zu wichtig. Sowas wie Proof of Concept Multi-Part Formdata Parser in C++ ist immernoch kaputt. Sowohl die include-Klammern, als auch newlines.

1 „Gefällt mir“

Ich habe letztens nochmal einen alten Thread von mir ausgekramt und durchgelesen - schön ist anders.
Hier sieht man nochmal den < > Bug:

Und dieser Beitrag ist ein Beispiel für eine ganze Reihe von Übernahmefehlern:

  1. Inline-Tags wurden nicht in Festbreitenschriftart übernommen, die bbcodes stehen noch darin
  2. Die Listenpunkte ([li]-Tags) wurden nicht korrekt übernommen
  3. Die Codeblöcke wurden falsch übernommen (nicht alle Codezeilen wurden als Code erkannt, scheinbar sind die Backticks in der falschen Zeile / falschen Anzahl)
  4. Bei Zitaten steht oben der Namen und die Post-ID vom zitierten Beitrag, was unschön aussieht (wenig problematisch, die anderen Punkte wiegen deutlich schwerer, weil sie den Lesefluss arg hemmen)

Es ist schwierig, bei einem „kaputten“ Beitrag „die“ Ursache zu erkennen. Ich denke, dass es immer Beiträge geben wird, die kaputt sind - nicht zuletzt weil einzelne vielleicht schon im Original kaputt waren (aber man es einfach nicht gesehen hat). Der Klassiker wären da „doppelte schließende Tags“, die IIRC oft ignoriert wurden, aber einen „Parser/Konverter“ leicht aus dem Konzept bringen können.

Besonders problematisch finde ich deswegen forenweite Fehler am Code, wie eben gerade die <>-Sache…

Aber nochmal: Man kann das ja nicht einfach ersetzen. Bei

#include <html_parser>

void main() {
    std::string tagStart = "<" // Das < steht für die < 
}

rauszupfriemeln, welche $lt; ersetzt werden müssen, ist schwierig (bis „praktisch fast unmöglich“). Aaaaber: Ich gehe davon aus, dass in der „raw“ (ungerenderten) Variante die richtigen Informationen stehen! In der Vorschau in Generics gehen bei "Fix formatting post-migration: Javas, rmCRs" kaputt werden die <> ja richtig angezeigt!

Falls hier nichts weiter kommt, frage ich mal im discourse-Forum nach. Es kann ja nicht sein, dass wir die ersten sind, die vor diesem Problem stehen :confused:

Allgemein stimme ich dir zu. Da ich den Beitrag aber selbst verfasst habe, kann ich das in diesem Fall ausschließen. Mangels URL im alten Format kann ich leider auch kein Belegexemplar aus der waybackmachine herzaubern.
Allerdings sieht man auch ganz klar, dass der letzte Listenpunkt der einzige ist, der nicht richtig übernommen wurde.

Dass der Code nur teilweise als Code erkannt wird und die ersten bzw. letzten Zeilen nicht im Codeblock sind, ist auch ganz klar ein Formatierungsfehler, der im Ursprungsbeitrag nicht vorhanden war. Das Problem dabei ist übrigens, dass nach den drei ````` zu Beginn des Quellcodes und vor den Backticks am Ende des Codes kein Zeilenumbruch steht.

Wenn der Code semantisch verfälscht wird, wiegt das natürlich deutlich schwerer, als offensichtliche Fehlformatierungen.

man warum bekomme ich keine Mails wenn was geschrieben wurde, da muss ich auch noch einmal gucken

Was meinst du mit newlines, ich hab gerade mal die History angesehen und außer dass es dort noch zerpflückter ist sehen die gleich aus

und ja ich hab das SQL Statement noch nicht los geschickt gehabt weil die Diskussion für mich noch nicht fertig war und ich die DB nicht schon wieder “kaputt” machen wollte

ich hab den Code mal gefixt ich hab nur java durch ``` ersetzt ohne davor oder danach Leerzeilen einzufügen aber einige Leute haben ihre java tags immer direkt an den Code geklebt damit kommt der Parser nicht klar

Bei den anderen müssen wir mal gucken wie wir das beheben können

Mit den newlines meinte ich, dass im Code in Proof of Concept Multi-Part Formdata Parser in C++ Leerzeilen vorkommen, die vermutlich (!) im Original nicht dort waren, sondern vermutlich (!) dort noch \n oder waren …

EDIT: Aha: Leere backticks ` zeigt er gar nicht an, nur wenn was dazwischen steht.

Ja, ich habe die Java-Tags direkt an den Code gepackt, weil die alte Software sonst zusätzliche Leerzeilen eingefügt hat.
In Discourse muss nach den drei Backticks zwingend ein Zeilenumbruch folgen, was in diesem Fall wohl nicht berücksichtigt ist.

ahh du meinst zb

 if (content.compare(pos, 2, "
") == 0) 

wow das wird nen Brocken das zu fixen

Das größte Problem ist ja, dass dieses “Fixen” SEHR schwierig ist, weil es fast unmöglich ist, das zu fixen, OHNE woanders wieder was kaputt zu machen.

Ich denke, dass man das, wenn überhaupt, nur fixen könnte, wenn man auf den Originaldaten arbeiten würde, und erkennen könnte, dass das in Code-Tags steht. Aber [java] dieser Code steht auch in Code-Tags[/java], nur sind die halt noch mit backticks eingeklammert.

Am “sichersten” wäre vermutlich: Den raw-post und den HTML-Output aus dem alten Forum getrennt ins neue übertragen - aber das ist technisch wohl kaum möglich…