Plug-in: zem_contact_reborn

thebombsite · 2006-10-30 20:15:49

That looks rather good Steve. I look forward to trying it out. :)

rohner · 2006-11-13 01:45:48

I just installed the latest version of the original zem_contact and discovered during testing that quotations and ampersands are written as " and & in the message of the email that is sent instead of “ and &. I have searched in this forum and on the net for a fix this with no luck. (I am not a PHP guru – only HTML and CSS). Does anyone know of a fix for this?

For example, if I type the following into the textarea field of the form:

You must read the book called “Great Expectations.”

I get this in the body of the email when it is delivered:

You must read the book called "Great Expectations."

I hope someone can help with this. Thank you!

I posted here and in the zem_contact plugin thread for help because I wanted to know if I should just delete zem_contact and use zem_contact_reborn instead – if it fixes this problem. Or does this problem also exist in zem_contact_reborn?

jstubbs · 2006-11-13 02:43:13

I think it happens with both versions of the plugin. It does come out like that with zem_contact_reborn.

Stuart, any idea if/when the foreign characters in drop down select boxes will be fixed in a future version of reborn? And the problem with the resulting emails as mentioned above by Rohner? Same thing happens with all foreign characters, resulting in complaints from clients who find it difficult to read their emails.

ruud · 2006-11-13 08:57:26

@rohner, I’m working on a new version (available for testing this week) which already includes a fix for this html escaping bug.

@jstubbs, can you give a detailed example/description the problem you have with foreign characters you have. I’d like to fix that.

Might as well post a list of bugs in the current version that should be fixed in the next one

text in the body of emails is no longer html-escaped, which matches the content type used (text/plain).
nonce-based anti-spam measure works now and also has better prevention of duplicate form submission.
to_form was parsed before the zem_contact form, making it impossible to let to_form base its output on anything entered by a visitor. By switching them around, you should be able to let the To address depend on something entered on the form (using it to select between pre-defined email addresses for example).
checking of the email address domain part would fail if checkmxrr wasn’t available and the domain itself didn’t have an A record (only an MX record). Fixed by either checking both or not checking at all. The MX check doesn’t work on windows hosts.
checkbox state is now remembered correctly if the form is displayed again upon error
subject is now properly mime-encoded if non-ascii characters were used.
separating showerrors and showinput should work now (fix taken from the development version by stuart/tranquillo)
zem_contact_submit tag can now also be a container tag, in which case it will automatically use the button element instead of an input element. This enables you to use any txp image tag inside the container.
selected attribute in select tag is now valid xhtml
use label of the radio tag in the email message instead (works better for non-usascii characters).
select tag now remembers previous input upon errors, even if it contains < > “ & characters
select tag strips newlines, carriage returns and tabs from the list attribute.
ignore ‘default’ when submitting a form (‘default’ is only used when displaying a new form).
reject invalid UTF-8 input
UTF-8 aware min/max checking (max check now gives error instead of truncating input)
automatic generation of name/id based on labels works now even if the labels don’t contain any us-ascii characters (i.e. Japanese).
multiple forms on a page are possible, even when using separate error and input parts.
more…

Last edited by ruud (2006-11-16 23:09:14)

jstubbs · 2006-11-13 13:36:48

Hi Ruud, my first post on this subject was a year ago here

That post got a bit mangled, so I will explain it again briefly. There are 2 issues:

1. When using a select drop down box, if one of the words includes a foreign character, the form sometimes fails. If I change (which I have done) the foreign character to the HTML entity instead, then the form works

2. The resulting email sent by the form includes the HTML entities, which makes the email difficult to read

Hope that explains it! Thanks.

If you are creating/updating this plugin, can we start a new thread for it?

Also, it may be a good idea from a user perspective to remove the article send portion of zem_contact_reborn – I would think for most people just the form working well is enough. Just a thought.

wet · 2006-11-13 13:44:51

Ah, it’s christmas time…

My two major suggestions for zem_contact I wanted to throw in the ring are:

Get rid of the single instance data store ($zem_contact_form[]) and allow more than one form per URL.
Using the value of label (which is the default behaviour) as a name for the sent data items fails for int’l non-ASCII labels, so a little dumbDown() would be nice. Or even a more robust way of naming the form elements caring for longish label texts.

ruud · 2006-11-13 14:29:49

wet:
More than one form per URL can probably be done by doing an md5sum of the zem_contact attributes (excluding showerror and showinput) and $thing. If that md5sum is sent in a hidden field, it should be easy to check which form was used. Doesn’t even require an extra attribute. It just works ;)

What do you propose we use instead of $zem_contact_form[]? Having all form data available in a global variable makes it easy for other plugins to make use of it.

The label-to-name conversion already removes invalid characters. If the name is nothing but invalid characters, I’m using a base64 encoded label which is a valid name (if trailing = are removed).

Last edited by ruud (2006-11-13 14:41:54)

ruud · 2006-11-13 14:39:37

jstubbs:

1. When using a select drop down box, if one of the words includes a foreign character, the form sometimes fails. If I change (which I have done) the foreign character to the HTML entity instead, then the form works

How does the form fail. Does it give an error. or something else?
You say it fails sometimes. Is there a difference between the times when it fails and when it doesn’t. Does that depend on what you enter in the form or do you get different results (works / fails) with the same form input?
Does this happen in specific browsers?
Can you provide an example form that shows this faulty behaviour? (feel free to email me)

Last edited by ruud (2006-11-13 14:44:05)

wet · 2006-11-13 18:26:26

ruud wrote:

What do you propose we use instead of $zem_contact_form[]?

Though I’m not sure if I understand your question properly I’ll try to explain what bothers me: I think this global var inhibits the use of more than one form per URL, as it will mix all form elements in all forms used on one single page into one big global array. This will be confusing for the mail recipients.

A thought: Make $zem_contact a multidimensional array with one dimension being a human-readable “form identifier” (md5 won’t fit as it means nothing for an e-mail recipient). This form identifier is passed to zem_contact as an attribute value and defaults to a reasonable default for pages with just one form. On pages with more than one form its up to the user to differentiate the various forms:

<txp:zem_contact formid="subscribe-newsletter">[... form elements ...]</txp:zem_contact>[...]
<txp:zem_contact formid="order-message">[... form elements...]</txp:zem_contact>

Am I getting through?

Last edited by wet (2006-11-13 18:26:44)

jstubbs · 2006-11-14 02:56:20

Ruud,

Will get an example up for you later today. Would you like a form setup on one of my sites, or shall I send you a form in text file for you to use on your own install?

ruud · 2006-11-14 07:47:17

jstubs: send it in email. That’s easier for me to test without flooding you with test emails ;)

wet:
Even though a page can contain multiple forms, you can only submit one at a time, so if ZCR (zem_contact_reborn) recognizes which form is being submitted, ZCR can abort form processing at the very beginning if it’s the wrong form. This prevents the wrong form from filling the zem_contact_form variable. No multi-dimensional array is needed.

This leaves the question on how to recognize which form ZCR should process. You suggest an extra attribute. The approach I want to take is to recognize this automatically. The md5 hash would not be shown to the email recipient. Same as the nonce, which also isn’t visible to end users.

wet · 2006-11-14 07:49:35

ruud wrote:

The approach I want to take is to recognize this automatically.

Ah, now I understand. Definitely a better approach.

Textpattern CMS

Textpattern CMS support forum

#613 2006-10-30 20:15:49

Re: Plug-in: zem_contact_reborn

#614 2006-11-13 01:45:48

Re: Plug-in: zem_contact_reborn

#615 2006-11-13 02:43:13

Re: Plug-in: zem_contact_reborn

#616 2006-11-13 08:57:26

Re: Plug-in: zem_contact_reborn

#617 2006-11-13 13:36:48

Re: Plug-in: zem_contact_reborn

#618 2006-11-13 13:44:51

Re: Plug-in: zem_contact_reborn

#619 2006-11-13 14:29:49

Re: Plug-in: zem_contact_reborn

#620 2006-11-13 14:39:37

Re: Plug-in: zem_contact_reborn

#621 2006-11-13 18:26:26

Re: Plug-in: zem_contact_reborn

#622 2006-11-14 02:56:20

Re: Plug-in: zem_contact_reborn

#623 2006-11-14 07:47:17

Re: Plug-in: zem_contact_reborn

#624 2006-11-14 07:49:35

Re: Plug-in: zem_contact_reborn

Board footer