TinyMCE 2.9.9: geändertes Verhalten p/br

faglork · 05. Juli 2012 16:35

Servus!

FYI:

in der neuen Version werden standardmäßig beim Drücken der ENTER-Taste nicht wie bisher P eingefügt sondern BR.
Siehe: http://www.tinymce.com/forum/viewtopic.php?id=28724

Um das normale Verhalten zu bekommen, *muss* unter "Erweiterte Eigenschaften" das Häkchen bei "Absatz erzwingen:" gesetzt werden.

Leider ergibt (und ergab übrigens schon immer - ist anscheinend niemanden aufgefallen, auch mir nicht) das invalides HTML im Falle von

Hier klicken, um den Code zum Kopieren zu markieren

[== html ==]
<p>{irgendeintag}</p>

Sieht jemand da eine Lösung?

Ich bin kein Smarty-Experte, aber könnte man da nicht sowas wie ein prefilter.freeTag.php schreiben welches die P-Umklammerung vom {tag} entfernt?

Servus,
Alex

Beitrag geändert von faglork (05. Juli 2012 17:23)

spike · 05. Juli 2012 19:16

Für <p> und <br /> wie gehabt - folgendes:

TinyMCE/Advanced/Extra Configuration Fenster:

forced_root_block:true

siehe mein thread beim .org Forum
für dein annere Problem null Ahnung.

gruss - spike

Beitrag geändert von spike (05. Juli 2012 19:18)

mike-r · 06. Juli 2012 22:35

faglork schrieb:

Ich bin kein Smarty-Experte, aber könnte man da nicht sowas wie ein prefilter.freeTag.php schreiben welches die P-Umklammerung vom {tag} entfernt?

das Thema hatten wir hier (und drüben glaube auch) schon einige Male, finde nur gerade keinen Thread dazu.
Mein Kenntnis-Stand ist der, dass es keine vernünftige Lösung gibt dafür.

nicmare · 06. Juli 2012 10:36

als notlösung hatte ich mal sowas vorgeschlagen:

Hier klicken, um den Code zum Kopieren zu markieren

{content assign="content"}
{$content|strip|replace:"> <":"><"|replace:"<p><div":"<div"|replace:"</div></p>":"</div>"}

Funktioniert in den meistens Fällen gut.

faglork · 06. Juli 2012 11:47

Könnt ihr das bitte mal testen:

prefilter.freetags.php

Hier klicken, um den Code zum Kopieren zu markieren

[== php ==]
<?php function smarty_cms_prefilter_freetag($tpl_source, &$smarty) 
{ 
return preg_replace('/<p>(\{[A-Za-z0-9\\._-]+\})<\/p>/', "$1", $tpl_source); 
} 
?>

Bisher funzt das, aber da das Teil ja auch im Backend arbeitet müsste man erstmal testen ob das dort keine negativen Auswirkungen hat. Ich habe bisher nix gefunden.

Calguy hat Einwände, in seiner unnachamlichen freundlichen Art:
http://forum.cmsmadesimple.org/viewtopi … 74#p281973

Servus,
Alex

Beitrag geändert von faglork (06. Juli 2012 16:07)

nockenfell · 06. Juli 2012 19:34

Scheint zu funktionieren. Bisher habe ich noch keine Probleme festgestellt, werde im Frontend noch im Backend.

faglork · 07. Juli 2012 12:17

nockenfell schrieb:

Scheint zu funktionieren. Bisher habe ich noch keine Probleme festgestellt, werde im Frontend noch im Backend.

Danke für das Feedback. Mich würde ja sehr interessieren warum CG "tonnes" von Problemen sieht. Mag ja sein, dass es da irgendeinen Mechanismus (wohl eher im Backend) gibt der damit kollidiert. Irgedwas scheint da ja zu sein. Oder er irrt, was ja auch nicht unmöglich wäre wink

Servus,
Alex

NaN · 07. Juli 2012 14:12

Ich vermute mal das Hauptproblem ist dieses Pattern:

Hier klicken, um den Code zum Kopieren zu markieren

[A-Za-z0-9\\._-]+

Nur Buchstaben, Zahlen, Unterstriche, Minus und ... keine Anführngszeichen, keine Kommas, keine Dollarzeichen (für Variablen), keine Klammern, keine Leerzeichen, kein =, keine Backticks ...
Kurz: Ein Modulaufruf kann durchaus komplexer sein als einfach nur

Hier klicken, um den Code zum Kopieren zu markieren

{module_name}

Z.B.

Hier klicken, um den Code zum Kopieren zu markieren

{module_name param="foo"|cat:'bar' param2=$foo->bar param3=$foo.bar ... }

Ich kann mir nicht vorstellen, dass das wirklich problemlos funktioniert.
Ich glaube nicht, dass dieses Pattern tatsächlich alle möglichen Modulaufrufe finden kann.

Ich hätte es evtl. so gemacht:

Hier klicken, um den Code zum Kopieren zu markieren

/<p>(\{[^}]+\})<\/p>/i

(Ich habe allerdings beides nicht getestet)

Mal ganz davon abgesehen, dass man im WYSIWYG Editor überhaupt nicht alle Zeichen verwenden kann. Aber CG denkt gerne mal etwas "globaler".

faglork · 07. Juli 2012 15:21

NaN schrieb:

Ich vermute mal das Hauptproblem ist dieses Pattern:
Hier klicken, um den Code zum Kopieren zu markieren
[A-Za-z0-9\\._-]+
Nur Buchstaben, Zahlen, Unterstriche, Minus und ... keine Anführngszeichen, keine Kommas, keine Dollarzeichen (für Variablen), keine Klammern, keine Leerzeichen, kein =, keine Backticks ...
Kurz: Ein Modulaufruf kann durchaus komplexer sein als einfach nur
Hier klicken, um den Code zum Kopieren zu markieren
{module_name}
Z.B.
Hier klicken, um den Code zum Kopieren zu markieren
{module_name param="foo"|cat:'bar' param2=$foo->bar param3=$foo.bar ... }
Ich kann mir nicht vorstellen, dass das wirklich problemlos funktioniert.
Ich glaube nicht, dass dieses Pattern tatsächlich alle möglichen Modulaufrufe finden kann.

Na wenn das das einzige problem ist ...

NaN schrieb:

Ich hätte es evtl. so gemacht:
Hier klicken, um den Code zum Kopieren zu markieren
/<p>(\{[^}]+\})<\/p>/i
(Ich habe allerdings beides nicht getestet)

Danke! Aber das matcht nicht mal einfache Aufrufe.

Kann man übrigens hier sehr schön testen:
http://regexpal.com/

NaN schrieb:

Mal ganz davon abgesehen, dass man im WYSIWYG Editor überhaupt nicht alle Zeichen verwenden kann. Aber CG denkt gerne mal etwas "globaler".

Das alles sehe ich NICHT als Problem. Ein "wirkliches" Problem wäre es z.b. - wie mir in der Testphase passiert ist - dass Modulaufrufe im Backend ausgefiltert werden. Und damit Module unbrauchbar. Oder sowas in der Art.

Sieht jemand eine Möglichkeit, die Filterung explizit auf das Frontend zu beschränken?

Servus,
Alex

faglork · 07. Juli 2012 15:34

Habs grad mit (\{[\S\s]+\}) gestestet - regexmäßig ist das ok, funzt mit dem von NaN oben angegebenen Beispiel-Modulaufruf. Das dürfte so ziemlich fast alles abdecken - siehe untenstehende Beschreibung der Parameter.

Dann in das Plugin eingebaut - alles läuft.

Zu was Self_html nicht alles gut ist:
\s /\s/ findet jede Art von Weißraum-Zeichen ("Whitespace"), also \f, \n, \t, \v und das Leerzeichen.
\S /\S+/ findet ein beliebiges einzelnes Zeichen, das kein "Whitespace" ist, also kein \f\n\t\v und kein Leerzeichen.
http://de.selfhtml.org/javascript/objekte/regexp.htm

Der aktuelle Code lautet jetzt:

Hier klicken, um den Code zum Kopieren zu markieren

[== php ==]
<?php function smarty_cms_prefilter_freetag($tpl_source, &$smarty)
 { 
return preg_replace('/<p>(\{[\S\s]+\})<\/p>/', "$1", $tpl_source);
 } 
?>

Man kann das Filter übrigens - falls es mal nötig sein sollte - einfach umgehen, indem man dem Modulaufruf ein Leerzeichen folgen lässt.

Eine Bitte an alle: falls Ihr ein Testsystem zur Verfügung habt, bitte testen. Auf ne Live-Installation würde ich das noch nicht loslassen.

Und: falls jemandem ein *grundsätzliches* Problem in diesem Zusammenhang auffällt, seid so nett und sagt es. Nicht wie dieser Idi von CG.

Servus,
Alex

Beitrag geändert von faglork (07. Juli 2012 15:54)

nockenfell · 07. Juli 2012 21:16

Ein Problem könnte das noch haben:

Ich habe den Code mit http://gskinner.com/RegExr/ getestet. Wenn ich nun im Text folgendes Teste:

Hier klicken, um den Code zum Kopieren zu markieren

<p>{News meier=1 test="Hallo{}" asdtedad}</p>

* real time results: shows results as you type 
* code hinting: roll over your expression to see info on specific elements 
* detailed results: roll over a match to see details & view group info below 
* built in regex guide: double click entries to insert them into your expression 
<p>Test</p>

<p>{News}</p>

markiert er als gefunden den kompletten Text zwischen den 2 Funktionsaufrufen. Somit wird der eigentliche Funktionsaufruf nicht genügend abgesichert kontrolliert.

NaN · 08. Juli 2012 01:09

Das liegt daran:

S /\S+/ findet ein beliebiges einzelnes Zeichen, das kein "Whitespace" ist,

Also findet es auch Geschweifte Klammern.
Daher muss man eben sagen, dass Geschweifte Klammern ausgeschlossen werden sollen:
[^}]+
oder
[^\}]+
Ich hab mein Beispiel sowohl mit gskinners RegExr als auch mit regexpal getestet.
Funktioniert.

Forum für CMS/made simple

#1 05. Juli 2012 16:35

TinyMCE 2.9.9: geändertes Verhalten p/br

#2 05. Juli 2012 19:16

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#3 06. Juli 2012 22:35

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#4 06. Juli 2012 10:36

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#5 06. Juli 2012 11:47

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#6 06. Juli 2012 19:34

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#7 07. Juli 2012 12:17

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#8 07. Juli 2012 14:12

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#9 07. Juli 2012 15:21

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#10 07. Juli 2012 15:34

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#11 07. Juli 2012 21:16

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

#12 08. Juli 2012 01:09

Re: TinyMCE 2.9.9: geändertes Verhalten p/br

Fußzeile des Forums