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 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