Textpattern CMS support forum

You are not logged in. Register | Login | Help

#191 2017-04-05 03:33:34

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

jstubbs wrote #305131:

Anyone use ZCR on WebFaction with email served by Fastmail? Running into some problems and any pointers appreciated…

In case anyone else comes across this issue, the problem was caused by an over zealous spam filter on outbound emails from WebFaction.

Offline

#192 2017-04-26 10:55:10

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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.

Investigation is ongoing. In the meantime (and this is primarily aimed at Oleg, but if anyone has any insight, please chime in) the only reason the plugin uses its own lAtts() attribute parser is to do some extra manipulation for legacy reasons. Namely, to permit “on” and “yes” as alternatives to “1”. I also chose to use this function to enable the plugin’s own implementation of “global attributes” for atts that are common to most input tags:

    $zem_contact_globals = array(
        'accesskey'  => '',
        'autofocus'  => '',
        'dir'        => '',
        'disabled'   => '',
        'hidden'     => '',
        'id'         => '',
        'lang'       => '',
        'list'       => '',
        'readonly'   => '',
        'spellcheck' => '',
        'style'      => '',
        'tabindex'   => '',
        'title'      => '',
        'translate'  => '',
    );

That saved me having to add them to every tag by hand.

Instead of doing that, 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?

If it’s possible I could perhaps remove the plugin’s custom attribute processing and replace it with the core lAtts(). Although, the label attribute for some of the plugin tags are set to some gTxt() value’s default in the attribute list, so I’m not sure how compatible that is with core global attributes. Probably okay, I guess. Untested.

If not, how could I implement something in the plugin that played nicely with the core system? Bonus marks if it’s backwards compatible with 4.6, but not essential.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 3,127
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

maniqui
Moderator
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,625
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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).

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

mericson
Member
Registered: 2004-05-24
Posts: 137
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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

Offline

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,625
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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).

Offline

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

Kjeld
Member
From: Tokyo, Japan
Registered: 2005-02-05
Posts: 216
Website

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

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)


JapaneseStreets.com – Japanese street fashion (mostly txp)
Old Photos of Japan – Japan between 1860 and 1940 (100% txp)
MeijiShowa – Stock photos of Japan between 1860 and 1940 (100% txp)

Offline

Board footer

Powered by FluxBB