Pages

Property Management

Property Management controls how fields are structured and displayed in the module item editor. You can define which fields are visible, group them into named sections, and configure their layout - giving content editors a cleaner, more focused editing experience.

Sections and fields are arranged on a 12-column grid, the same layout system already used in the analytics dashboard. Items automatically wrap to the next row when two adjacent items exceed the available width. This grid also supports wide-screen displays - the overall admin content area scales up to approximately 2400px on large screens, sections on the item edit page scale up to approximately 1500px, and edit groups scale proportionally to screen size.

Access Property Management from the module list view by clicking "CONFIGURE" and selecting "Property Management". The interface is split into two panels: 'All Properties' on the left and 'Visible Properties' on the right.

A "PREVIEW" button, next to "SAVE" at the bottom of the page, opens a live preview of the item Create/Edit form - showing field types, their configured widths, and section placement based on your current Property Management setup, without leaving the page.

Removing a field from the item editor using "Move To All Properties" only visually hides it from the editing UI - the field is not deleted from the system and its stored data is preserved.

All Properties

The left panel displays all properties that are not currently assigned to any section in the editor layout. It is divided into two groups.

'System Properties' lists the built-in platform fields available for this module - such as Categories, Tags, Author, Parent, Template, and Layout. Drag any system property into a section on the right to make it visible in the item editor.

Drag and drop multiple properties at once by selecting multiple properties using the Cntr (Windows), or Command (Mac) key while selecting the properties. Selected properties are shown with a style clearly distinct from the ordinary hover state, making it easy to see which fields are included in your selection.

A "Search" field at the top of the page allows you to quickly locate any property across both the 'All Properties' and 'Visible Properties' panels.

Visible Properties

The right panel defines the actual structure of the module item editor. Only properties placed in sections here are rendered when an admin creates or edits an item. Fields are arranged on the same 12-column grid used for sections, and each field can be assigned a width from col3 to col12 using the grid control on the right of each property row. By default, a field spans the full width of its row (col12). If two adjacent fields do not fit within the remaining columns of a row, the second field wraps to the next row.

When the screen width drops below the responsive threshold, all sections and fields collapse into a single column and your configured widths are overridden to full-width.

Click the options icon () on any property row within the 'Visible Properties' panel to access per-property actions.

Sections

Within the 'Visible Properties' panel, fields are organised into named sections. Sections help content editors navigate the item editor more easily, and can be reordered, renamed, resized, and permission-controlled independently.

The 'Item Settings' section is mandatory. It is always present, cannot be removed, and always contains the required "Name" and "URL" fields. Some system sections become available only when specific functionality is enabled - for example, enabling bookings makes an Event Properties section available.

Create New Section

Add new sections using the "+ Create New Section" link at the bottom of the 'Visible Properties' panel.

Click the options icon () on any existing section header to manage it.

Frontend Form Code and Property Management

When generating Create/Edit form code for frontend submission of items (via the Component Manager), input fields are grouped and ordered to honour the Property Management configuration, including section headings. All fields are included in the generated form code, with non-visible properties placed in a section titled "Other".

Layouts

Layouts are the containers for an item's data to be rendered into, along with your custom markup. They are output by way of their associated component tag.
eg:

{% component type: "module", source: "Blog", layout: "List" %}

When the component is output it loops through all of its relevant items and renders their data into the specified Layout, as defined by the layout parameter of the component tag.
In other words, the Layout acts as a type of template for displaying the Blog's data.

You create your HTML markup or custom code and insert something similar to “data merge tags” by way of Liquid objects (eg: {{this['name']}} would render the item’s name).

From the Blog Layouts screen you’ll also have access to the Blog Post Layouts as this is a grouped module.

List Layouts

Layouts of type ‘List’ are typically used for rendering repeating data sets. So, if the component you've configured retrieves 3 items, the List Layout will be rendered 3 times, each with a different item’s data being inserted within a defined markup.

Here is a simple example of how the Layout works, rendering a heading with the item's name as a link:

<div>
    <h2><a href="{{this['Url']}}">{{this['Name']}}</a></h2>
</div>

Using the example above of 3 items, the result on the website's front-end would look something like this:

<div>
    <h2><a href="/module-url/Blog-1">Blog 1</a></h2>
</div>
<div>
    <h2><a href="/module-url/Blog-2">Blog 2</a></h2>
</div>
<div>
    <h2><a href="/module-url/Blog-3">Blog 3</a></h2>
</div>

Detail Layouts

Layouts of type ‘Detail’ are typically used for rendering a single item's detail view, as displayed when browsing to that item’s unique URL.

Here is a simple example of how the detail Layout could look, rendering a heading with the item's name and the item's description field:

<div>
    <h2>{{this['Name']}}</h2>
    <div>
        {{this['Description']}}
    </div>
</div>

So, as per the example above, if viewing the first Blog, the Layout would render something like this:

<div>
    <h2>Blog 1</h2>
    <div>
        This is the description content of Blog 1.
    </div>
</div>

Blog Specific Layouts

Since Blogs are a grouped/nested module, when calling the parent module in your component tag, the parent’s Detail layout is configured to then list the child items via the child component tag.
So, the default Blog detail layout, called “General Blog Layout”, looks something like the below - calling the child Blog Post component filtered by its parent ID:

<div>
    <h1>{{this['Name']}}</h1>
    {% component type:"module", source: "Blog Post", layout:"List", filterBy:"parentid", filterValue:"{{this.id}}" %}
</div>

Therefore, if your site had 3 parent Blogs each with a child Blog Post, the Layout would render something like this:

<div>
    <h1>Blog 1</h1>
    <div>
        <h2><a href="/module-url/Blog-1/Blog-Post-A">Blog Post A</a></h2>
    </div>
</div>
<div>
    <h1>Blog 2</h1>
    <div>
        <h2><a href="/module-url/Blog-2/Blog-Post-B">Blog Post B</a></h2>
    </div>
</div>
<div>
    <h1>Blog 3</h1>
    <div>
        <h2><a href="/module-url/Blog-3/Blog-Post-C">Blog Post C</a></h2>
    </div>
</div>

Adding/Editing Layouts

You have the freedom of editing these layouts as you need to, with any HTML, CSS or JS as appropriate for your project. As well as creating unlimited, additional layouts.

Click the 'CREATE NEW' button at the top and choose which grouped module you wish to add a list or detail layout for.

You can then add your custom markup and insert dynamic Liquid objects into your layout. Using the ' Properties' manager (found at the top right of the editor), simply click on the desired Liquid object name from the list to have it inserted at your cursors position within your markup, or click on the copy icon () to copy it to your clipboard.

Additionally, you can even add other modules inside of these Layouts, just as you might insert them onto a regular page. Simply click on the ' Components' manager (found at the top right of the editor) and follow the prompts to configure any additional component tags for the desired data output.

Table

This setting allows you to customise the column headers in the table/list view of module items in the admin. Allowing you to provide a better editing experience for you and the site admins.

For example, looking at a list of products, you’d likely want to see, and sort by, different columns of data than you would for a list of gallery slides or a list of staff members.

Reposition or Remove Table Columns

The Tables interface shows a representation of the current column headers which can be repositioned (via drag and drop), or deleted (via the x () icon, shown on hover).

Any changes made to the headers here are saved automatically.

Editing Table Columns

You can add additional columns to your module list view by clicking the “Add New Column” button, or you can edit existing ones via the pencil () icon (shown next to the column label on hover).

Column options are as follows:

Views

There are 2 different list views your Page items can be configured to display in, or switched to via the icons ( ) in the top right of the item view.

Depending on how the module is configured, some or all of these icons may be visible and the default view may be different to that of how other modules display.

List View ()

A direct listing of all the current module items, in a tabular layout, which can be clicked on to access their content. A typical view for singular, self contained modules.

Tree View ()

Relevant for nested module structures, this view shows all current module items, in a tabular layout, as folders (parent items) which can be clicked into to access a List View of their child module items.

Filtering, Sorting and Saved Views

Above the module item list, a single control panel brings together search, filtering, sorting, and view switching.

Any combination of applied filters and sort order can also be saved for later reuse - see 'Saved Views' below.

Filter By

Click "FILTER BY" () to open a dropdown containing all of the list's available filters. Set the filters you need, then click "APPLY" to update the list, or "RESET" to clear the dropdown's fields back to their defaults.

Sort By

Click "SORT BY" () to open a dropdown for setting the list's sort order. Set the "Column" and "Direction", then click "APPLY", or "RESET" to return the dropdown to its default state.

The field the list is sorted by. Available fields depend on the module's configured list columns (see 'Table' above).

Clicking a column header in the table also sorts the list by that column, and stays in sync with the "SORT BY" control - using either method updates the same underlying sort.

If the module has "Enable drag and drop order" configured, the "SORT BY" popup also includes a "Manual Order" checkbox for switching to drag and drop ordering - see 'Manual Order (Drag and Drop)' below.

Applied Filters and Sorting

Once one or more filters or a sort order is applied, they're displayed as removable chips below the search field. Each chip shows the filter or sort in a short format, for example: "Last Updated: Last 7 days" for a filter, or "Sort by: Name (Asc)" for the active sort.

Click the close icon () on an individual chip to remove just that filter or sort, or click "Clear All" to remove everything at once.

Alongside the chips, a "Save View" action lets you save the current combination of filters and sort as a reusable view - see 'Saved Views' below.

Saved Views

Clicking "Save View" opens a modal where you can name and save the current filter and sort combination. Enter a name in the "View Name" field and click "SAVE" to save it, or "BACK" to close the modal without saving.

Once at least one view has been saved, a "SAVED VIEWS" () control appears in the panel, next to "SORT BY". Its dropdown lists every saved view, with a checkmark shown next to the currently active one. Selecting a saved view immediately applies its filters and sorting to the list.

Select "Manage Saved Views" at the bottom of the "SAVED VIEWS" dropdown to open a panel listing all of your saved views. Each entry shows the view's name alongside a delete icon () for removing it. Use "CANCEL" to close the panel without changes, or "SAVE" to confirm any deletions.

Manual Order (Drag and Drop)

Module items can be manually reordered by dragging and dropping them in the item list, powered by the system property "Enable drag and drop order" (Liquid alias DnDOrder). Once enabled on a module, you can visually reorder items in the list and reference the resulting order in your Liquid components and the On-Site Editor.

Enabling Manual Order

To use manual ordering, add the "Enable drag and drop order" system property to a section in Property Management. It appears in the 'All Properties' panel alongside the other system properties and can be dragged into 'Visible Properties' like any other field.

The property's internal field name and Liquid alias is DnDOrder.

You can also add "Enable drag and drop order" as a column in the item list via the 'Table' tab, to display each item's current order value alongside the drag handle. However, this is not required to enable drag and drop ordering.

Drag and Drop Mode

A "Manual Order" checkbox is available at the bottom of the "SORT BY" dropdown option above the table list. When checked, the list is sorted by DnDOrder as the primary sort key, layered on top of the selected secondary column and direction.

When "Manual Order" is active, the item list switches into drag and drop mode:

• A drag handle () appears on the left of each row, and the row selection checkboxes are hidden.
• Dragging a row swaps the DnDOrder values of the two items involved. Other items in the list are not shifted.
• The bulk "Move to Trash Selected" action in the toolbar is replaced by a "Reweigh" action - see below.

Manual Order and drag and drop reordering are only available in 'List View'.

Reweigh

"Reweigh" reassigns sequential values (1, 2, 3, ...) to all items in the module - not only those visible on the current page - based on the current table sort order. Existing DnDOrder values are overwritten.

Clicking "Reweigh" opens a confirmation dialog to confirm the action.

Reweigh overwrites existing DnDOrder values for every item in the module. This action cannot be undone.

Sorting Logic

When items are sorted by DnDOrder, it is used as the primary sort key. For items that share the same value (such as multiple items at 0), the following secondary keys are applied in order: name, then Release Date, then create date.

Empty DnDOrder values are treated as 0, and appear at the top of the list when sorting ascending.

Editing DnDOrder Values

DnDOrder behaves as a standard property and can be edited through any of the following:

• Drag and drop in the item list
• "Reweigh", for bulk initialisation or resequencing
• Export to Excel, editing the value, then re-importing - see 'Import / Export' above
• The item detail page, if the property has been added to a section in Property Management
• The frontend item create/update form
• Via On-Site Editor (when correctly configured)

Liquid Support

DnDOrder is a supported value for a component's sortBy parameter, and is exposed on items as 0.

For example:

{% component source: "ModuleName", layout: "List", sortBy: "DnDOrder", sortOrder: "ASC", type: "module" %}

On-Site Editor

Drag and drop reordering in the On-Site Editor (OSE) requires all of the following:

• "Enable drag and drop order" is enabled on the module
• The Liquid component uses sortBy: "DnDOrder"
• The layout includes the required DnD data attribute (See the OSE article for instructions)

Import / Export

Found under the main auxiliary menu (), you can import/export data to/from your Pages module where you can then further update your items in bulk using a spreadsheet application and re-import item data in an Excel file format (.xlsx).

If re-importing to update existing items, be sure to maintain the same 'External ID' values from those exported items.

Export the current items in order to get a template import file you can use for importing new data. If you're starting from scratch, first create a dummy item with some sample data so you can see the import format needed.

When re-importing existing items, most spreadsheet columns can be omitted, and those fields will remain untouched by the import. Only the 'External ID' and 'Item Name' columns are required.

Import for Nested (Parent/Child) Modules

Nested modules include eCommerce (Products/Catalogs), Pages, Blogs, Events, Banners, Galleries & Sliders, FAQs, and any Custom Modules that have been configured to ‘Allow creating foreign items from other existing Custom Modules’.

The import file for such child modules will include a ‘Parents’ column which allows the imported item (row) to be assigned to a parent item (or its root level) via it’s URL path/slug. Or even multiple parents, if ‘Allow multiple parent items’ is configured in the parent module.

For example; if we have a parent module called “Web Technologies” with an item called “Javascript” and we wanted to assign an item from a nested module to it, we would include the following path in the child item’s “Parent” column cell: /web-technologies/javascript

The item’s full URL would then become /web-technologies/javascript/item-name

And if assigning to multiple parents, we would include each parent item’s slug separated by a semicolon (;), like so: /web-technologies/javascript;/web-technologies/liquid

Similarly, if we want to assign the child item to the root level parent module, include the module slug without any parent item slug included: /web-technologies

If the import file for the child items has empty ‘Parent’ cells or if the column is not present, the child items will be imported into the view you initiated the import from. So if you are viewing the parent items in ‘List View’ or are at the top level/root using ‘Tree View’, the imported items will be assigned to the root level of the parent module. Likewise, if you have navigated into a parent “folder” and initiate the import process, the child items will be assigned to the currently viewed “folder” (only if the Parent cell is empty or omitted from the file).

You can also assign child items as parents to other child items, in the same module, during the same import process. For example; if we have two child items called “Number type” and “Integer” an wanted “Integer” to be a child of “Number type”, then it’s Parent cell value would include the parent module’s root slug and the target child item’s slug, like so:
/web-technologies/number-type

Resulting in the item’s full URL to become /web-technologies/number-type/integer

The sequence of the imported items in the spreadsheet is not important here. They can be in any order.

URL Conflicts

If, upon attempting to create an imported item with the constructed parent/child URL, the URL already exists in your site, the item will be handled in one of two ways (based on the site’s setting in ‘Settings’ > ‘Misc’ > ‘Disable autocomplete for already taken URL slugs’):

• If setting is unchecked (URL autocomplete enabled) then the conflicting URL will be appended with an incrementing number.
• If setting is checked (URL autocomplete disabled) then the import will present an error for that item and skip any update/creation of the item.

URL list column

The ‘URL list’ column in an export file is for export display purposes only (to display a full construction of both parent and item slug paths). This column is ignored for imported data and item URLs are determined by the individual parent and slug values.

Other Errors

The import process will present an error of each imported item if any of the following conditions are encountered (and will skip that item from being updated/created):

• If multiple parent slugs are included in the Parent cell but the module is not configured with the setting “Allow multiple parent items”
• If multiple parent slugs are included in the Parent cell and one or more of those slugs do not match any existing parent module items (missing parent items will not be created during import).
• If the slug included in the Parent cell is the same as the item slug being updated/created (cannot assign itself as parent).

If an error is thrown on a child item that is elsewhere assigned, in the import file, to be a parent to other child items, then all of those child items will also be skipped during import, since their parent cannot be created.

Deleting

Found under the main auxiliary menu (), you can delete ALL Pages in bulk using the "Delete All Items" option.

Additionally, you can make bulk selections from the item list view (by ticking the checkboxes on the left of each item) and click the "DELETE SELECTION" button that will appear at the base of the list view.

Individual items can be deleted either by expanding the auxiliary menu to the right of each item and selecting the "Delete" option or when on the item's edit page, click the trash can icon () in the lower right of the page.

Bulk Apply Template

After making a selection of module items, using the checkboxes to the left of each item, an “Apply Template” option will become available in the main auxiliary menu () allowing you to assign a template, in bulk, to the selected items.

Settings

SEO

Component Tag with ‘isSearchResult’

To render the search results to the page and/or a collection, you need to configure the module’s component tag with the isSearchResult parameter set to true (see the Page component documentation for technical details).

{% component type: "module", source: "Page Folder", layout: "List", isSearchResult: "true" %}

This will allow the component to reference search parameters in the resulting URL.

URL search parameters will override any corresponding parameters in the component. If no search parameters are present in the URL, isSearchResult will be ignored.

You may want to separate the search form from the component tag if you want a dedicated search results page, or where you have a search input in the header or footer of all pages as so searches could be made from any page.

This method also alleviates a side-effect of the isSearchResult configured component whereby it will output all indexed items by default if no search query has been specified (ie: when a user first navigates to a search page).

If you do want one single search page, with both search form and component and don’t want to initially list all results, another solution to this is to wrap the component tag in a Liquid condition which looks for the presence of the prop_KeyWords parameter in the URL, like so:

{% if request.request_url.params.prop_KeyWords %}
    {% component type: "module", source: "Page Folder", layout: "List", isSearchResult: "true" %}
{% endif %}

Basic Search Form

A basic keyword based search form for Pages would be constructed like the following:

<form>
    <input type="hidden" name="prop_ModuleId" value="1234">
    <label>Keywords</label>
    <input type="text" name="prop_KeyWords" maxlength="255" value="{{request.request_url.params.prop_KeyWords}}">
    <input type="submit" value="Search">
</form>

This form element includes a prop_KeyWords text input, prop_ModuleId hidden input, a submit button and no form action attribute.

The prop_ModuleId hidden input tells the search which module to search (replace ‘1234’ with the ID of your module).

The prop_KeyWords text input allows multiple keywords to be entered for searching.

The search logic combines multiple keywords with an AND operator, so items will be returned only if they include ALL keywords entered.

Currently, searching does not support any manual logic operators to be used in the keyword input field (such as; AND, OR, NOT...)

When the form is submitted, prop_ModuleId and prop_KeyWords, along with their values, will be passed as URL parameters for the isSearchResult configured component tag to interpret.

By default, the search form has no action attribute, so it will redirect to the current page with the URL parameter appended to the current page URL.

You can, instead, separate the search form from the ‘site_search’ component, having the module component on a separate page and sending the search query to that page instead of the current page.

To do this, you’d add the other page URL slug to the form element. So if the other page was “/search-results”, you’d adjust the form to include an action attribute as such:

<form action="/search-results">

Advanced Search Form

Building further on the basic form structure above, you can add Page specific fields to search their contents, either individually or combined with other fields and/or keyword queries.

The search logic combines all field queries with an AND operator, so items will be returned only if they include ALL the queries entered.

The fields (providing they are available to the module) that can be search upon include:

• Name
• URL (Slug)
• SKU Code
• Release Date
• Expiry Date
• Site Search Keywords
• Rating
• Description
• Any ‘Default Properties’ (eg: Categories, Tags, Author...)
• Any ‘Custom Properties’
• Module specific ‘System Properties’ (Price, Product Dimensions, Unit Type, Capacity...)

To add these fields to your search form, create an appropriate input with the name attribute configured like prop_PropertyName.

So, if you were adding a search field for a custom property called “Vehicle Colour”, the form input might look like this:

<input type="text" name="prop_VehicleColour">

Follow this same format for most other properties. Although you may like to change the input type to suit the type of data required.

For example, if our above “Vehicle Colour” property was actually a dropdown field with predefined colour values, you may choose to create a <select> element instead, like so:

<select name="prop_VehicleColour">
    <option value="Red">Red</option>
    <option value="Blue">Blue</option>
    <option value="Green">Green</option>
</select>

After the search form has been submitted, you might also like to keep the search queries filled in the search form fields, for better usability. So to do this you can pull the query parameters out of the URL and into the input values, like so:

<input type="text" name="prop_VehicleColour" value="{{request.request_url.params.prop_VehicleColour}}">

Search Within Number Ranges

For property types such as dates, prices, ratings and numbers, you can search with a to-from/min-max range by adding _Min or _Max to the property name.

So let’s say you want to search for items within a certain date range, based on their release/expiry dates.

<input type="datetime-local" name="prop_ReleaseDate_Min">
<input type="datetime-local" name="prop_ExpiryDate_Max">

And to populate these fields with the searched values:

<input type="datetime-local" name="prop_ReleaseDate_Min" value="{{request.request_url.params.prop_ReleaseDate_Min | date: "%Y-%m-%dT%H:%M"}}">
<input type="datetime-local" name="prop_ExpiryDate_Max" value="{{request.request_url.params.prop_ExpiryDate_Max | date: "%Y-%m-%dT%H:%M"}}">

Searching for a minimum release date will return all items with a release date newer (or the same as) the query date. And likewise searching for a maximum expiry date will return all items with an expiry date older (or the same as) the query date.

Programmatically Search (without a form)

There may be times when you require the search results for a module based on constructed data, other than that of a user’s input into a search form.

You can achieve this with the use of the searchScope parameter on the module’s component tag (see the Page component documentation for technical details).

This parameter allows a search on the module without search parameters needed in the URL. Instead, search parameters are added to the value of this parameter. Therefore, this parameter can be used to output module specific search results from hard-coded (or Liquid constructed) values without the use of a search form.

The search queries are similar to that used in the above form based search method, but use JSON syntax for their construction.

Below is an example of a constructed searchScope configured component tag, with min/max release date search, keywords and multiple tags query:

{% component type: "module", source: "Page Folder", layout: "List", searchScope: "{'prop_ReleaseDate_Min':'2018-07-01', 'prop_ReleaseDate_Max':'2018-07-31', 'prop_KeyWords':'Your Keywords', 'prop_ItemTags':['tag1','tag2']}" %}

The search logic combines all field queries with an AND operator, so items will be returned only if they include ALL the queries entered.