Query parameters now have their own button and box for controlling them when managing a Cameo form.

Background

Generally, the names of query parameters don’t have to be changed. You can simply take what Cameo gives you. Some websites in which forms are embedded use the same names for their own purposes, though, so it is necessary to change them to avoid a clash.

Fig 1: query params in the Payments form. (1) manage query params, (2) simulate query

Forms which change their behaviour based on query parameters offer controls for the names of those parameters. Previously, except for the booking form (which was complicated), each query parameter name had its own setting () for this.

Query parameters now have their own button

Instead, there is now a button next to the settings button () specifically for managing query parameters (Fig 1: 1).

Query parameter management is unified across most forms. Common code makes it more coherent (and also easier to maintain).

This opens a box which lets you see and set the query parameter names appropriate for the form and explains what they do. It also lets you set a default for when the query parameter isn’t present in the URL of the page embedding the form.

Fig 2: query parameters available for the Payments form

Simulate queries

In the forms management section, the Simulate queries button above the form lets you display the form as if it had some or all of the query parameters provided. This hasn’t changed. But it now corresponds with the query parameter controls.

Personalised forms also understand which query parameters provide the personalisation and set them accordingly.

Particular forms

Booking form

The Booking form reserves places and takes payment for events. It has six possible query parameters which control which event and occasion the form should allow booking for. If these specify more than one event, the first step of the form is an event selection page. For example, the query parameters may select an event which has several performances, and the customer would select the date/time of the performance they want. Or, the query parameters may select a particular set of different events among which the customer can choose. Event selection is skipped when the query parameters identify a single event occurrence.

Previously it was over-complicated to change the query parameter names, and the defaults were set separately. Now, however, the parameters are set independently in the query parameter box. The default is set alongside each query parameter name.

The new personalisation for Bookings form invitations (which uses a further query parameter called msg by default) also appears in this box.

Fig 3: query parameters for event selection and personalisation in the Bookings form, which selects the Event called on line discussion in the absence of any query parameters in the URL which displays the form.

Optout and Email forms

The optout and email forms work a little differently. Organisation settings includes example URLs of showing where to find the pages embedding these forms. This is so that the form and email messages generated by a template agree on the name of the query parameter used to personalise the form. Both the forms and the template substitutions for inserting links to them decide what the query parameter is called by looking at these URLs.

Next steps

Several of the other forms could usefully include personalisation (or better personalisation than they already have). This common framework makes it easier to do this in the future.