WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: StudioVerlag on October 09, 2009, 01:10:12 AM
-
Merkwürdiger Fehler bei einem Anwender
[[ModifiedWhen]] zentral im Footer. Funktioniert auf allen Seiten, bis auf die, wo Form eingesetzt wird. Dann ist nämlich nur [[ModifiedWhen]] zu sehen, während es auf allen anderen Seiten weiterhin ordnungsgemäß funktioniert.
Kann das jemand verifizieren?
Auch nach einem Templatewechsel zeigte sich weiterhin dieser Fehler. Lokal auf Portable ist alles ok.
Gruß, Hans>NUL
-
Jap das ist bekannt und auch schon in bearbeiteung. Es scheint ein Problem mit Form und Dropplets zu geben. Warum der Portable allerdings funktioniert wäre gut zu wissen. Ich konnte den Fehler heute nur soweit nachbasteln das es nicht funktionierte. Bin leider kein Coder und kann deswegen nichts zur Lösung beitragen.
Bis denne dann Moritz
-
wollte den fehler eben auf einer 2.7er nachbasteln, aber es gab kein problem mit dem droplet im footer + form.
"This page was last modified on 09/10/2009 at 07:57."
hab ich bestimmt irgendwas falsch gemacht. :-)
dbs
-
Hi,
auf Seiten auf denen eine Form eingesetzt wird, wird der PHP Ausgabebuffer (view.php des Moduls) beendet. Dies war ein "Workaround", um bei eingeschaltetem E-Mail Outputfilter keine Umwandlung von E-Mail Adressen z.B. test@blubb.de --> test(at)bludd(dot).de durchzuführen.
Folge: E-Mail Adressen und Droplets (oder generell Module welche den Outputfilter nutzen) kommen ins straucheln (setzt voraus, Output Filter ist aktiv und auf der Seite ist eine Form und ne weitere Sektion).
Kurz nach Veröffentlichung von WB 2.7 wurden aber ein paar Regex in den Output Filter eingebaut, um die E-Mailfilterung in Formfeldern zu überspringen (soweit ich weiss). Wenn das in WB 2.8 noch so ist, könnte man im Form Modul (view.php) den ob_end_clean() Aufruf auskommentieren.
Doc
-
nach aktivierung des outputfilters kann ich das problem nun auch bestätigen. :-)
dbs
-
könnte man im Form Modul (view.php) den ob_end_clean() Aufruf auskommentieren.
Dann funktioniert das E-Mail Crypting in Form nicht mehr. Deswegen ist das damals so gemacht worden. In der index.php im Rootverzeichnis, so ungefähr Zeile 152 wird abgefragt, ob der Buffer noch Inhalt hat, und dann erst ein ob_clean angestossen. War bislang nicht und erzeugte eine FEhlermeldung, dass der Buffer leer ist.
Da ich mir das Formmodul ja nochmal vornehmen will, versuche ich das anders zu lösen. Nur es sollte schon die Möglichkeit bestehen die E-Mail gecrypted auszugeben.
Dietmar
-
Hi,
in der Datei view.php des Form Moduls (2.7 und 2.80 ) steht in Zeile 222 folgender Code:
/**
NOTE: comment out the line ob_end_flush() if you indicate problems (e.g. when using ob_start in the index.php of your template)
With ob_end_flush(): output filter will be disabled for this page (and all sections embedded on this page)
Without ob_end_flush(): emails are rewritten (e.g. name@domain.com --> name(at)domain(dot)com) if output filter is enabled
All replacements made by the Output-Filter module will be reverted before the email is send out
*/
if($filter_settings['email_filter'] && !($filter_settings['at_replacement']=='@' && $filter_settings['dot_replacement']=='.')) {
ob_end_flush();
}
Dieser kann zu Testzwecken ausgeschaltet werden, dann sollten E-Mails verschlüsselt angezeigt werden und auch Droplets funktionieren, auf deren Seite ein Form Modul untergebracht ist.
Kurz nach Veröffentlichung von WB 2.7 hatte ich eine modifizierte Regex für den Output Filter gepostet. Diese hatte nur Auswirkung auf E-Mailadressen, welche nicht in Form Elementen (<input> Feldern etc.) stehen. Wenn diese modifizierte Regex (Output Filter) in WB 2.8 eingeflossen ist, kann man die Zeile ob_end_flush() in der view.php des Form Moduls mittels voranstellen von // auskommentieren. Dann sollte eigentlich alles richtig funktionieren. Änderungen betreffen nur die view.php des Form-Moduls, nicht die des Output Filters.
Gruss Doc
-
Hallo
Ok ... jetzt kann ich es endlich auch bestätigen ... wenn frontendfilter aktiviert schepperts mit den droplets,
ansonsten funktionert es -- wenn man die Zeile auskommentiert schlägt die Validierung (Zeile 346 in der view.php) in class.wb.php Zeile 263 zu ...
hm ... ok "ob_end_flush" auskommentieren und ab Zeile 346 in der "view.php" den Block abändern in:
<?php
if($field['type'] == 'email' AND $admin->validate_email($_POST['field'.$field['field_id']]) == false) {
$_POST['field'.$field['field_id']] = str_replace( array ("(at)", "(dot)"), array ("@", "."), $_POST['field'.$field['field_id']] );
if ($admin->validate_email($_POST['field'.$field['field_id']]) == false )
$email_error = $MESSAGE['USERS']['INVALID_EMAIL'];
}
?>
Sprich ... doppelte Prüfung ... dann klappts auch mit den Droplets ... und den Frontendoutputfilte rs
Nur so'n vorschlag ... hier zumindest klappt das mit der #1153 ...
Edit: Sorry, Doc ... haben wir beide gleichzeitig? ...
Gruß
Aldus
-
Werde ich austesten. Meine Feststellungen waren noch bevor die 2.8 final rauskam. Werde mich auch mit Docs Post auseinander setzen. Ich weiss nur, wo ich bei der Entwicklung von 2.8 das in der view.php auskommentiert hatte, wurden die E-Mails nicht gecrypted. Aber inwzwischen ist ja viel passiert.
Also nochmal testen
Dietmar