đī¸Static and Dynamic Form Layouts
Last updated
Last updated
Form Layouts are designed to supercharge your experience of setting up forms in Siteglide with these key objectives:
Get started quicker. No need to copy and paste fields from the default layout into a custom layout anymore in order to add styling. With a click, you can have a styled form layout ready to go.
Get consistent styles across your forms - Form layouts are modular, using component layouts to style individual UI-controls. This makes it easier to apply consistent styles between your contact form and secure zone signup form without editing every line individually. Just add the code for each component to that form's layout once.
Low Maintenance - No need to change your form layout every time a new field is added or removed in the Admin. By choosing the dynamic option, your layout will automatically adapt to any changes in the Admin and display them in the form.
These are the currently supported form features out of the box. Feel free to add more to your Static Layouts (see more about static vs. dynamic layouts below) and we may add more if there is popular demand.
User CRM fields
âī¸
CRM Address Book - Add Addresses and if applicable store against a checkout order.
âī¸
Secure Zones Signup
âī¸
eCommerce Checkout Form
âī¸
eCommerce Basic Payment Form
âī¸
eCommerce Quote Form
âī¸
reCaptcha or hCaptcha
âī¸
eCommerce Subscription Form
âī¸ Partial Support
CRM Address Book - Choose an existing Address
â Not yet. Awaiting: https://roadmap.siteglide.com/core-platform/p/crm-update-existing-addresses
CRM Companies
â
Change Email / Change Password
âī¸
Custom Field Sets
â
WebApp & Module Front End Item Create/Edit/Delete Forms
âī¸
The Form Layouts are organised into sections based on the Siteglide feature they provide layouts for:
CMS Forms
WebApp Item Create Forms
WebApp Item Update Forms
Delete Forms
Module Item Create Forms
Module Item Update Forms etc.
Click to learn more about WebApp CRUD Forms and Module CRUD Forms.
The Form layouts can be installed in the same way as other SiteBuilder layouts, but with a few differences:
Note that it's recommended to output Update and Delete Forms for WebApps and Modules inside a WebApp Layout so that they inherit the correct ID and other data. This is why these layouts are not available directly on PageBuilder yet.
Siteglide stores form layouts in folders according to their form ID e.g. form_1 or form_2. When you install a form layout, we ask you which folder you want to install the layout into based on the form_id/ name. If you are installing a WebApp or Module CRUD form, the ID of the WebApp or Module will be used instead.
With dynamic layouts though, the form is not restricted to working on a single one of your forms. A contact form layout can be copied and pasted into another form folder and will work out of the box. We'll look more at static vs. dynamic layouts next.
When you install a SiteBuilder form layout, you must choose whether you need a static or a dynamic layout.
Modular, component-based layouts for editing markup and styles consistently.
âī¸
âī¸
Quickly get started with a ready styled layout for your form.
âī¸
âī¸
Form layout files will work on any form without needing code changes.
â
Re-install the layout from SiteBuilder to create a version which will work on the new form.
âī¸ Note- they will need to be copied and pasted (or installed) into each form's layouts folder, but no changes in code needed!
No need to change your layout code when a new field or feature is added to the form in Admin.
The liquid code dynamically updates the HTML when the page is loaded by reading the fields defined in the Siteglide Admin form configuration.
â
Re-install the layout from SiteBuilder to create a version which will work with the new features.
âī¸
Full control over re-ordering fields in the Layout Code.
âī¸
âSee the `defer_fields` parameter for options.
Can re-order fields in the file `marketplace_builder/views/partials/tables/forms/.liquid` in Siteglide-CLI using the `order` property for weighting.
â
âī¸
In summary, the main benefit of dynamic layouts is that they take very little code maintenance compared to traditional Siteglide form layouts. All features are controlled via the Siteglide Admin.
The main reason to choose static forms might be if you want full control over the order of your fields or the functionality in your form. In this case, you're using the power of SiteBuilder form layouts to get you started fast, then you're able to change anything you like from there-on-out.
If you're not sure, why not start with dynamic form layouts, then switch to static form layouts if you need to later.
All form layouts have a main layout file, or wrapper, which takes the name you gave the layout and a subfolder of component layouts named after the layout, but with _components at the end. See the example below:
This file structure will be exactly the same whether you opt for a static or dynamic wrapper. The main difference between the two types of form layout will be the contents of the wrapper.
A static wrapper contains
liquid tags for each component in your form and passes them the data they need via parameters. These parameters may appear to be hardcoded, however, it was dynamically generated at the time the layout was created by SiteBuilder- it will just need editing if there are any subsequent changes in Admin.
Alternatively, after making changes to the form configuration, you can always use SiteBuilder to re-generate a new version of the layout with a new name and new parameters.
A dynamic wrapper does not include components directly; instead it includes this include tag which runs the dynamic SiteBuilder script for fetching the latest configuration of the form:
This tag can be passed parameters to modify its behaviour. Any of the parameters below can alternatively be added directly to the Siteglide `
` tag and the `form_layout_fields` include will inherit their values.
collection ParameterSetting collection: 'false' means the fields will be outputted in the HTML exactly in the place of the
tag.
Setting collection: 'true' allows you to re-position key groups of fields within your wrapper.
See available field groups below.
Outputting field groups on the page while using collection='true'
The available field groups are:
Siteglide and Custom Form Fields
This contains all Siteglide and all Custom Fields in the Form:
Hidden Fields
This contains hidden fields needed to run the form:
Address Fields
This is an array which contains all CRM addresses added to the form, if any are present:
The code here will loop over them all and output them all, but you can edit this if you want to display Billing and Shipping addresses separately.
reCaptcha
This contains the hCaptcha or reCaptcha, if present:
Note that Siteglide recommends using hCaptcha with forms. This file however, continues to be named reCaptcha for backwards-compatibility reasons.
Payment Gateway
This contains the payment gateway and payment fields, if present:
disable_fields Parameterdisable_fields: can be passed a comma-separated string of field names to hide from the form. In the example above, the field called Name from the addresses is hidden.
The name field for the User's name and other mandatory Siteglide fields are exceptions. It cannot be removed from the form using this method.
defer_fields ParameterThe defer_fields: parameter is useful where you want to use the advantages of dynamic form layouts for most of your fields, but also want to manually move a few key fields out of the main field output and into a separate section within the form.
To do this, first add the fields' names to a comma separated list in the defer_fields: parameter.
Then, you can output the individual field where you would like it using the following code:
In fact, the full range of deferred fields are available as an array here:
Developers can use this to loop over the fields if they wish. The additional filters in the example above help to find the item in the array with the field name you need, access the HTML needed to output the field and finally bypass platformOS's sanitization so that the HTML is output as intended (see Form Layout Sanitization section for details).
This feature could also be useful if you wish to hide and show some fields conditionally and therefore require greater control over these.
hide_name_while_logged_in and hide_email_while_logged_in ParametersThese parameters exist primarily for the use-case of implementing a form with multiple parts or sections, where each section is actually a form in its own right. Siteglide mandates the inclusion of the name and email fields in every form that outputs, but this solution allows you to hide these fields on the 2nd, 3rd etc. sections of the form while the user is logged in and their values are auto-filled behind the scenes (and is still submitted along with the form). This use-case is demonstrated on the Flowbite Demo Site:
For both parameters, the default is 'false' and turning on the feature is 'true'.
If the user is not logged in, the fields will show as normal, as they are awaiting user input.
Important note: this functionality relies on the name_field and email components to contain code which will hide these fields, because the fields need to output, but hidden. If your component does not contain this code, you can add the example from below:
Fields to edit email and password are not part of the Siteglide Form Configuration and are instead added by parameters.
Set include_email_editor to 'true' to include the edit_email component in the form.
Set include_password_editor to 'true' to include the edit_password component in the form.
Authorizing the Change
Including either of these parameters will also cause the current password component to display, as this is needed to authorise the change.
Validation
Siteglide provides server-side validation to ensure the security of this functionality.
On most form layouts we provide, the default behaviour for client-side validation is that if an edit_email or edit_password component is displayed on the form, it is required. This is the simplest behaviour to implement and makes sense if you have an account area with separate small forms for each possible action. If you have one large form and you want editing email/password to be optional, it might be sensible to add JavaScript to remove the required classes from the fields if they are empty, or to change this directly in the component layouts. You would also need to remove the required class from the password field in the situation that neither an attempt to change email, nor password was attempted.
Adding Confirmation Validation
Set confirm_email_password to 'true' and any email or password edit field will come along with a confirmation field for validation. This comes with client-side and server-side validation.
Troubleshooting Edit Email & Password
A form must have a secure zone set against it for this feature to work properly.
Editing Email & Password on Static Form Layouts
For Static Layouts, follow the Siteglide Documentation for editing emails & passwords. You can include the relevant components and pass the components the paramters above if you like.
custom_form_redirect parameterThis is a quick way to override the form_redirect path that's set in the Siteglide Admin for a specific form. One common use case would be to set the form to redirect to the current page:
Prior to v. 4.6.3 this was already possible in hidden fields, so this parameter just adds the convenience of setting this at a higher level in the code. It relies on the new versions of the form layout's hidden
Components are files within the layout which are re-usable. This helps speed up development and achieve consistency as a string component need only have classes added once to re-style all <input type="text"> elements in the form. Components are used by both Static and Dynamic forms of each layout. Below is an example string.liquid component (the classList for the <input> has been simplified for the sake of readability!):
There is a component for each Siteglide field type that is available on standard forms. There are also components for additional features such as Secure Zones or eCommerce which can be used if required. Most layouts will include these extra fields as an option even if the layout design might not appear to need it, in case these are required in future. Once installed, the layout is yours and you can delete any components which are not needed.
Some Siteglide field types are available only for CRM fields at the moment. We will provide a component file for all of these, but it may be empty if we don't support that field type in your library yet.
The main components available are as follows:
Field Type Components
string.liquid
boolean.liquid
input_checkbox.liquid
input_radio.liquid
datasource_multi.liquid
datasource.liquid
date.liquid
textarea.liquid
select_multi.liquid
select.liquid
file.liquid
Components with Unique Functionality
hidden_fields.liquid
This contains hidden fields which are most likely to be edited, e.g. to override the form redirect.
email.liquid
Mandatory.
name_field.liquid
Mandatory.
password.liquid
Appears if Secure Zones are activated for the Form and right conditions are met.
recaptcha.liquid
Appears if reCaptcha is enabled for the form.
subheading.liquid
Only used if `collection` is set to false.
basic_payment.liquid
For eCommerce forms, the correct component will be included depending on the form's payment settings.
checkout_standard.liquid
quote_only.liquid
subscription_detail.liquid
More components may be added in future.
The main Liquid parameters passed into form layout components are as follows:
{{name}}
The name attribute's value.
{{value}}
The value attribute's value.
{{attributes}}
This normally adds the data-attributes needed to allow the Siteglide CRM to work correctly, where appropriate.
{{validation}}
Normally contains either `` or required as required. For Siteglide, this needs to be included within the class list of the element (or in some cases e.g. checkbox groups, within the parent element's classList).
For libraries which use Bootstrap (or another library which relies on native HTML validation to some extent), it can also be useful to add the {{validation}} inside the element so that it also adds the required attribute to the element where required.
{{field_id}}
The field's ID.
{{label}}
The human-readable name of the field. Useful for labels.
{{options}}
An array of options for this component, where needed. For example for a <select> component.
{{form_redirect}}
Pulls in the default form redirect URL.
{{form_payment_amount}}
Pulls in the default amount for Basic Payment Forms.
{{form_payment_currency}}
Pulls in the default currency for Basic Payment Forms.
{{include_email_editor}}
If `'true'`, the `password` component should display in order to allow the user to confirm their current password. This is necessary to confirm they have the required permissions to change their email address in another component. Inherited value.
{{include_password_editor}}
If `'true'`, the `password` component should display in order to allow the user to confirm their current password. This is necessary to confirm they have the required permissions to change their email password in another component. Inherited value.
{{confirm_email_password}}
If `'true'`, the `edit_password` and `edit_email` components should also display an additional confirmation field. Inherited value.
{{hide_email_while_logged_in}}
This value is inherited from: [hide_email_while_logged_in](#the-hide_name_while_logged_in-and-hide_email_while_logged_in-parameters)
{{hide_name_while_logged_in}}
This value is inherited from: [hide_name_while_logged_in](#the-hide_name_while_logged_in-and-hide_email_while_logged_in-parameters)
Using Siteglide-CLI, it is possible to give your Form's custom fields an order property. This will affect the order they appear in the Siteglide Admin, default form layout and SiteBuilder Form Layouts. For dynamic SiteBuilder form layouts, changes in order will appear immediately, however for static form layouts, the order will only affect the initial install of the layout.
Firstly, pull the site using Siteglide CLI.
Next find the table's JSON file. The tables directory is at marketplace_builder/views/partials/tables/. Within that, you can find directories for forms, webapps and modules, with each one containing files numbered by IDs.
(Optional) Convert the minified JSON into human-readable JSON. If using VSCode, you can use an extension like JSON tools or a similar equivalent for your IDE.
4.Inside the JSON file, find your custom field under custom_fields, e.g. form_field_1_1. If the order property already exists, edit it to a new number. Fields are ordered in ascending order, so the higher the number, the earlier in the form it will appear. Negative and decimal numbers are allowed.
(Optional) If you carried out step 3, minify your JSON file.
Sync the JSON file to the site.
Save the form in the Siteglide Admin. This copies the changes from the JSON file into the Form Configuration automatically. (Previously we recomended making changes to order in the form configuration directly, however, the method stated above is now the only reliable method.)
Since it is not currently possible to edit the orders of system fields e.g. name, email, using the above method, it's useful to note that we now assign default orders to these fields. We use negative values with large gaps between them deliberately, so that these fields default to the beginning of the form, but there is ample room for custom fields to be ordered before, between and after them.
name: -40
email: -30
password: -20
Categories: -10 (This refers to WebApp and Module item categories)
This is a breaking change in 4.3.0, so older sites which update to this version may need their fields re-ordered using the documented method.
When outputting user-submitted values on a web-page e.g. the value attribute in a form field, there is a chance of a malicious user introducing executable code into that value by submitting it in a form field.
platformOS will automatically sanitize fields when values are outputted in {{ }} Liquid tags, unless the | html_safe filter is used. Since the html_safe filter is recommended in the main part of your Form Layouts, you may be re-assured to know that the value attribute will have been already outputted at the stage of your form components being rendered from Liquid to HTML by the server. This means the user-submitted values will have already been sanitized and you can use html_safe safely where we recommend it.
On WebApps, fields like enabled, release_date and expiry_date were originally hidden away in hidden fields. We needed them to be there and inheriting default values, but didn't yet have UI support for them.
If you want users to be able to edit them, you can add custom code to the hidden field component and make them visible there.
Proper support for these fields will be added in a future update.
