<p> im FCKEditor entfernen

[Superwilly]

Hallo,

ich habe eine sehr schmale(hohe) Zeile, in der nur eine Zeile über das CMS eingetragen werden soll. Der Editor von WB trägt aber automatisch immer einen   <p> und </p>  vor bzw. nach dem Text ein.

Dadurch wird immer die Zeile in der Höhe verändert, was ziemlich doof aussieht, da die Zeile nben anderen Hintergrund hat als der Rest.

Zur Zeit muss ich immer im FCKEditor auf "Queltext anzeigen" klicken und die <p> ´s von Hand entfernen und dann wieder speichern.

Zukünftig sollen das System aber unerfahrene User bedienen, denen ich nicht zumuten möchte das immer zu entfernen vorher.

Weiss jamand vielleicht wie ich diese <p> ´s irgendwie in der Voreinstellung wegbekomme, irgendwo aus ne Datei rausnehmen oder so?

THX

[dbs]

moin, wird schwierig bis unmöglich.

was du machen kannst ist das p tauschen gegen br:

Code:

modules > fckeditor > wb_config > wb_fckconfig.js mit Editor öffnen und

suchen nach der Zeile:

           FCKConfig.EnterMode             = 'p' ;        // allowed tags: p | div | br

dort 'p' raus und 'br' rein (tauschen mit ShiftEnterMode).

dbs

[Luisehahne]

Geht auch anders, Den Bereich markieren und dann statt normal auf normal div klicken, so wird der p tag mit einem div tag ausgetauscht. Ist für eingefügte Droplets ratsam

Dietmar

[Waldschwein]

Hallo!

Ich habe diese Probleme leider auch, aber das Problem ist eher, dass der FCKeditor sogar <p> einfügt, wenn man im Quellcode Modus arbeitet und den WYSIWYG Bereich gar nicht bedient...
Die Antwort von dbs stimmt natürlich - aber das ändert nur das <p> wenn der Benutzer "Enter" drückt.

Prinzipiell müsste man hier wohl nachträglich diese etwas unschöne Praktik verändern - aber ich weiß nur, dass dies mit etwas Fachwissen geht, und halt nicht immer.

Wenn man generell auf <p> verzichten möchte wäre es vielleicht sinnvoll, entweder einen ganzen Parser hintendranhängen oder mit dem PHP-Befehl str_replace an Ende des Templates über einen Array diesen anzuweisen, alles <p> in "nichts" und alles </p> in <br /> zu ändern. Allerdings weiß ich nicht wie das im Standard-WB-Templatesystem zu bewerkstelligen ist.
Jedenfalls in xft2 geht es nach dem Schema

Code:

<?php 
$page=str_replace(array
    (
    "p=\"br\""
    ),            "",
                  $page);
$xft2->remove_unusedMarkers($page);
$page=str_replace("\\", "", $page);
echo $page; ?>

Aber normal geht das nicht!!!

Aber da müsste ein Coder ran, das umzuschreiben... Oder gleich ein ganzes Parsermodul erstellen, z.B. mit meinem Gedanken von hier http://www.websitebaker2.org/forum/index.php/topic,16295.0.html

Gruß Michael

Edit: Ok, Dietmar hat Recht, so geht's einfacher...

[dbs]

wenn das mit dem div einfacher ist, dann eben nicht br in der wb_fckconfig.js eintragen sondern div womit das markieren&ändern entfällt..

aber das ist doch nicht die lösung, wer will schon alles voller div's haben.
dann lieber eine lösung von einem coder, wo erstmal nichts automatisch eingetragen wird im fck.
ein traum ...

dbs

[Luisehahne]

dann schreib mal bitte ins fck forum, mal schauen was du für eine Antwort bekommst. Lasst uns die Diskussion beenden. FCK ist ein 3rd party Produkt,

Dietmar

[dbs]

hab schon öfter gesucht nach einer lösung, auch im fck-forum. gibbet nich.
muss jeder für sich entscheiden wie er es handeln will.
markieren und normal div draus machen oder im quellcode was entfernen.

allerdings ist die variante mit br statt p im IE (oder firefox-addon IE-Tab) von vorteil, weil das br nicht automatisch eingefügt wird.

dbs

[instantflorian]

Ganz einfach stylen! Wenn de schmale Spalte irgend eine Klasse oder ID hat, bspw. "schmal", braucht man im Stylesheet doch nur zu notieren

#schmal p {
  margin:0;
padding:0;
}

[Luisehahne]

Ich frage mich nur, was es für einen Sinn machen soll, grundsätzlich ohne p tags zu arbeiten. Ich setze div immer dann ein, wenn es Validierungsproblem e gibt. Hmmmm

Dietmar

[dbs]

in manchen modulen zerhaut dir ein p die optik,
bei mir z.b. im eventcalendar.

dbs

[chio]

Was ist der Nterschied zwischen einem
p {margin 0;}
und einem div? Oder einem nicht-p?

Aber Groß von W3C und sonstwas daherreden...

[Luisehahne]

@Chio
das p tag bringt teilsweise Validierungsfehler, das meinte dbs

Dietmar

[chio]

Wenn <p> einen Validierungsfehler macht, ist das ein Fehler im Modul.
Dann machen auch <h1-6> oder sonstige Blockelemente Fehler. Wie wärs mit strip_tags() ?

[Waldschwein]

Wie wärs mit strip_tags() ?

Ich bin ja nach wie vor der Meinung, eine Schnittstelle wo man einen Parser wie z.B. HTMLpurifier andocken kann wäre das beste. Aber anscheinend bin ich da alleine auf weiter Flur... Wobei es ja für andere CMS solche Plugins im Core oder als Module in Massen gibt...

Gruß Michael

[Luisehahne]

@Chio
nein so ist das nicht, wenn du z.B. ein Droplet einfügst und FCK bettet das in p tags einbettet, sind je nach Lage des Droplets p tags nicht erlaubt

Dietmar

[DarkViper]

@Superwilly

wenn Du grundsätzlich immer die erste Zeile in WYSIWYG-Sections vom <p> befreien willst, hier ein kleiner Patch für die /modules/wysiwyg/save.php

Code:

<?php
// Update the mod_wysiwygs table with the contents
if(isset($_POST['content'.$section_id])) {
    $content = $_POST['content'.$section_id];
    $pattern = '/^<p.*>(.*)<\/p>/isU';

    $content = preg_replace( $pattern, '$1', $content);

    $content = $admin->add_slashes($content);
    // searching in $text will be much easier this way
?>

[Luisehahne]

Klar geht das, aber ich mache mir doch meine ganzen gewollten Abschnitte kaputt und sehe dann nur noch FLiesstext.

Dietmar

[DarkViper]

nein, das Statement wirkt sich, bedingt durch das Carret ^ nur auf den ersten Paragraphen der Section aus. Alle weiteren bleiben davon unberührt und schön formatiert.

[dbs]

(durch das p im betreff hier, taucht der thread nicht in meinem klipfolio auf)

der eröffner wollte p-tags entfernt haben, richtig?
ich würde auch gern selbst bestimmen wollen was da für tags eingefügt werden. darum ging es.

den hack hab ich ausprobiert an der letzten fck-version  und es funktioniert leider nicht. bringt fehlermeldungen wie :

Code:

Parse error: syntax error, unexpected T_REQUIRE in .../modules/wysiwyg/save.php on line 2

meldungen sind verschieden, je nachdem wie ich die leerzeilen verändere. komischerweise habe ich oft dateien wo automatisch leerzeilen nach jeder code-zeile eingefügt sind. (dietmar, ist das bei dir auch so?)

der hack war doch so gemeint?

Code:

// Update the mod_wysiwygs table with the contents
if(isset($_POST['content'.$section_id])) {
    $content = $_POST['content'.$section_id];
    $pattern = '/^<p.*>(.*)<\/p>/isU';
    $content = preg_replace( $pattern, '$1', $content);
    $content = $admin->add_slashes($content);
    // searching in $text will be much easier this way
    $text = umlauts_to_entities(strip_tags($content), strtoupper(DEFAULT_CHARSET), 0);
    $database = new database();
    $query = "UPDATE ".TABLE_PREFIX."mod_wysiwyg SET content = '$content', text = '$text' WHERE section_id = '$section_id'";
    $database->query($query);    
}

dbs

[Stefek]

Nur als Idee:
Könnte man dem FCK Editor nicht "beibringen", dass er keine p's oder div's setzt, wenn er auf ein [[droplet]] stößt?

Neben Droplets, die sich auf diese Art umgeben schlecht auf das Template und Validierung auswirken, gibt es ja bekanntlich auch Droplets, die gar nicht an der Stelle, wo sie eingefügt wurden etwas ausgeben, sondern nur dazu gedacht sind, den Output zu filtern.

Gruß,
Stefek

[Waldschwein]

Natürlich geht das. Und wie gesagt: Spielt doch mal damit http://htmlpurifier.org/demo.php herum, es ist ja nicht umsonst mittlerweile in jedem größeren CMS-Module-Park zu finden, zudem unter LGPL.

Gruß Michael

Edit: Auf deren TODO-Liste steht:

Code:

Ongoing
[...]
 - Plugins for major CMSes (COMPLEX)
    - phpBB
    - Drupal needs loving!
    - Phorum need loving!
    - more! (look for ones that use WYSIWYGs)
[...]

Wenn sie das schon wollen, kann man sie ja mal drum bitten.