phpmyadmin: Zeilenumbruch (New Line \n \r\n)

  • Moin. Sagt mal, hier gibt es doch sicherlich ein paar, die auch den phpmyadmin verwenden. Gibt es dort in den Einstellungen oder so eine Möglichkeit, dem Ding beizubringen, was er als Zeilenumbruch verwenden soll, also \r\n, \n oder \r ??? Ich weiß, der nutzt die Vorgaben vom Betriebssystem bzw. in dem Fall von PHP. Ja, das wäre auch völlig ausreichend, wenn er es denn immer tun würde und nicht nur, wenn er Lust dazu hat.

    Problem:

    Meine Texte, egal von wo die kommen, User-Eingaben, Kunden-Eingaben, vom Skript erzeugt oder sonst was, sind alle mit \r\n als Zeilenumbruch. Das habe ich meinen Systemen so beigebracht, dass das immer konsistent gleich sein soll. Es ist also immer ein \r\n, egal ob die Daten von Linux kommen oder aus einer Input-Form von Windows.

    Hintergrund ist dabei, dass ich mit diesen "\r\n" arbeite und nicht nur ein nl2br habe (kommt von PHP selbst), sondern ein eigenes nl2p, das mir entsprechend Blocksätze <p> bildet und nicht einfach nur lauter <br> nacheinander.

    Ein Text schaut z.B. so aus (gekürzt):

    "... ausreichend Freifläche und Spielmöglichkeiten am Haus.\r\n\r\nIn Verbindung mit einer zweiten Ferienwohnung ..."

    Genau dieses \r\n\r\n ist hier das Merkmal, das mir die beiden Sätze in <p></p> schreibt und nicht ein "<br><br>" dazwischen.

    So, wunderbar, das geht seit 13 Jahren ohne Probleme, aber nun, keine Ahnung seit wann, zickt der phpmyadmin run. Gespeichert wird noch alles richtig, aber sobald ein Text im phpmyadmin bearbeitet wird, macht der teilweise aus einem "\r\n" einfach ein "\n", aber nicht immer. Und zack, mir fehlt die Erkennung einer neuen Zeile.

    Aus

    "ausreichend Freifläche und Spielmöglichkeiten am Haus.\r\n\r\nIn Verbindung mit einer zweiten Ferienwohnung"

    wird also

    "ausreichend Freifläche und Spielmöglichkeiten am Haus.\n\nIn Verbindung mit einer zweiten Ferienwohnung"

    Noch nicht so schlimm, aber es ist nicht konsistent. Suche ich einen bisher unbearbeiteten Datensatz und gehe dann über "bearbeiten", mache was und speichere, dann bleibt der "\r\n" da. Gehe ich aber nicht über "bearbeiten", sondern über die Schnelledit-Funktion (Doppelklick), denn wird daraus ein einfacher "\n". So, und das bleibt dann auch so. Also den Datensatz dann nochmal über die echte Bearbeiten-Funktion bearbeiten, es bleibt ein "\n". Erst wenn ich den ganzen Text lösche und neu schreibe, wird daraus wieder ein "\r\n", der auch so gespeichert wird.

    Hat einer eine Idee? Die Schnellbearbeiten-Funktion einfach weg zu lassen ist keine Option, seit man die einzelnen Datensätze nicht mehr per "in neuem Tab öffnen" einfach aufrufen kann. So mit dem ganzen Javascript-Mist ist das ein Unding, einen Satz an Datensätzen zu suchen, einen anzuklicken, alle anderes sind dann weg, den einen zu bearbeiten, speichern, wieder alle suchen, erneut einen anklicken, etc. Immer so weiter, bis man fertig ist. Sehr gerne kommt dann auch noch ein "falscher Token", wenn man "neuen Tab" doch versucht oder noch ein Fenster zu lange unbenutzt offen war.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Hm, ok, also keiner eine Idee.

    So wie es scheint, gibt es da noch viele andere, die das Problem auch haben. Sogar offizielle Bug-Reports, die auch als offizieller Bug samt Bug-Fix vorhanden sind. Witzig, das Problem geht schon seit 7 Jahren um. Behoben wurde es in phpmyadmin Version 4.7. Ebenso behoben in 4.8 und 4.9. Laut GitHub sind die Fixes dort überall enthalten und sind im Grunde nur zwei geänderte Code-Zeilen in einer Javascript-Funktion.

    Die 4.8. ist die Vorlage für den "neuen" Zweig 5.x. In denen, 5.0, 5.1 und 5.2. ist der Fehler aber wieder da. Merkt sowas eigentlich keiner?

    Muss dann wohl meine Systeme alle umstellen, alles, fast jedes verfluchte Script, nur wegen einer Anwendung. Dieser JS-Mist nervt echt. Nervt schon, seit der eingeführt wurde. Macht hier eigentlich nur Probleme. Doppelklick zum Markieren und Kopieren? Geht nicht. Reinklicken, und mit der Maus markieren. Geht teilweise auch nicht, da verschiebt man die Spalte der Tabelle (die man aber gar nicht sieht) oder es fehlt der letzte oder erste Buchstabe der Auswahl. Klickt man zu schnell, dann löst es die Ajax-Bearbeitung aus und genau bei der entsteht das Problem. Der phpmyadmin prüft ja eigentlich, ob es eine Datenänderung gab und führt ein Update nur dann durch, wenn nötig.

    Problem, dieses automatische Ersetzen von \r\n in \n wird als Datenänderung erkannt, obwohl man eigentlich gar nichts gemacht hat. Da klickt man einfach nur was an, und dieses doofe Ajax-Edit kommt:

    Da kommt man nicht mehr weg, kann nicht abbrechen oder sonst was. Man kann nur woanders klicken, dann wird aber dieses Feld gesendet und das ist dann die "Änderung". Zack, es hat den Text zerrissen.

    Wie ich dieses JS-Zeug hasse :(

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • PHPmyadmin in 2022?

    Schau dir mal https://www.navicat.com/de an, nutze es seit 15 jahren. Extrem schnell weil micht nach jeder aktion das gui neu geladen und gerendert werden muss; tabs um mehrere abfragen gleichzeitig zu oeffnen, abfragen koennen gespeichert werden, verbindungen zu mehreren servern moeglich (lokal oder zum hoster) und hat keine probleme mit linux zeilenumbruechen usw. usf.