zem_contact_reborn v4.5.0.0: contact mail form processing

etc · 2017-04-27 09:16:01

Bloke wrote #305504:

A heads-up: anyone on the bleeding edge of 4.7.0 will notice that the plugin outputs labels twice. There’s a temporary patch you can apply, as outlined in the GitHub issue linked above, but I don’t know if it has other side-effects yet. I suspect it does, though it at least stops the duplicate labels.

Sorry for the global atts breaking ZCR, but that was (kind of) expected. Actually, I should have created a branch for these, but branches are rarely tested ;-)

could I (a.k.a any plugin) hook into the core’s shiny new global attributes system and augment the available attributes for specific tags? i.e. register the above attributes as valid options only for the plugin’s tags? If not yet, could it be done that way? Is that desirable? Or too slow?

Dunno. By definition, global attributes are applicable to any tag. We can (should) imagine some kind of attributes registration for new plugins, but there are few obscure points:

backward compatibility, of course
performance. Even a smallest in_array() call in the parser can slow it down.

I’m unable to find a right balance without much testing. Let’s try to fix issues on the plugins level first (I can take a look to ZCR). If this is too complicated, we can simply drop the global attributes.

Bloke · 2017-04-27 09:30:45

etc wrote #305517:

By definition, global attributes are applicable to any tag.

Yes, I thought about that after I posted my stupid comment. Forgive me.

Let’s try to fix issues on the plugins level first (I can take a look to ZCR).

Thank you. Any assistance you can offer would be brilliant. And if we can drop the plugin’s implementation of lAtts() and do it properly without too much code repetition/bloat — there’s already waaay too much repetition in it — that would be even better.

maniqui · 2017-04-27 20:28:00

Heads up!
This affects emails sent from any contact form (not only forms managed by zem_contact_form): if the user filled in a yahoo.com (or yahoo.com.XX where XX is a country code) email address, then there is a very high chance that the email message will be rejected by your server (ie. it won’t be delivered, not even to the spam folder). See here, here.

The solution is easy: use the from attribute in zem_contact_reborn to set a From: address. You will be able to reply to the sender, as when using the from attribute, zem_contact_reborn adds the Reply-to: header, and sets it to the sender’s email address.

Bloke: I wonder if it wouldn’t be a better solution to have a built-in solution: adding a special case in the plugin code so when the sender is using a yahoo.com address, the From: would be set to another address, to avoid being caught by this issue (when not using the from attribute). I know, I know… they said that special cases aren’t special enough.

phiw13 · 2017-04-28 03:18:55

maniqui wrote #305532:

This affects emails sent from any contact form (not only forms managed bu zem_contact_form): if the user filled in a yahoo.com …

I had similar problems with gmail.com addresses (at least I think it is the same; haven’t found any conclusive evidence or documentation though).

The solution is easy: use the from attribute in zem_contact_reborn to set a From: address. You will be able to reply to the sender, as when using the from attribute, zem_contact_reborn adds the Reply-to: header, and sets it to the sender’s email address.

Same solution for any contact-type script: the From: header should be set to your own contact address, and use the Reply-to: for the person who fills in the form.

Bloke: I wonder if it wouldn’t be a better solution to have a built-in solution: adding a special case in the plugin code so when the sender is using a yahoo.com address …

Why make it a special case? Make it the rule, and always add the Reply-to: header (and allow for override if the user has special needs).

Bloke · 2017-04-28 09:03:39

phiw13 wrote #305533:

the From: header should be set to your own contact address, and use the Reply-to: for the person who fills in the form.

If this’ll make it easier and more robust, the plugin should try to do this by default. The assumption would be that there’s an email field in the form. And the form designer used <txp:zem_contact_email /> instead of <txp:zem_contact_text type="email" /> (unless we can reliably trap that case too). From memory, I think the plugin fails to send if there isn’t an email field.

So currently:

Visitor fills out a ZCR form which asks for an email address.
They type an address that ends in yahoo.com or (as I and phiw13 have witnessed) gmail.com, or <insert name of provider who will cause problems in the future>.
They send the form off and it disappears into the abyss because the recipient server thought it didn’t originate from the domain from which it was sent.

In which case, yes, phiw13’s solution seems the logical route. No special cases. Use the sender’s email as Reply-to:, and make the From: header the contact address unless from or from_form attributes are set.

I’ll look into doing that unless someone can see an overarching reason why it wouldn’t work.

mericson · 2017-05-01 02:02:39

I continuously get the error message “The form has expired, please try again.” for the contact form on a site I’m supporting. I’ve also received complaints from others that it doesn’t work.

Just to try it I upgraded my zem_contact_reborn and zem_contact_lang to the most recent versions.

FYI, running…
Textpattern version: 4.6.2
PHP version: 5.6.30
zem_contact_reborn 4.0.3.21
zem_contact_lang 4.0.3.6

phiw13 · 2017-05-01 02:47:51

mericson wrote #305571:

I continuously get the error message “The form has expired, please try again.” for the contact form on a site I’m supporting. I’ve also received complaints from others that it doesn’t work.

Just to try it I upgraded my zem_contact_reborn and zem_contact_lang to the most recent versions.

FYI, running…
Textpattern version: 4.6.2
PHP version: 5.6.30
zem_contact_reborn 4.0.3.21
zem_contact_lang 4.0.3.6

You are running an older version; try version 4.5.0.0 (and you don’t need zem_contact_lang with that version).

Kjeld · 2017-05-11 07:02:19

Kjeld wrote #304168:

I just installed zem_contact_reborn v4.5.0.0 on a site using MLP.

The English side works well, but on the Japanese side, I get messages like zem_contact_email_thanks instead of the actual Japanese language strings.

What am I missing?

Bump… Posted this in February, but got no responses yet.

You can see the issue here. It says zem_contact_contact instead of the actual Japanese language string…

Last edited by Kjeld (2017-05-11 07:17:13)

phiw13 · 2017-05-11 07:09:49

Kjeld wrote #305660:

Bump… Posted this in February, but got no responses yet.

Did you miss this post ?

(IOW there are no Japanese language strings available)

Bloke · 2017-05-11 09:29:24

Kjeld wrote #305660:

It says zem_contact_contact instead of the actual Japanese language string…

Sorry for missing your request. Have you added Japanese strings to the plugin? Are they in your database if you, for example, query it:

select * from txp_lang where name like 'zem_contact%' and lang = 'ja-jp'

Edit: phiw13 was faster!

Last edited by Bloke (2017-05-11 09:40:57)

uli · 2017-06-22 13:42:30

How can I add a zemerror class to the body tag? In case it can’t be done with zcr: Could it be achieved with adi_gps, i.e. is the random code “predictable” in any way so it could be used in adi_gps?

(Background info: I’ve some CSS animations on the page that I want to overrule cause they seem to avoid the page from skipping right to the zem_error section. Plus the contact form is in the middle of the page, amidst several other articles, i.e. if I stretch the form to elements at the beginning of the page, some things might stop validating or even working.)

Bloke · 2017-06-23 10:59:17

uli wrote #306056:

How can I add a zemerror class to the body tag?

You might have some luck with the zemcontact.render callback. It’s called when the form is displayed to allow you to change it, but you might be able to check the status of the global $zem_contact_error in that callback and take action on other elements there?

You don’t have direct access to the DOM, but you might be able to manipulate the buffer, or (perhaps better) just drop some JavasSript on the page right there in the ZCR form that adds the class onload if there’s anything in the $zem_contact_error variable.

There’s nothing in the URL that could help you determine what the error state is.

Textpattern CMS

Textpattern CMS support forum

#193 2017-04-27 09:16:01

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #305504:

#194 2017-04-27 09:30:45

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

etc wrote #305517:

#195 2017-04-27 20:28:00

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#196 2017-04-28 03:18:55

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

maniqui wrote #305532:

#197 2017-04-28 09:03:39

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #305533:

#198 2017-05-01 02:02:39

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#199 2017-05-01 02:47:51

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

mericson wrote #305571:

#200 2017-05-11 07:02:19

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Kjeld wrote #304168:

#201 2017-05-11 07:09:49

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Kjeld wrote #305660:

#202 2017-05-11 09:29:24

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Kjeld wrote #305660:

#203 2017-06-22 13:42:30

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#204 2017-06-23 10:59:17

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

uli wrote #306056:

Board footer