Contact form: add additional fields such as telephone

[bobbingwide]

The Divi contact form, and many other contact forms, support multiple fields such as Telephone number.
I don't need a complex solution but it would be nice to include telephone as an additional field for the oik contact form block / shortcode.

Requirements

• Add Telephone field as an optional field
• Include the value submitted in emails

Proposed solution

• Add a fields parameter which accepts the fields to be displayed.
• Default value: name,email,subject,text
• Allow the fields to be in any order
• Support a field name of telephone ( oiku_telephone )
• Include all the chosen fields in the email that's sent.
• Improve the oik/contact-form block accordingly

[bobbingwide]

A slightly more advanced solution would be to allow the contact form shortcode to include embedded content, with nested shortcodes that define the fields to be included on the form.

[bw_contact_form]
[bw_contact_field name=_telephone label="Telephone" type=telephone required=y]
[/bw_contact_form]

This is similar to the solution offered by Jetpack's Grunion contact form.
It's different from Contact Form 7, in which the content is loaded from a Contact form CPT and doesn't use shortcodes, although they look like them.

The [bw_contact_field shortcode] could be similar to the [bw_field] shortcode. It may use the same functions.

It should also be possible to implement the bw_contact_field shortcode as a block.

[bobbingwide]

Notes about other forms plugins

wpforms-lite stores the forms in a CPT called wpforms in JSON format
ninja-forms are stored in custom tables prefixed nf3 ( eg where WordPress prefix is wp_: wp_nf3_forms and wp_nf3_form_meta )
nf3_form_meta columns include label, key & type eg values: Name, name, textbox.

[bobbingwide]

Note: oik-user has some disabled logic that's similar to oik's contact form.

[bobbingwide]

At present the oik/contact-form block block isn't producing any field values for the fields in the form.

[bobbingwide]

At present the oik/contact-form block block isn't producing any field values for the fields in the form.

This was because the [bw_contact_field] shortcode wasn't registered when using the block. When re-implementing the Contact form block with embedded Contact field blocks it may make sense to rework the logic generates and expands [bw_contact_field] shortcodes into direct calls to the implementing logic.

The downside of this is that the code will become less extensible since there'll be fewer action hooks invoked.

[bobbingwide]

Rather than having a fields attribute on the [bw_contact_form] shortcode I've implemented the solution to use the embedded [bw_contact_field] shortcode.

• The default fields are: name,email,subject, and message ( not text ).
• At present Message is a required field and is added to the form if not already specified.

Since the logic uses bw_form_field() to display the fields in the form, the [bw_contact_field] shortcode supports the following field types. The field type can be determined from the field name, which is determined from the field's Label.

Field type	Field name	Notes
text	name, subject	and any other field not specifically catered for
email	email
telephone	telephone
textarea	message, text

The syntax for the bw_contact_field shortcode allows positional parameters

Position	Attribute	Default
0	label	field
1	type	Determined from the name.
2	name	Determined from the label.
n/a	value	null
n/a	placeholder	null
n/a	required	y if the label contains an asterisk ( '*' )

Examples

[bw_contact_field "Name *"]

produces a required text field labelled Name *

[bw_contact_field Telephone]

produces a tel field labelled Telephone

Note: bw_form_field doesn't yet support <input type="tel"

[bobbingwide]

Having achieved a reasonable level of success with the shortcode solution I now want to implement the oik/contact-form as a block that supports embedded blocks of the type oik/contact-field.

• The oik/contact-field will only be insertable into the oik/contact-form.
• It may support several variations such as Name, Email, Subject and Message
• When the Contact Form block doesn't contain nested blocks then it will behave the same as the [bw_contact_form].

[bobbingwide]

The challenge here would be to find out how to implement InnerBlocks and ServerSideRendering at the same time.

It appears other people have already tried this, quite a while ago.
In WordPress/gutenberg#10478 Fabienkaegy wrote

There is no way to pass the InnerBlocks html string to the block renderer Rest endpoint. Which is something that I believe would be very useful.

I suppose I'll have to look at how Jetpack's Contact form blocks work. I assume that there's no Server Side Rendering.

[bobbingwide]

I suppose I'll have to look at how Jetpack's Contact form blocks work.

Rather than use Server Side Rendering I'm going to emulate the form in the block editor.

I'm making some progress. The blocks are much faster than when using Server Side Rendering.

Notes:

• It's OK in the editor, but I need to determine how to render the inner blocks for the front end.
• I haven't yet implemented the different field types: Text, Email and Textarea
• or field length
• or required toggle.
• And the method Jetpack uses for editing the Label is quite nice as well.

Actually, in the Editor the <table> tag is outwith a <div>. Not sure what to do about that.

[bobbingwide]

Actually, in the Editor the <table> tag is outwith a <div>. Not sure what to do about that.

In order to display the Contact form nicely in the block editor I had to replace the table formatting method with grid styling.

For the front end this meant changing the form field logic that calls bw_tablerow() to use a new function bw_gridrow().
It also entailed changing the logic to produce the outer table to a div that'll have the CSS grid styling.

The default contact form is now expected to be a <div class="bw_grid">.
It falls back to a <table/> when the bobbforms shared library version is lower than 3.4.0

The PHPUnit tests for the contact form will now default to the grid format.

Because this change produces different HTML from before the oik version should be changed to v4.9.0
I don't think it's necessary to make it v5.0.0

[bobbingwide]

Now that I've developed the form to be styled as a grid I can try to introduce a checkbox field that gets a user to confirm they understand how the data they submit might be used.