zem_contact_reborn 4.0.3.20

ruud · 2007-08-23 14:06:07

zem_contact_reborn 4.0.3.20

Download here (works in TXP 4.0.3, 4.0.4, 4.0.5 and higher versions in the TXP 4.0.x series):

zem_contact_reborn
zem_contact_lang
upcoming version for Txp 4.5.x (as a plugin template file, not a compiled plugin. For testing only)

Report problems or ask questions about this version of the plugin here in this topic please.

Upgrading from 4.0.3.19 to 4.0.3.20

The only change that might affect people is that label attribute values are assumed to be plain text, not html escaped text, since the emails need the plain text values and it’s much easier in the plugin to escape the label when showing it in the browser (if needed). In the older versions no escaping or unescaping was done which could cause problems in either email or in HTML.

See also: upgrade info and changes in older versions

Bug fixes

remove leading and trailing spaces from form input
escape label attribute values when showing the form in the browser (not in email, plain text there)
remove dependency on zem_contact_submit ‘name’ attribute value for the submit button as this is handled by the zem_contact_form_id nowadays (makes it easier to custom build your own submit button)
use ISO-8859-1 instead of ISO-8599-1 (typo!) when override_charset is set in the TXP preferences (by default UTF-8 is used)
add some extra email header escaping. Not to fix header injection, but to filter out ASCII NULL
use the correct sender email address in the copysender email even if the ‘from’ attribute is set in the zem_contact tag
some other HTML escaping fixes
make required=“0” attribute work when used in zem_contact_email tag (thanks Federico!)
don’t display empty input values in the email
use TXP built-in email validation checks instead of duplicating code in plugin

Plans for the future

Built in ‘Multi language pack’ support (which also means making the zem_contact_lang plugin optional)
Customizable email body layout
Support for attributes like tabindex
Requires TXP 4.0.4 or higher to reduce code size.
…

Solving plugin installation problems

If you get a blank screen or a HTTP 304 or a HTTP 404 error during plugin installation, put the following in a .htaccess file in your textpattern folder (not your website root!) during the install and remove it afterwards:

<IfModule mod_security.c>
SecFilterScanPOST Off
</IfModule>

If you get an error message during plugin installation that reads “malformed or empty plugin code”, you either didn’t copy/paste the entire plugin code (try again!) or your webhost has restricted the maximum amount of text that can be transmitted using a form. In the latter case, try installing the compressed version of the plugin (requires TXP 4.0.4 or higher).

Apparently very few people still use this version with the rather old TXP 4.0.3, because it took almost 3 months before someone pointed out that TXP 4.0.3 does not have a built in is_valid_email() function. If you are still using TXP 4.0.3 (please, please upgrade!), then you can temporarily restore 4.0.3 compatibility by editing the plugin and adding the following code at the end. You’ll have to remove it when upgrading to a higher version:

function is_valid_email($address)
{
  return preg_match('/^[a-z0-9](\.?[a-z0-9_+%-])*@([a-z0-9](-*[a-z0-9])*\.)+[a-z]{2,6}$/i', $address);
}

Last edited by ruud (2007-11-14 19:28:52)

diuk · 2007-08-23 18:52:41

Hi Ruud, thanks for the update, however, attempts to install this plugin result on a blank page.

Regards,

D

ruud · 2007-08-23 19:19:37

Try the compressed plugin, if that’s not it, do you have mod_security active on your webhost?

marios · 2007-08-23 19:19:43

Thanks also for the documentation, which is getting better and better.
I can see, the plugin is in good hands now. Will take some time, before I can fully test this.

regards, marios

wet · 2007-08-23 19:27:29

Works without a flaw, but I also had to disable SecFilterScanPOST of mod_security to avoid the “WSOD” upon installation.

Logoleptic · 2007-08-25 22:47:20

I’ve written a little API plugin that improves compatibility between zem_contact_reborn and asy_jpcache. The plugin gets rid of “form already used” errors by clearing the cache when a ZCR form is submitted. Basically, it makes asy_jpcache handle ZCR forms the same way it already handles comment submissions.

lrumley · 2007-09-11 02:22:13

Can you do anything with optgroup in your txp:zem_contact_select tag? Check out my workaround by turning off CSS at this site.

Notice that I created a Recipient2 field to actually work, and a Recipient field to look pretty. On submit, Javascript sets Recipient2=Recipient to make the form go the correct person: not ideal.

Thanks!

Last edited by lrumley (2007-09-11 02:32:29)

jstubbs · 2007-09-15 11:07:38

Works beautifully. Can we disable or remove pap_contact_cleaner now, or is it still a good idea to use it?

ruud · 2007-09-15 11:12:17

pap_contact_cleaner still helps to reduce spam, so if you get a lot of spam it can be a useful plugin to install (I have it installed on the websites I maintain).

Logoleptic · 2007-09-16 02:14:38

jstubbs wrote:

Works beautifully. Can we disable or remove pap_contact_cleaner now, or is it still a good idea to use it?

As Ruud mentioned, pap_contact_cleaner is still a good idea. As originally written, however, it can trip up some software that pre-fills forms. This is because the field ids that it uses are things like “phone,” which those programs use to single out fields that can be pre-filled.

With a couple of edits, the plugin can be almost as effective without causing problems. Look for two function calls:

finput('text','phone',ps('phone'),'','','','','','phone')

and

finput('text','mail',ps('mail'),'','','','','','mail')

Change the first and third occurrences of “phone” and “mail” in each function call, like so:

finput('text','eggs',ps('phone'),'','','','','','eggs')

and

finput('text','spam',ps('mail'),'','','','','','spam')

You can use any word to replace the defaults, so long as it’s a valid HTML name or id attribute value. Don’t use words that might be common id or name values for fields on other forms (like “user”). Also, don’t use the examples I gave above. If spammers know which fields are bogus, this technique loses its effectiveness. Our chief weapon is surprise!

Last edited by Logoleptic (2007-09-16 02:15:30)

Ambitiouslemon · 2007-09-20 23:54:37

Your markup for the contact form doesn’t validate since you placed the <form> tag inside an inline tag (in this case the <p> tag).

You don’t really need to play everything in a paragraph tag for us so you could either lose the <p> tag or place the form tag outside the paragraph tag.

Its an incredibly minor complaint but I was hoping you could address it anyway so our forms would validate.

thank you!

output from w3c validator:
Line 34, Column 144: document type does not allow element “form” here; missing one of “map”, “object”, “ins”, “del”, “noscript” start-tag.

…#zcr72f785f80b3bd697ad2f35cf3d15be27”>

✉

The mentioned element is not allowed to appear in the context in which you’ve placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you’ve forgotten to close a previous element.

One possible cause for this message is that you have attempted to put a block-level element (such as “<p>” or “<table>”) inside an inline element (such as “<a>”, “<span>”, or “<font>”).

maniqui · 2007-09-21 00:14:16

Ambitiouslemon wrote:

Your markup for the contact form doesn’t validate since you placed the <form> tag inside an inline tag (in this case the <p> tag).

I use ZCR 4.0.3.20 and it isn’t wrapped by any <p> tag (by the way, <p> is a block element).
Is is possible that you are including your ZCR form inside the body of an article?

In that case, you have to put an space in front of the starting tag, because Textile is wrapping that line with <p> tags.

Textpattern CMS

Textpattern CMS support forum

#1 2007-08-23 14:06:07