Skip to main content
Here you’ll find two ready-made sets of configuration and templates for a contact form. Use one of them as a starting point and adapt it. How an INQUIRY is structured, where the files belong, and how to embed the form in a shop page is described on the guide page. This page contains only the templates themselves. Guide: Forms for customer inquiries · Upload module for forms with INQUIRY

The two sets

The two sets differ only in these points. Everything else, the basic configuration, the field list, and the remaining templates, is the same in both. You can therefore also combine the features: to get a form with an arithmetic challenge and a PDF attachment, add both sections to the same configuration.The previous documentation doesn’t mention that the two sets can be combined. This has been added here.

The files

anfrage.config

The configuration consists of three parts: the general sections, the free input fields, and the fixed address fields. The first two are shown here in full; the address fields are described further below as a pattern with a list of values.

The general sections

Only in the PDF set

Only in the set with the arithmetic challenge

The arithmetic challenge is only one of four captcha methods that INQUIRY4 supports. The guide page describes the others and what you need to keep in mind regarding data protection.

The address fields

After the free input fields, the configuration contains the fixed address fields: first those of the inquirer with the prefix A-, then those of a different delivery address with the prefix D-. Each field gets its own section, and all of them have the same form:
The following table shows how the sample set populates each field. Create a section following the pattern above for every field you need. In the sample set, the delivery address fields are all set to Allow = no. They exist for the same fields as above, from D-Salutation to D-Suffix10, each with the field name prefix d_ instead of a_. A customer number, a UserID, and a User Index exist only for the inquiry address.
The sample set contains all sections in the file, including those set to Allow = no. That’s convenient for trying things out, but it makes the file more than 800 lines long. For production use, it’s enough to create only the sections you actually need.

anfrage.htm

The form. Each field consists of three parts: the label from _descr, the input field with _name and _max, and an error area with _error. The error area appears only if validation failed for that field.
Don’t omit ~INQUIRY-Link~ directly after the opening form element. The module uses it to find the inquiry again when the form comes back with errors.

The addition for the arithmetic challenge

In the set with the arithmetic challenge, this block is added before the submit button:
The names of these tags were derived from the structure of the other fields, not from the module. Check them against the INQUIRY4 documentation before you use the block. The rest of the page is taken from the templates.

anfrage_antwort.htm

The page shown after submission. It covers two cases: the successful inquiry, and the case where the form has already been submitted or was left open for too long.
The block with {PDF-Form} is included in both sets. Without the <PDF> section in the configuration, the condition simply isn’t true and the button doesn’t appear. You can therefore use the template unchanged for both sets.

anfrage_antwort_pdf.htm

Only in the PDF set. The appearance of the inquiry as a PDF.

anfrage_confirmemail.htm

The confirmation sent to the inquirer.

anfrage_inquiryemail.htm

The notification sent to the shop operator. It shows what each of the five AUTOGENERATE tags outputs.
This template is built as a showcase: it outputs all five variants one after another so you can see which one suits you. For production use, leave out the other four.

tpl_anfrage.htm

The shop page that embeds the form. It contains nothing except the call.
The cfg parameter names the configuration file. This is how you distinguish multiple forms in the same shop: a separate configuration for each form, and a separate shop page that calls it.

Note on all files

All templates use the HTML 4.01 doctype and charset=iso-8859-1, matching charset = ISO-8859-1 in the configuration. For a new shop, switch both to UTF-8, in both places together. If the configuration and the template don’t match, umlauts are displayed incorrectly.
Compared to the previous documentation, eight places in the templates have been corrected: the spellings A-ZIP and A-EMail, which differ from the section names A-Zip and A-Email; a &lt;Basic&gt; that appeared as a bare angle bracket in a heading; two hard-coded field names instead of the corresponding tags; a label with two targets in one for; the missing id attributes on the input fields; a superfluous space in <body >; and the outdated wrap attribute on the textarea.