Plugin: zem_contact_reborn 4.0.3.18 (old version)

ruud · 2006-11-20 19:05:09

zem_contact_reborn 4.0.3.18

This is an old version. A new version of this plugin can be found here

zem_contact_reborn 4.0.3.18 [old]
zem_contact_lang 4.0.3.5 [old]

Report problems in this topic please.

Upgrading from 4.0.3.17 to 4.0.3.18

Only those who have styled their forms or customized their zem_contact_lang plugin need to read this. Others can simply upgrade both plugins.

CSS / form styling

Some IDs have changed to classes to make multiple forms per page possible. This only matters if you use these IDs in a style sheet.
- id="zemContactForm" changed to class="zemContactForm" (on the form tag)
- id="zemSubmit" changed to class="zemSubmit" (on the submit tag)
If you want to style individual input fields, explicity specify the name for that input field in its corresponding tag instead of relying on how zem_contact_reborn transforms the label into a name/class automatically if no name was supplied.

zem_contact_lang Six extra language strings have been added:

'form_used' => 'The form was already submitted, please fill out a new form.',
'invalid_utf8' => "“<strong>$var1</strong>” contains invalid UTF-8 characters.",
'max_warning' => "“<strong>$var1</strong>” must not contain more than $var2 characters.",
'name' => 'Name'
'refresh' => 'Follow this link if the page does not refresh automatically.',
'secret' => 'Secret',

Bug fixes and new features

Keep in mind that the goal for this release wasn’t to add new features, but to fix bugs in the existing code, so nearly all of the things listed below are bug fixes. Things that should have worked, but didn’t.

Multiple forms per page are possible.
Better handling of UTF-8 input (non-us-ascii characters)
- Subject is now properly mime-encoded (important for site names with non-us-ascii characters).
- Reject invalid UTF-8 input
- UTF-8 aware min/max checking (counts the actual characters instead of the number of bytes)
- Automatic generation of ‘name’, ‘id’ and ‘class’ attributes based on the ‘label’ attribute works now even if the ‘label’ doesn’t contain any us-ascii characters (i.e. Japanese).
- Radio tag now uses the ‘label’ in the email message instead if the ‘name’.
Separating errors and form by using the ‘show_error’ and ‘show_input’ attributes works (fix taken from the development version by stuart/tranquillo)
Text in the body of emails is no longer html-escaped, which matches the content type used (text/plain). If you have an & in your label, it will no longer be transformed into an & amp; in email.
Nonce-based anti-spam measure fixed.
Prevention of duplicate form submission (nonce based)
The ‘to_form’ is now parsed after the main ‘form’ (containing all the input field tags), allowing you to let the ‘to_form’ return an email address based something entered by a visitor.
The MX check does not work on non-windows hosts. Don’t pretend otherwise. 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.
Checkbox state is now remembered correctly if the form is displayed again upon error.
The ‘max’ attribute for input fields and textareas no longer truncates input but gives an error, similar to the ‘min’ attribute.
The ‘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.
‘0’ is now accepted as a value in form fields, instead of being mistaken for an empty string.
User input appearing in form errors is properly HTML escaped.
zem_contact_select:
- Valid XHTML for ‘selected’ attribute.
- Remembers previous input upon errors, even if it contains < > “ & characters.
- Strips newlines, carriage returns and tabs from the ‘list’ attribute.
Ignore ‘default’ attribute when submitting a form (‘default’ is only used when displaying a new form).
Redirect attribute falls back to a meta refresh on webservers that use FastCGI.
subject_form attribute added.
A new forum topic (by far the most requested feature).
…

Older versions, changes and plugin history

Plans for the future

Multi-language support.
Better documentation with more examples.
send_article: keep, remove or split into a separate package?
…

Last edited by ruud (2007-02-18 21:48:20)

mrdale · 2006-11-20 19:13:37

Thanks, I was waiting for the showerrors/showinput fix.

Could you detail the ID changes?

Destry · 2006-11-22 21:24:00

Nice work, ruud. I might actually use this plugin now.

ruud · 2006-11-23 18:17:23

Some small changes:

escaping of user input that shows up in error messages is done within zem_contact_reborn instead of zem_contact_lang now. At the same time, the sitename is unescaped, so having an & in your sitename looks okay in email (the previous test version made it look like & or even &amp;).
removed some unneeded variables and simplified the label2name transform in case the name wasn’t specified. Both shouldn’t have any effect on normal use.

If no-one reports any problems before the weekend, this’ll be released as 4.0.3.18.

ruud · 2006-11-24 00:19:39

Yet another test version. Hopefully the last one.
Redirect now sends more appropriate HTTP headers depending on the server setup and falls back to a meta refresh on webservers that use FastCGI. This is to prevent HTTP 500 errors due to duplicate http Status headers being sent (related to this bug … hmm… where have I seen that name before).
This requires an extra language string called ‘refresh’ (see opening topic).

Last edited by ruud (2006-11-24 00:26:11)

ruud · 2006-11-26 21:34:16

I’d like to thank jstubbs, Matthew, Phillippe and all the others who downloaded and gave feedback during testing… and since all reported bugs have been fixed, we now have an official release.

Last edited by ruud (2006-11-27 07:38:13)

thebombsite · 2006-11-27 20:43:12

Nice one Ruud. I have a nice new site to test it out on. :)

wet · 2006-11-29 17:12:47

Ruud, I tried to separate the input form and error message display using <txp:zem_contact show_input="no" />. However, the plugin still requires to specify a “to” attribute. Me wonders why?

And another issue: Error display requires both tag instances (one with show_input="no", the other one with show_error="no") to share a common $zem_contact_form_id which means that both tags must have an identical attribute set. This seems somehow unhandy and error prone when forms are modified as it requires the web monkey to keep those two instances in sync. Wouldn’t it suffice to have the instance where show_input="no" is specified to display all $zem_contact_error messages whereever they stem from?

Last edited by wet (2006-11-29 17:20:44)

ruud · 2006-11-29 18:27:27

If you want to separate the errors and input part of the form, the entire form, including attributes has to be exactly the same apart from the show_input and show_error attributes. The error part of the form needs this to be able to reproduce the errors. It’s basically two identical forms, one just displays the errors, the other shows the form and sends the mail.

Since the error form usually comes before the input form in the HTML code, the error form has to be able to detect errors all by itself, because by the time the input form is processed, it’s too late to feed back any error to the error form.

By using the ‘form’ attribute, you can keep the contents of the zem_contact form all in one place, which reduces the risk of a mismatch between the error part and the form part, although you still need to keep the attributes in sync (spacings and linebreaks are ignored).

Last edited by ruud (2006-11-29 18:28:54)

wet · 2006-11-29 21:01:43

Thanks, haven’t thought about that.

BTW: I’ve done zem_contact_lang-de for german messages / für die deutschsprachigen Meldungen.

theturninggate · 2006-11-30 08:53:29

Brilliant update to this plugin. The only problem I’m having is that when I send an article to my email address using this plugin, the “ and ‘ characters change into “&blah;” unicode in the email body. Anyway to fix this?

ruud · 2006-11-30 09:39:50

That’s due to a mismatch between the content-type of the email (text/plain) and the article (text/html)
Two ways to fix this: convert the article back to plain text (the email is sent with content type text/plain) or send the email with content-type text/html. The former is probably best. You can try editing the plugin and edit the line (scroll down to around 1/4th of the plugin code) that says:

Removed a solution that used ‘html_entity_decode’, because it doesn’t support UTF-8 until PHP5.

Last edited by ruud (2006-12-04 17:47:16)

Textpattern CMS

Textpattern CMS support forum

#1 2006-11-20 19:05:09