zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke · 2016-04-28 06:36:29

phiw13 wrote #298861:

So far, that does the deed.

Excellent.

it should be lang="fr-fr".

D’oh, well-spotted. I’ll fix that, thanks.

Pat64 · 2016-04-28 07:37:10

Hi Stef ;)

This pre-release is super cool!

I just noticed that label="" (empty attribute to remove the Contact title into the <txp:zem_contact /> tag) doesn’t work.

Comment a line solves the problem momentarily:

    // Set defaults, in the local language if necessary.
    if ($label === '') {
        //$label = gTxt('zem_contact_contact');
    }

Bloke · 2016-04-28 08:11:42

Pat64 wrote #298863:

I just noticed that label="" (empty attribute to remove the Contact title into the <txp:zem_contact /> tag) doesn’t work.

Ahem, good point. I should change the attribute defaults to null, not ''. I’ll fix that as well today, thanks.

EDIT: Fixed.

phiw13 · 2016-05-02 03:07:45

Another (minor) issue with beta 3 (+ patch noted in comment above):

Tag error: <txp:zem_contact class="contact-form-form" to="foo@example.com"> ->  Notice: Undefined variable: lang while parsing form foo on page default

Adding lang="en-gb" to the <txp:zem_contact> tag then works of course.

I would expect the attribute to be optional – if not specified, ZCR uses the language specified for the admin (In this case, admin is the default EN-GB).

Bloke · 2016-05-02 21:15:22

phiw13 wrote #298912:

Undefined variable: lang while parsing form foo on page default...

D’oh. Note to self: use debugging mode in my dev installation.

Fixed, thanks.

phiw13 · 2016-05-06 01:35:12

The selected attribute for txp:zem_contact_option does crazy things.

I’m going by the sample(s) provided in the help file…

<txp:zem_contact_select break="" label="Subject" name="subject">
<txp:zem_contact_option label=" " selected="1" />
<txp:zem_contact_option label="General enquiry" />
<txp:zem_contact_option label="Site issue" />
<txp:zem_contact_option label="Other…" />
</txp:zem_contact_select>

generates:

<select class="zemSelect required-field" id="subject" name="subject" required>
<option class="zemOption" selected="selected" label=" "></option>
<option class="zemOption" selected="selected" label="General enquiry"></option>
<option class="zemOption" selected="selected" label="Site issue"></option>
<option class="zemOption" selected="selected" label="Other…"></option>
</select>

Duh… The same problem occurs if I add selected="0" to the other 3 options. Ok, I then added selected="Site issue" to the txp:zem_contact_select tag itself. Surprise, this appears to work. Or does it? Start filling in the form, omit one of the required fields. Press “Submit”. The error page loads, but notice that the selected option now displays the last option, independently of which field was chosen on first input (or if the field was not filled).

Finally, I added the value="" attributes, with the strings as needed, to my first examples above. Now we’re going somewhere. The option marked as selected is indeed selected, validation does’t do weirdo things anymore.

I think that the help file is a bit in need of a revision here. And, perhaps mark the label and value attributes as required.

Just your average friday morning nitpicking while waiting for a thunderstorm to pass.

els · 2016-05-16 14:07:45

Hi Stef, thanks for these improvements to the plugin! I’m trying to style my contact form, and what I’d really need to do is have different classes for label and input. The class attribute just adds the same class to both. Is there a way to achieve this? Apologies if I am overlooking something obvious…

philwareham · 2016-05-16 14:13:37

Els wrote #299125:

Hi Stef, thanks for these improvements to the plugin! I’m trying to style my contact form, and what I’d really need to do is have different classes for label and input. The class attribute just adds the same class to both. Is there a way to achieve this? Apologies if I am overlooking something obvious…

Can you just target the elements directly, i.e.:

label.someclass {)
input.someclass {}

Or even:

label.someclass {}
.someclass:not(label) {}

Bloke · 2016-05-16 14:18:56

Els wrote #299125:

different classes for label and input

The plugin does indeed add the same class to both elements. I could probably hack it to allow you to add different ones, but before I do that, could you check something out for me please? Is it possible to alter the way you reference the style rules so you can do different things by using the element names as well? For example, with the tag <txp:zem_contact_text class="myTextBox" label="Name" break="" /> you might be able to do:

input.myTextBox {
   min-width:15em;
}
label.myTextBox {
   font-size: 140%;
}

Is that flexible enough for your needs?

Edit: What Phil said!

Last edited by Bloke (2016-05-16 14:19:22)

els · 2016-05-16 14:40:37

I’m using a bootstrap template and was trying to keep it as simple as possible – for me… ;) But of course I should be able to solve it with additional CSS.

Thanks both!

gomedia · 2016-05-22 23:33:25

My query is connected with Els’s post but also shows a change in behaviour between the old & new ZCR.

Consider the following tags:

<txp:zem_contact_radio label="Yes" name="my_input" group="My input" />
<txp:zem_contact_radio label="No" />

The markup generated by the old ZCR is:

<input value=“xxx" type="radio" id=“xxx" class="zemRadio my_input" name="my_input" />
<label for=“xxx" class="zemRadio my_input">Yes</label>
<input value=“yyy" type="radio" id=“xxx" class="zemRadio my_input" name="my_input" />
<label for=“yyy" class="zemRadio my_input">No</label>

Markup from the new ZCR is:

<input type="radio" class="zemRadio zemRequired" id=“xxx" name="my_input" value=“xxx" form=“zzz" required />
<label for=“xxx" class="zemRadio zemRequired">Yes</label>
<input type="radio" class="zemRadio zemRequired" id=“yyy" name="my_input" value=“yyy" form=“zzz" required />
<label for=“yyy" class="zemRadio zemRequired">No</label>

There’re two observations here:

The old ZCR automatically adds a class matching the field name – in this case my_input – to both <label> & <input>.
Specific to radio input buttons, the new ZCR is now adding in a class of zemRequired, when it didn’t appear before.

I’ve used radio inputs as examples but the classes (in #1) are missing from all fields, and the sudden appearance of zemRequired is possibly just fixing a bug. However, it means that the new ZCR is not quite the drop-in replacement for v4.0.3.20 – in my case, some of my styles no longer work.

Can we have the classes back? Either way it’d be useful to document some “Upgrade considerations”.

Bloke · 2016-05-23 09:09:59

gomedia wrote #299201:

The old ZCR automatically adds a class matching the field name

From memory, Phil argued (convincingly) to take all the automatic classes out, bar the ones beginning with zem, in the interests of the plugin not doing things it’s not been asked to do by your tags. If you want to use your own classes, you have to use the class attribute now to override them.

Specific to radio input buttons, the new ZCR is now adding in a class of zemRequired, when it didn’t appear before.

The spec says that the required attribute need only be present on one of the inputs in a group, but it’s recommended that it appears on all. I find the spec a little confusing here. Surely by its very nature, it’s not possible for a radio group to not be required, given that one of the options is always selected, thus always transmitted with the form?

I’m not sure what effect setting required="0" should have on the HTML. Presumably, it should remove the zemRequired class and required attribute. But, in my head at least, it’d be a syntactic/logic error for a radio set not to be required? So maybe we should drop support for required on radio elements, since they always occur at least in pairs? Or am I missing a use case here? Any thoughts anyone?

I’ll add some docs about an upgrade path, though. Good call. And fix the bug you sent me via email, thanks for the report.

Textpattern CMS

Textpattern CMS support forum

#49 2016-04-28 06:36:29

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #298861:

#50 2016-04-28 07:37:10

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#51 2016-04-28 08:11:42

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Pat64 wrote #298863:

#52 2016-05-02 03:07:45

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#53 2016-05-02 21:15:22

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #298912:

#54 2016-05-06 01:35:12

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#55 2016-05-16 14:07:45

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#56 2016-05-16 14:13:37

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Els wrote #299125:

#57 2016-05-16 14:18:56

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Els wrote #299125:

#58 2016-05-16 14:40:37

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#59 2016-05-22 23:33:25

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#60 2016-05-23 09:09:59

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299201:

Board footer