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


#41

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');

#42

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.


#43

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



#44

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



#45

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


#46

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.


#47

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?


#48

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).


#49

“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:


#50

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).


#51

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.


#52

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)

#53

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:


#54

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.


#55

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


#56

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


#57

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.


#58

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.


#59

ahh du meinst zb

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

wow das wird nen Brocken das zu fixen


#60

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