website logo
⌘K
Introduction
PORTAL
Agency Whitelabelling
PAGES
Pages - Accessing Page Data
Pagination Layouts
Page Templates
FORMS
Form Confirmation Pages
Adding a Progress Bar
Adding Custom CSS To Show Form Submit Process
Dynamic Content in Workflow and Autoresponder Emails
How to output Custom Field Set fields in a Form's Custom Layout
Custom JavaScript Validation for Forms
File Upload Previews
FAQ
CATEGORIES
Filtering WebApps and Modules by Categories
Outputting Categories on WebApp / Module / eCommerce Layouts
Outputting Category Fields in any Location
Category Detail Layouts
FAQ
COMPANY INFORMATION
Company Information
SITE SEARCH
Site Search
PUBLIC API/ZAPIER
Zapier - Formatting arrays correctly
Public API/Zapier Changelog
MODULES
Module Marketplace
Building Custom Modules
Siteglide Modules
Front-end Submit Modules
DATA STRUCTURES
Automations
Creating WebApps from the CLI
Field Types
WEBAPPS
Front-end Submit WebApps
Layouts
Search and Filtering
Understanding Custom Field Names and IDs
FAQ
CRM
User Details
User Secure Zones
Storing User's Favourite WebApp / Module Items
User's Form Submissions (Cases)
How Users Edit their Email and Password Front End
Editing a User's CRM record Front End with Custom Field Sets
CLI
Introducing Siteglide CLI
CLI Changelog
Secure Zones with CLI
Page Templates with Siteglide CLI
Pages with Siteglide CLI
Includes with Siteglide CLI
Managing Email Templates
Migrate - Manual Form setup
Migrate - Convert existing Forms
Liquid
Accessing Assets
Liquid Dot Notation
Using WebApp Collections- Tutorial
Using the current_user object with Secure Zones
Preventing Duplicate Content with Query Parameters- Canonical URL and Robots.txt
FAQ
GraphQL
Tutorial Overview
About GraphQL
Tutorial 1- Your First Query
Tutorial 2 - Pagination
Tutorial 3 - Filtering the Results
Tutorial 3 - Answers to the First Filtering Challenge
Tutorial 4 - Advanced Filtering
Tutorial 4 - Challenge Answers
Tutorial 5 - Using Liquid to run GraphQL queries on your Site
Tutorial 6 - Variables
Tutorial 6 - Answers to the Variables Challenge
Tutorial 7 - Sorting
Tutorial 8 - Building a Liquid API GET Endpoint Page powered by GraphQL queries
Best Practice and Performance
Module/WebApp Caching
Getting Started with Liquid Caching - to Reduce Server Response time and Improve Performance
Includes
ecommerce/checkout_standard
Frequently Asked Questions
Using Liquid Logic to Check if a field exists, or is empty on the Front End
How do I learn more about Liquid?
How to setup a multi domain start page
Docs powered by archbee 
14min

Understanding Custom Field Names and IDs

Each WebApp and Module has specific custom fields. Each field has a human-readable name and a database ID.

Introduction

WebApp custom fields are designed to be used by Agencies and Clients to store whatever they need. Each field is designed to be flexible and reliable. To achieve this we give each field two names by which they can be referred to in the code:

  • Custom Field ID e.g. "webapp_field_1_2". Usually in the syntax, you refer to this prefixed by properties e.g. properties.webapp_field_1_2.
  • Name - the human-readable, editable name. e.g. "Manufacturer's Instructions"

How do I find a field's Custom Field ID?

With the Siteglide Admin In Admin, you can find the Custom Field ID by navigating to any WebApp Item in the WebApp. You can then display the Custom Field ID against each field by turning on the following toggle:

Document image

The Custom Field ID will always have the following format:

webapp_field_x_y ...where x is the ID of the WebApp the custom field belongs to and y is given to the field in the order the Custom Field was created. For example, the third field created on webapp_5, would have the Custom Field ID of webapp_field_5_3.

With Liquid Inside your WebApp Layout, you can output the entire JSON data structure for the Item using:{{this}} Inside this, the Custom Field IDs tend to be stored inside the properties object- this shows the original structure of fields in the results. Outputting the following will show you a list of Custom Field IDs and their values for this item: {{this.properties}} Using your favourite JSON parsing tool, you can read this JSON and identify each field by its contents. You can see a third party comparison of JSON tools here, to help you pick your favourite: https://geekflare.com/json-online-tools/

Why do we need two ways to refer to the field?

The actual name of the field in the Database is the Custom Field ID. This fulfils an important functional role. The key points are:

  • It always stays the same - meaning you can always reliably access the data stored in the field
  • It has a format easily accessed by code- which in some specific cases can mean using it will make your Pages faster. (We'll list some common Use Cases later.)

We also provide a human-readable Name for each field. That's what is chosen when Agency or Client create the WebApp. This lets you:

  • Know exactly what the field is for when managing your WebApp items in Admin and outputting them in Layouts.
  • Change the Name whenever you like
  • Use spaces in the name

When is the Custom Field ID useful?

Most of the time when you're working in Layouts, you can refer to the field by its name. This is easier for the developer as it becomes self-evident what the field's role is.

However, when you're working on some features, the documentation will ask you to refer to the field by its Custom Field ID. This is because for some features, better Page load speed is achieved using this more direct way to refer to a field and we want to pass on the benefits of this advantage to you. Here are examples of some of the Articles where we'll ask you to use the Custom Field ID:

  • When sorting WebApps
  • When filtering WebApps with "use_adv_search"
  • When pre-fetching Datasources

What about Modules, Custom Fields, and Custom Field Sets?

When working with Modules and their Custom Fields; you can use the Toolbox within Code Editor to find these Custom Fields and their associated code.

Many of their fields will also have Custom Field IDs. These are also used when sorting and filtering for better performance. The main difference is in the format: module_field_x_y instead of webapp_field_x_y.

Custom Field Sets also have Custom Field IDs which are commonly used when accessing them.

Updated 19 Oct 2021
Did this page help you?
Yes
No
UP NEXT
FAQ
Docs powered by archbee 
TABLE OF CONTENTS
Introduction
How do I find a field's Custom Field ID?
Why do we need two ways to refer to the field?
When is the Custom Field ID useful?
What about Modules, Custom Fields, and Custom Field Sets?