zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke · 2016-06-01 12:06:12

gomedia wrote #299370:

Are there any plans to support such attributes as autocapitalise etc?

There weren’t, mainly because I can’t keep up with the HTML spec, but there are now!

A generic attr (or equivalent) is something I’ve been mulling over for a while. You’ve convinced me to explore it further. But I’d eschew your syntax for a simpler one, given that quotes-in-quotes aren’t very friendly, and comma-separating the att=value pairs is probably good enough separation:

<txp:zem_contact_text attr="autocapitalize=off, autocorrect=off, ..." />

That would just add arbitrary HTML attributes to your chosen tag(s), but without any plugin support whatsoever. It’d just be a dumb repeater, so the above would add:

... autocapitalize="off" autocorrect="off" ...

to your tag. i.e. it would quote whatever you put after the equals sign. Does that make sense?

Related: do I remove explicit support for things like the autocomplete attribute and bundle it under this ‘diy’ attribute so if you want it, you add it yourself? There’s no inherent plugin logic to that attribute so it’s just a dumb repeater, after all.

Similarly, there are other ‘global’ attributes which might fit here too. For example, accesskey, autofocus, disabled, lang, tabindex, translate and so forth. I could remove direct (i.e. first-level) support for these directly as attribute=value pairs and defer them all to the generic tag. Or leave them as they are, and just add attr to permit additional ones.

Anyone have any views either way?

gomedia · 2016-06-01 13:03:34

Bloke wrote #299384:

But I’d eschew your syntax for a simpler one, given that quotes-in-quotes aren’t very friendly, and comma-separating the att=value pairs is probably good enough separation … Does that make sense?

Yes, indeed.

Related: do I remove explicit support for things like the autocomplete attribute and bundle it under this ‘diy’ attribute so if you want it, you add it yourself? There’s no inherent plugin logic to that attribute so it’s just a dumb repeater, after all.

I reckon so.

Similarly, there are other ‘global’ attributes which might fit here too. For example, accesskey, autofocus, disabled, lang, tabindex, translate and so forth. I could remove direct (i.e. first-level) support for these directly as attribute=value pairs and defer them all to the generic tag. Or leave them as they are, and just add attr to permit additional ones.

Perhaps not if they existed in the old ZCR – dare I mention backward compatibility?

And just to push the envelope even further, one might argue that all TXP tags that generate HTML tags should have a general purpose attr. In the past I’ve had to muck around with markup that requires data-xyz attributes and have had to resort to manual markup. And there’s role & aria-* to fiddle with these days. Perhaps ZCR might be a good proving ground for such a thing …

phiw13 · 2016-06-01 13:09:22

Bloke wrote #299384:

Anyone have any views either way?

From the POV of readability for the HTML author, separate attributes are probably slightly easier on the old eyes. On the other hand… meh. Whatever is easier to maintain within ZRC. But then, on the other foot – are there any plugins that add to ZCR and might depend on a particular ZRC-way-of-writing-things? You might want to keep that on the back of your mind, eventually.

Bloke · 2016-06-02 15:47:48

gomedia wrote #299389:

Perhaps not if they existed in the old ZCR – dare I mention backward compatibility?

Hehe, as far as I know, all the HTML 5 atts are new so we could get away with it, but phiw13 makes a good point about other things relying on it, so maybe I’ll leave them for now and just augment them with an attr attribute.

In the past I’ve had to muck around with markup that requires data-xyz attributes and have had to resort to manual markup.

Yes, that is annoying. A generic attribute processor is something I’d like to see. Ruud and Oleg have more parser tricks in the pipeline (next release, not this one) and Gocom had some great ideas about that, which may well see the light of day at that point too.

jakob · 2016-06-03 10:33:42

I’d like to calculate a total amount based on choices made in the ZCR form fields and send this with the email that is sent out (and save it to the database with another function).

As the form field doesn’t need to be rendered as part of the form, I guess I have to do this in a function called with the callback zemcontact.submit?

How can I add a self-calculated field to the set of fields being sent out / saved to the db?

Bloke · 2016-06-03 11:51:46

jakob wrote #299462:

I’d like to calculate a total amount based on choices made in the ZCR form fields and send this with the email that is sent out

Unfortunately zemcontact.submit doesn’t allow you to alter the payload. But zemcontact.deliver does. Here’s an example form:

<txp:zem_contact to="you@example.com">
<txp:zem_contact_text type="number" label="Group 1 Value 1" name="v1" /><br />
<txp:zem_contact_text type="number" label="Group 2 Value 2" name="v2" /><br />
<txp:zem_contact_text type="number" label="Group 1 Value 3" name="v3" /><br />
<txp:zem_contact_text type="number" label="Group 2 Value 4" name="v4" /><br />
<txp:zem_contact_text max="3" label="Generic value" name="vg" /><br />
<txp:zem_contact_radio label="Group 1" name="group-select" checked="1" />
<txp:zem_contact_radio label="Group 2" name="group-select" />
<txp:zem_contact_submit />
</txp:zem_contact>

Say you have a radio set called ‘group-select’ which implies some business logic. In this case, the logic is that if it’s selected, you want to add the corresponding ‘Group’ values together. Additionally, if you select Group 2, the value of the generic (text) input is added to the total. No validation is done on this value so if it’s character data, you’ll need to weed that out. But as a rough example, here’s a tiny plugin module to perform that logic:

register_callback('jcr_contact_store', 'zemcontact.deliver');

// Callback. The ampersand is important on the data parameter!
function jcr_contact_store($evt, $stp, &$data)
{
   // Will store the total in this variable
   $calc = 0;

   switch ($data['fields']['group-select']) {
      case 'Group 1':
         $calc = $data['fields']['v1'] + $data['fields']['v3'];
         break;
      case 'Group 2':
         $calc = $data['fields']['v2'] + $data['fields']['v4'] + $data['fields']['vg'];
         break;
   }

   // Append the total to the email body text.
   if ($calc > 0) {
      $data['body'] .= "\n\nTotal: " . $calc;

      // @todo Some database storage logic here.
   }
}

Not ideal, but how’s that for starters? If you can think of a way to make this cleaner by enhancing the plugin, please let me know.

gomedia · 2016-06-04 05:53:36

jakob wrote #299462:

How can I add a self-calculated field to the set of fields being sent out / saved to the db?

Email on its way.

jakob · 2016-06-05 21:23:14

Thanks Stef and Adi. I think I’m almost there thanks to your help. I’ve solved it (so far) with a ‘home-hammered’ zcr plugin (and learned a thing or two) but Adi, your plugin may come in just handy for another similar situation on my to-do list… I’ll report back!

gomedia · 2016-06-06 23:59:32

Hi Stef,

I’ve just tripped over something else. I notice that the old class zemRequirederrorElement is no longer applied, instead errorElement is used. Something for the “Differences from previous version”?

And in the help can I suggest changing:

required: Class assigned when a required element is not completed. Default: zemRequired.

to:

required: Class assigned when an element is required. Default: zemRequired.

momono-02 · 2016-06-14 10:34:42

Hi Stef, I have been using ZCR version 4.0.3.6 on this website without any problems:
http://verloskundigencoevorden.nl/zemtest/ (made a testpage with a minimal form)

After a PHP upgrade from the host the form didn’t work anymore, it says the message has been sent but the email never arrives.
So I did the upgrade to V.4.5.0. Same problem occurs when sending the form. There’s no problem with Textpattern system emails (like adding a new user). Sadly I have no access to serverlogs due to account settings.

Do you have any idea what I can do next?

Bloke · 2016-06-14 10:49:43

momono-02 wrote #299714:

After a PHP upgrade from the host the form didn’t work anymore, it says the message has been sent but the email never arrives.

This has happened a few times throughout the history of the plugin. Usual fixes are:

Try setting the SMTP envelope sender address in Admin->Preferences. The plugin will (should!) pick that up and use it, which often solves the issue.
Tweak your server setup (if possible) or ask your host to enable SPF or DKIM support. That adds a few security brownie points to each mail and thus sometimes allows them through.
If that doesn’t work and the destination is a Gmail account or app, try a different email provider :-0

Google are a law unto themselves and aggressively filter legit mails. My stance is that it’s my damn mail, so I feel I should decide what is spam and what isn’t. I dumped them for this reason a few months back.

momono-02 · 2016-06-14 12:07:43

Already tried the SMTP envelope sender address but that didn’t do the trick, maybe because I use a different emailadress than the domain it’s send from.
Client has crappy hosting with no phone support but I will try the second fix with SPF or DKIM support.
Thanks man!

Textpattern CMS

Textpattern CMS support forum

#97 2016-06-01 12:06:12

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299370:

#98 2016-06-01 13:03:34

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299384:

#99 2016-06-01 13:09:22

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299384:

#100 2016-06-02 15:47:48

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299389:

#101 2016-06-03 10:33:42

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#102 2016-06-03 11:51:46

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

jakob wrote #299462:

#103 2016-06-04 05:53:36

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

jakob wrote #299462:

#104 2016-06-05 21:23:14

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#105 2016-06-06 23:59:32

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#106 2016-06-14 10:34:42

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#107 2016-06-14 10:49:43

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

momono-02 wrote #299714:

#108 2016-06-14 12:07:43

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Board footer