Kommentar via Custom beisst sich mit Spamschutz

[hagenroewer]

Moin zusammen,

gerade bei einem aktuellen Projekt fällt es mir wieder auf und ein:

Wenn Kontaktformular in der Custom-Variante mit der
Template-Datei plugin_dynamicform.tpl hergestellt wird,
beisst sich es sich unter Umständen mit bestimmten Optionen
im Spamschutzstöpsel.
Denn dort habe ich in den meisten Fällen in den Pflichtfeldern folgendes
eingetragen:
name,email,comment

Wenn diese aber dann nicht mehr als Felder durch andere Bezeichungen im
Formular nicht auftauchen, kommt es zu unschönen Fehlermeldungen wie
z.B.
Name, E-Mail und ihre Nachricht dürfen nicht leer gelassen werden.
Sie haben das Feld "name" nicht ausgefüllt!

D.h. als momentaner Workaround muss E-Mail als abzufragender Datensatz
zur E-Mail-Adresse immer als Email eingetragen werden.
Wenn man den Nachnamen abfragt, dann immer als Name abfragen.

Dann können die entsprechenden Pflichtfelder mitbedient werden,
und die Mail-Header werden dann auch wieder richtig gesetzt.

Andere Alternative wäre die Pflichtfelder leer zulassen,
dann wird aber bei den eigentlichen Kommentaren nichts mehr dazu abgefragt.

Bei der Standard-Einstellung ist das anders,
da ist in der deutschen Sprachdatei schon der entsprechende Wert
für EMAIL mit "E-Mail" richtig belegt, und wird entsprechend abgerufen.

Nur wenn ich das richtig interpretiere, wird beim plugin_dynamicform.tpl
der interne Feldname direkt aus dem eingegeben Feldnamen übernommen.
So kommt es dann dazu, dass aus E-Mail z.B. das interne Feld e_mail wird,
und nicht eben email.

Kann man das generell irgendwie beheben,
dass man die gewünschten Pflichtfelder nach außen hin anders benennen kann?

[garvinhicking]

Hi!

Richtig, das Problem lässt sich konzeptionell nur bekämpfen indem Du immer die gleichlautenden Formularfelder angibst. Wenn Du eine eigene .tpl nimmst könntest du immer direkt die felder die spamblock braucht als hidden-input field übermitteln...

Ich wüsste sonst nicht, wie man das anderes beheben könnte, als dass du selbst über übereinstimmende Feldnamen dich kümmern musst.

Grüße,
garvin

[hagenroewer]

Wenn Du eine eigene .tpl nimmst könntest du immer direkt die felder die spamblock braucht als hidden-input field übermitteln...

Ich wüsste sonst nicht, wie man das anderes beheben könnte, als dass du selbst über übereinstimmende Feldnamen dich kümmern musst.

Gut, das mit den hidden-input-fields hatte ich auch schon im Auge gehabt.

Eine Idee wäre, diese beiden Felder mit Werte aus den individuellen Felder zu versorgen, da muss ich noch mal weiter nachdenken. Mir schwebt dann vor, dass ich bei der Plugin-Konfiguration, dann einfach [email] und [name] dann sage im Custom-Bereich, von welchem Feld sie dann den Wert übernehmen sollen. Wie das so aussieht, muss dann die Konfiguration und die TPL-Datein dabei entsprechend angepasst werden.

[hagenroewer]

Moin,

ich hole nochmal den alten Thread hervor, da mir gerade bei den Sprachdateien was aufgefallen ist:

Eine Idee wäre, diese beiden Felder mit Werte aus den individuellen Felder zu versorgen, da muss ich noch mal weiter nachdenken. Mir schwebt dann vor, dass ich bei der Plugin-Konfiguration, dann einfach [email] und [name] dann sage im Custom-Bereich, von welchem Feld sie dann den Wert übernehmen sollen. Wie das so aussieht, muss dann die Konfiguration und die TPL-Datein dabei entsprechend angepasst werden.

Ich habe mir schon vor einiger Zeit via Smarty in dem entsprechenden Template (plugin_dynamicform.tpl) meine Lösung gebaut, die auch ganz gut klappt.

Nur fällt mir gerade auf, dass die Variable @define('NAME', 'Name'); aus den Sprachdateien nicht nur in den Formularen benutzt wird, sondern u.a. in der Pluginbeschreibung beim Aufruf des jeweils installierten Plugins.

Ich hatte für mich in der Datei serendipity_lang_de.inc.php zwischendurch von @define('NAME', 'Name'); nach @define('NAME', 'Vor- und Nachname'); - das sieht ein bißchen doof aus in den Pluginbeschreibungen aus.

Gruß,

Hagen Röwer