zem_contact_reborn v4.5.0.0: contact mail form processing

philwareham · 2016-05-25 13:49:21

I always thought that this plugin would be hugely beneficial if merged into core – it’s an essential plugin and by being in core it then gets guaranteed support (in theory).

Then thankfully Stef stepped in and stabilised the code – as there were so many versions and hacks of this plugin floating about it got mighty confusing. A name change would be fine in my mind just to move away from all those old versions.

Just my opinion.

michaelkpate · 2016-05-25 14:52:23

Some Historical Context for anyone interested

Day 1 – 2004-10-17 – Zem Contact Introduced – zem_contact, flexible mailto form

Day 945 – 2007-05-20 – Zem makes last message board post to date – add id to $thislink array

Day 1040 – 2007-08-23 – Zem Contact Reborn Released – zem_contact_reborn 4.0.3.20

Day 4128 – 2016-02-05 – Zem Contact Reborn 4.5 Released – zem_contact_reborn v4.5.0.0: contact mail form processing

Day 4238 – 2006-05-25 – This post

debeo · 2016-05-26 15:09:03

Can someone point me to tutorial of any kind on how to make form submit via AJAX? I’m sure there was one before but can’t find it now. I have fairly complex layout which is navigated trough URL hash and form submission breaks it.

gomedia · 2016-05-31 01:32:26

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

autocapitalise, autocorrect etc etc are not currently in the HTML5 spec but browsers support them and they make life easier for mobile users.

Maybe a general purpose “additional freeform attributes” attribute would be suitable:

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

Last edited by gomedia (2016-05-31 04:39:57)

phiw13 · 2016-05-31 04:35:41

gomedia wrote #299370:

autocapitalise, autocorrect etc etc are not currently in the HTML5 spec but browsers support them and they make life easier for mobile users.

Maybe a general purpose “additional freeform attributes” attribute would be suitable:

<txp_zem_contact attr='autocapitalize="off",autocorrect="off"' />...

Yeah, now that Chromium (since v43, if I understand Chrome status correctly) has added support for those attributes, there is not much reason to omit them. But it probably should be a fine grained thing, only applied to individual fields not the whole form. Additional Google documentation.

gomedia · 2016-05-31 04:41:35

phiw13 wrote #299371:

But it probably should be a fine grained thing, only applied to individual fields not the whole form.

Agreed – it’s what I had in my head, but my fingers wandered off somewhere … original code suggestion edited accordingly:

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

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.

Textpattern CMS support forum

#91 2016-05-25 13:49:21

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#92 2016-05-25 14:52:23

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Some Historical Context for anyone interested

#93 2016-05-26 15:09:03

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#94 2016-05-31 01:32:26

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#95 2016-05-31 04:35:41

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299370:

#96 2016-05-31 04:41:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299371:

#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

Board footer