Suche dringend PHP-Script zur Konvertierung aller Zeilenumbrüche in <p> und <br />
Eingetragen von DrupalFan (1646)am 02.03.2010 - 22:22 Uhr in
Für zumindest 2 Inhaltstypen - Artikel und Blogs - möchte ich alle in der Datenbank gespeicherten Zeilenümbrüche (also \n und \n\n etc) umwandeln in <br /> und <p>.
Dies könnte man nun machen, in dem man direkt über die Datenbankfelder fährt und entsprechende Ersetzungen macht.
Oder man könnte dies als eine Art Filter machen, so dass die Datenbank nicht verändert wird aber bei der Ausgabe in Drupal noch vor der Übermittlung an den Richtext-Editor alle Zeilenumbrüche in korrekte HTML umgewandelt werden.
Wie und an welcher Stelle in Drupal kann ich so einen Filter einbauen? Es geht um die Ausgabe der Inhalte, also kein Eingabeformat, sondern eben bei der Ausgabe. Ausgangspunkt ist, es gibt viele importierte Inhalte oder Inhalte, die mit normalen Filtered HTML und Zeilenumbruchskonverter erstellt wurden, also nur Text und echte \n enthalten.
Da aber FCKEditor und TinyMCE damit nichts anfangen können, will ich bereits in PHP (auf keinen Fall in JavaScript, da hatte ich schon genug Probleme mit den Richttext-Editoren) umwandeln und korrekt in HTML ausgeben an den Richttext-Editor.
Wo kann ich diesen Filter einbauen in Drupal und wie könnte der Code dafür lauten?
Danke.
- Anmelden oder Registrieren um Kommentare zu schreiben
einfach Dir ne Funktion
am 02.03.2010 - 22:29 Uhr
einfach Dir ne Funktion bauen, welche dir die dinger austauscht und via hook_form_alter() übergeben.
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.
Code?
am 02.03.2010 - 23:03 Uhr
Code?
Kann man mit hook_form_alter nur das Formular oder auch den Inhalt, welcher im Formular zum Bearbeiten rein geladen wird, verändern? Wie verändert man den Inhalt?
Suche dringend eine Lösung.
am 02.03.2010 - 23:19 Uhr
Suche dringend eine Lösung. Vielen Dank für jeden Tipp!
Ein- oder Ausgabeformat. Das ist hier die Frage.
am 02.03.2010 - 23:38 Uhr
Es geht um die Ausgabe der Inhalte, also kein Eingabeformat, sondern eben bei der Ausgabe
Ein weit verbreiteter Irrtum ist es zu glauben, dass es sich bei Drupals Eingabeformaten um Formate fuer die Eingabe handelt.
Im Gegenteil. Es handelt sich um Formate fuer die Anzeige - also um Ausgabeformate.
Es gibt auf drupal.org Diskusionen dieses Verwirrspiel zu aendern. Ob es in D7 weiter existiert wird man bei D7 Final wissen.
Deswegen ist es voellig irritierend bei extra zu erstellenden Formaten fuer die Anzeige von Inhalten von Eingabeformaten zu sprechen. Das in diesem Zusammenhang zu empfehlende Modul Custom Filter spricht salomonisch von Inhaltsfiltern.
In der Moduldoku allerdings ist von Salomon nix mehr zu sehen und man irritiert mit "Input filter".
Da geht noch was.
Filter für \n nach <br /> und \n\n nach <p>
am 02.03.2010 - 23:37 Uhr
Danke für diese Info.
Stimmt dass, dass ich dann einen Filter (Eingabefilter) benötige, der
\n und \n\nin
<br /> und <p>
umwandelt? Die Umwandlung muss stattfinden, bevor die Inhalte an den Richtext-Editor (beim BEARBEITEN, darum geht es) übergeben wird.
So einen Filter gibt es anscheinend noch nicht, vielleicht ähnliche aber nicht diesen. Und wie kann ich so einen Filter bauen und aktivieren? Danke.
Was genau ist eigentlich das
am 02.03.2010 - 23:50 Uhr
Was genau ist eigentlich das Problem mit den Editoren?
Ein Custom Filter wird nix bringen da er wie gesagt erst bei der Anzeige filtert - die DB nimmt allen Muell auf den man eingibt um ihn erst bei der Anzeige zu bereinigen (Drupals Philosophie). Und Code aus der DB im Editor ist eben mal nicht bei der Anzeige einer Node.
Es ist schon eine ganze Weile her das ich mit dem Custom Filter Modul geaerbeitet habe. Eventuell bereinigt so ein Custom Filter in der aktuellen Modulversion ja wirklich bevor in der DB gespeichert wird. Aber das glaube ich nicht, denn so viel Andersartigkeit im Sinne Drupals Philosophie traue ich dem Modulmaintainer nicht zu.
Edit
Bevor Du mit Custom Filtern rumfummelst. Hast Du schon mit der Moeglichkeit der Umordnung der einzelnen Filter in einem Eingabeformat probiert Dein Problem in den Griff zu kriegen? Guckst Du in admin/settings/filters
Da geht noch was.
Problem ist massiv
am 02.03.2010 - 23:57 Uhr
Von dem Problem hast Du gerade vorher gelesen:
http://www.drupalcenter.de/node/25671
Custom Filter kenn ich noch nicht, aber ich brauche NUR ein Filter, welches dann ansetzt, wenn von der Datenbank ausgelesen wird und bevor(!) es im Textfeld des Textkörpers oder in diesem Fall im WYSIWYG-Editor zur Bearbeitung angezeigt wird. Und sonst soll das Filter rein gar nichts tun.
Sprich: Dann würde endlich der FCK-Editor und der TinyMCE die abgespeicherten Node OHNE VERLUST DER ZEILENUMBRÜCHE die Inhalte beim Editieren korrekt darstellen und man könnte, nach dem Editieren, das auch wieder speichern, und ein weiteres Mal editieren usw. All das geht derzeit nicht und dieses Problem macht die Benutzung von Richtext-Editoren in Drupal dzt vollkommen unbrauchbar (wenn man wie in vielen Fällen bereits bestehenden Inhalt oder importierten Inhalt oder mit Full/Filtered HTML erstellten Inhalt im Richtext bearbeiten muss).
Hier im Forum oeffne ich des
am 03.03.2010 - 00:03 Uhr
Hier im Forum oeffne ich des oefteren erstellte Threads oder Kommentare zum Bearbeiten um meine Tippfehler zu korrigieren. Aber ein Problem mit dem Editor beim erneuten Speichern konnte ich dabei noch nie feststellen. Eigentlich auch sonst nicht.
Da geht noch was.
Es gibt so viele Fälle, wo das ein Problem ist
am 03.03.2010 - 00:31 Uhr
http://drupal.org/node/513998
http://drupal.org/node/575626
http://drupal.org/node/730634
http://drupal.org/node/730542
http://www.drupalcenter.de/node/25671
WENN eiin Node zuvor(!) mit Filtered HTML erstellt wurde, dann sind in der DB \n und \n\n für die Zeilenumbrüche gespeichert. Und das ist in vielen Fällen der Fall!
- Beim Importieren von Inhalten (alter Content übernehmen bei neuem Projekt),
- wenn reg. User Inhalte mit Filtered HTML erstellen, Redakteure Inhalte aber mit TinyMCE bearbeiten
- wenn auf einer Drupalseite schon hunderte Inhalte existieren und danach ein Tiny oder FCK-Editor aktiviert wird um diese vorhandenen Nodes zu bearbeiten
- usw, es gibt sehr viele Fälle.
Das Probem müsste jetzt wirklich klar sein, dass es hier bei Dir beim Editieren von Artikeln nicht auftritt, das weiß ich auch, trotzdem gibt es so viele Fälle, wo WYSIWYG in Drupal derzeit vollkommen unbrauchbar ist, nämlich in genau den genannten Fällen.
Um exakt das zu realisieren
am 03.03.2010 - 00:09 Uhr
Um exakt das zu realisieren was Dir gerade vorschwebt - Text der aus der DB kommt vor seiner Aufnahme im Editor filtern - musst Du Dir wohl ein eigenes Modul schreiben. Sorry das ich Dir nicht konkreter helfen kann.
Da geht noch was.
Wo ansetzen?
am 03.03.2010 - 00:14 Uhr
Das wär doch kein Problem, wenn man hier ein Modul schreiben muss, es geht doch um den Ansatz.
Wie setzt man an? Wo kommt man an den Inhalt des Textkörpers ran, bevor er ausgegeben wird in das Editor-Formular? Das ist doch die Frage. Ob das ein Modul wird oder nur ein kurzes htmlentities() oder nl2br() oder htmlspecialchars() in einer node.tpl.php oder ähnlich wär egal, es ist wichtig, jetzt herauszufinden, an welcher Stelle in Drupal man hier ansetzen kann.
Zitat: dann sind in der DB \n
am 03.03.2010 - 00:19 Uhr
Die doppelten \n\n existieren weil sie so eingeben wurden! Eventuell hat genau dies aber der Redakteur eines Beitrage mit Absicht gemacht um Dich zu aergern. Sorry, will sagen weil er damit seinen Beitrag formatieren will.
Entweder Du willst an der Stelle Polizei spielen und die Redakteure bevormunden in dem Du stillschweigend derartige Mehrfach \n beseitigst oder Du sagst ihnen das sie so etwas boeses nicht machen sollen.
EDIT
Ich wollte in diesem Kommentar hier boese sein und deswegen habe ich mehrere \n hintereinander eingetippt. Und zwar zwischen "... formatiern will." und "Entweder Du willst ..."
Der hier verwendete BuEditor steckt dies ohne Probleme weg. Egal ob mit Filtered - oder Full HTML.
Da geht noch was.
???????????????? Die \n\n und
am 03.03.2010 - 00:18 Uhr
????????????????
Die \n\n und \n sind doch okay. Niemanden stören die, die sind doch Folge des Zeilenumbruchskonverters (aktiviert in Full HTML, Filterted HTML, usw).
Es geht doch darum, dass all die WYSIWYG-Editoren mit den \n nichts anfangen können. Darum geht es doch. Die Richtext-Editoren verstehen doch nur html und verlieren daher alle Zeilenumbrüche.
Alle suchen nach einer Lösung
am 03.03.2010 - 00:21 Uhr
http://drupal.org/node/513998 ist ein Ansatz, das zu lösen, aber der funktioniert in vielen Fällen nicht!
Daher hier oben die Frage nach dem umgekehrten Ansatz das zu lösen und Richtext für Drupal endlich verwendbar zu machen (für Beiträge, die zuvor ohne Richtext-Editor gespeichert wurden, usw usw wie schon mehrmals erwähnt).
Na dann haben wir uns
am 03.03.2010 - 00:21 Uhr
Na dann haben wir uns missverstanden.
Du willst die Zeilenumbrueche erhalten. Dann vergiss von mir voran geschriebenes.
Da geht noch was.
Zeilenumbrüche-Problem
am 03.03.2010 - 00:23 Uhr
einfach Dir ne Funktion bauen, welche dir die dinger austauscht und via hook_form_alter() übergeben.
Kannst Du bitte deine Aussage präziseren?
Geht es nun mit dieser Idee von Dir oder geht es nicht? Ich will nicht das Formular ändern, ich will das Problem der Zeilenumbrüche lösen.
Drupal-Zeilenumbrüche mit WYSIWYG-Editoren endlich kompatibel ma
am 03.03.2010 - 00:27 Uhr
Na dann haben wir uns missverstanden.
Du willst die Zeilenumbrueche erhalten. Dann vergiss von mir voran geschriebenes.
Ja, ich will, dass diese Zeilenumbrüche, die wie bei jedem ganz stinknormalen Drupal als \n und \n\n in der Datenbank abgespeichert wurden, im FCK und TinyMCE nicht verschwinden sondern dort erhalten bleiben, dazu muss man sie vor dem Laden in FCK und Tiny in
<br /> und <p>umwandelen.Und hier geht es darum, wie man das Umwandeln programmieren kann (welche Funktion, wo einbauen, wo kommt man ran an den Textkörper bevor er ins Edit-Feld / Richtext-Editor geladen wird??).
Meine Lösung
am 17.03.2010 - 21:01 Uhr
So schaut meine Lösung nun aus:
function _filter_autop($text) {
// All block level tags
$block = '(?:table|thead|tfoot|caption|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|blockquote|address|p|h[1-6]|hr)';
// Split at <pre>, <script>, <style> and </pre>, </script>, </style> tags.
// We don't apply any processing to the contents of these tags to avoid messing
// up code. We look for matched pairs and allow basic nesting. For example:
// "processed <pre> ignored <script> ignored </script> ignored </pre> processed"
$chunks = preg_split('@(</?(?:pre|script|style|object)[^>]*>)@i', $text, -1, PREG_SPLIT_DELIM_CAPTURE);
// Note: PHP ensures the array consists of alternating delimiters and literals
// and begins and ends with a literal (inserting NULL as required).
$ignore = FALSE;
$ignoretag = '';
$output = '';
foreach ($chunks as $i => $chunk) {
if ($i % 2) {
// Opening or closing tag?
$open = ($chunk[1] != '/');
list($tag) = split('[ >]', substr($chunk, 2 - $open), 2);
if (!$ignore) {
if ($open) {
$ignore = TRUE;
$ignoretag = $tag;
}
}
// Only allow a matching tag to close it.
else if (!$open && $ignoretag == $tag) {
$ignore = FALSE;
$ignoretag = '';
}
}
else if (!$ignore) {
$chunk = preg_replace('|\n*$|', '', $chunk) ."\n\n"; // just to make things a little easier, pad the end
$chunk = preg_replace('|<br />\s*<br />|', "\n\n", $chunk);
$chunk = preg_replace('!(<'. $block .'[^>]*>)!', "\n$1", $chunk); // Space things out a little
$chunk = preg_replace('!(</'. $block .'>)!', "$1\n\n", $chunk); // Space things out a little
$chunk = preg_replace("/\n\n+/", "\n\n", $chunk); // take care of duplicates
$chunk = preg_replace('/\n?(.+?)(?:\n\s*\n|\z)/s', "<p>$1</p>\n", $chunk); // make paragraphs, including one at the end
$chunk = preg_replace('|<p>\s*</p>\n|', '', $chunk); // under certain strange conditions it could create a P of entirely whitespace
$chunk = preg_replace("|<p>(<li.+?)</p>|", "$1", $chunk); // problem with nested lists
$chunk = preg_replace('|<p><blockquote([^>]*)>|i', "<blockquote$1><p>", $chunk);
$chunk = str_replace('</blockquote></p>', '</p></blockquote>', $chunk);
$chunk = preg_replace('!<p>\s*(</?'. $block .'[^>]*>)!', "$1", $chunk);
$chunk = preg_replace('!(</?'. $block .'[^>]*>)\s*</p>!', "$1", $chunk);
$chunk = preg_replace('|(?<!<br />)\s*\n|', "<br />\n", $chunk); // make line breaks
$chunk = preg_replace('!(</?'. $block .'[^>]*>)\s*<br />!', "$1", $chunk);
$chunk = preg_replace('!<br />(\s*</?(?:p|li|div|th|pre|td|ul|ol)>)!', '$1', $chunk);
$chunk = preg_replace('/&([^#])(?![A-Za-z0-9]{1,8};)/', '&$1', $chunk);
}
$output .= $chunk;
}
return $output;
}
Der neuste FCK-Editor bzw.
am 17.03.2010 - 21:25 Uhr
Der neuste FCK-Editor bzw. die Dev-Version hat so eine Funktion onboard, nur als Information.
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.
Nur Teillösung
am 17.03.2010 - 23:43 Uhr
Ja, habe ich auch schon gesehen und irgendwo geschrieben, dass es damit 2 Probleme gibt:
- Ich verwende den FCK-Editor jetzt nicht mehr, sondern TinyMCE als Standard
- eigentlich wäre es besser, wenn das im Modul WYSIWYG anstatt im FCK-Editor selbst drin wäre. Aber das ist Ansichtssache. So muss es in allen wysiwyg-Editoren eingebaut werden, auch TinyMCE ...
Und meine Lösung scheint mir aus diesem Grund besser zu sein. Denn ich kann jetzt, und das mache ich bei einem Inhaltstyp auch, zwischen TinyMCE und FCK-Editor hin und herschalten und alles funktioniert und ist kompatibel und alle Zeilenumbrüche bleiben immer erhalten. Das war ja das Ziel, bei mir ist es zu 100% erreicht.
Den FCK-Editor verwende ich nur, wenn Bilder auf den Server hochladen muss. Das ist nur in einem einzigen Fall nötig bei diesem Projekt: Dann wenn Imagecache aus manchen Bildern ganz unscharfe Bilder beim Verkleinern macht:
http://www.drupalcenter.de/node/25533
Sonst würde ich nur mehr TinyMCE zusammen mit WYSIWYG-Modul und das Modul Insert benutzen. Beides genial!