We're constantly putting together Tutorials and Guides to help you get started with each area of Siteglide.

Build Better AND Faster with SiteBuilder

Want to build from scratch?

Siteglide Command Line Interface (CLI)

Build and Manage Pages

Build and Manage Forms

Automate Processes with Automations

Use Our API to Integrate with Other Tools

Siteglide allows agencies to take control over code and data via API, CLI or UI. With the right blend of out-of-the-box tools and freedom to develop - without limits.

Where do I start?

If you're new to Siteglide we recommend starting from a pre-built Template that leverages our SiteBuilder tool: Create Site From Template.

If you're looking for help with a site and not sure where to look you can check out our Quickstart Guides.

If you're already working on a site and you're code savvy we strongly recommend setting up our CLI so you can get the most from Siteglide via VSCode or your preferred IDE: Quickstart: CLI

Looking for something else? Use the Search (top right) or navigate through the left menu which is organised to match the menu you will see in Siteglide.

Types of Articles

1. 🚀 Quickstart: Bare essential guides with links to more detailed articles if you get stuck

2. ℹ️ About / Introduction: A brief overview of the topic

3. 📋 Step by Step Articles: How to Implement a Feature or Solve a Problem

4. 💡 Concept: Will take a feature and explain it in a little more depth

5. 🏗️ SiteBuilder: How to get setup and get the most from the SiteBuilder module

6. 💻 Reference: A brief reference guide to this feature for developers and anyone interested in code

7. 🌳 File Structure: This will show you which folders and files are necessary and where to add them to your codebase. This will be presented in the format from which you would see it in Siteglide CLI

8. ❔ Troubleshooting: Find answers to common challenges

9. 🧙‍♂️ Go Further: This is where you'd find more detailed docs that help you really push the boundaries of all things web development

10. 🔗 API: Endpoints and articles related to our API

11. 🛳️ Changelogs: Releases, Updates and any important changes to Siteglide

12. 💳 Billing/Account: Articles related to Billing, Payments and Subscriptions

13. 👩‍💻 Agencies: Articles specific to Digital Agency partners

The Users page in Siteglide Portal shows you all the Users in your company:

It's important to understand User Roles and how to control what other users can see and do:

Ready to invite Users to your account?

Some useful Liquid tags:

You can view who has access to the site on the Users tab as well as invite existing users to the site.

You can only invite existing Siteglide users to Sites, you might be working with an external Siteglide Expert, you would give them access to this Site here.

Want to invite new Users to your account?

If you're looking to invite your own team to manage the site you would need to add them to your Account:

You might want to have www.example.com on one Siteglide instance and app.example.com (or any other subdomain) on another Siteglide instance.

1. First add your subdomain to the second instance as a new domain:

1. Then go to the DNS records of your fully delegated domain and create a CNAME as follows:

This will use the SSL certificate from the top level domain and resolve correctly to the new instance.

This is where you manage Account users, they would get access to all sites in your Portal

Invite Portal Users

To invite users to your Account you can only do this from the Users tab on your Account (your company name in the left menu):

You will not see the blue invite button on the Users page (left hand menu Users link):

If you click a user you can see what Sites they have access to and their User Role:

Find out more on Users and User Roles:

Want to Check what Plans are Available?

Ready to Go Live? Add a Payment Method

Looking for Invoices?

Simply fill in the form to add your card details to the Account. Please note this card will be used for ALL payments unless otherwise stated on the Go Live tab.

If you haven't previously setup Billing on Siteglide it will ask for your Company Name and Address:

If you already have a card on file with us it'll show the last 4 digits but you can replace this card with a new one:

Want to Add a New Domain?

You can either Fully Delegate your DNS to Siteglide or manage it externally:

Ensure Email Deliverability

With the increasing challenges faced with spam there are now stricter rules for email deliverability but there are some simple steps you can take to ensure your emails hit the inbox:

Ready to build a Site?

Need to Invite or Manage Users?

Want to Install or Manage Modules?

Ready to Go Live or Need to Manage Domains?

What is GraphQL?

Ready for some Tutorials?

Here I will outline key tips and information in maintaing your existing module once it has been created.

Maintaining Your Git Repo

When anyone (yourself or someone else) installs your module, it will automatically take a copy of anything currently within the master branch of your Git Repo.

If you would like to work on updates or new additions to your module, it is strongly recommended that you create a new branch in your repository so that it does not impact what is installed until your are ready.

Create a new branch and call staging for example. From now on, send your initial commits to staging while you are testing. When you are ready to release an update to your module, merge into the master branch in Git.

Notifiying Users Of An Update

Once you have committed a new version to your master branch in Git, edit your module in Siteglide Portal to update the version number and let people know there is a new version available to install.

June 25, 2024

We strive to support all recent versions of major browsers front-end JavaScript features that we deliver to your site, such as eCommerce or Forms.

For the sake of security and providing the best experience to the majority of customers, we do not support browsers that are no longer receiving security updates and represent a small minority of traffic.

Supported browser versions

• We support Edge v79 onwards per . We do not support Legacy Edge or Internet Explorer versions as they are .

• We support Chrome, Safari and Firefox on desktop platforms.

• We support the Android native browser on Android 4.4 and later.

• iOS and iPadOS version 10 and later. This also includes browser variants on iOS such as Chrome, Firefox, Brave etc.

• We respond to bug reports but do not proactively test other browsers.

If you have any system related issues in the browsers above then please don't hesitate to contact us for support.

Check and update your browser version

We recommend always using the latest browser version available to your operating system for the best support and security while using the internet. You can use the links below for your browser’s documentation to learn more about checking and updating your version:

For Safari, and Microsoft Edge browsers, this may depend on your device's operating system so check your OS is up to date as well.

Click the 'Sites' button in the left hand menu in Portal to see your list of sites, then click the Name of the site you want to view the settings for:

This is where you manage the site including Users, Modules and the Subscription:

Details Fields:

• ID - Unique identifier for this site

• Site Name - Name of the site - this can be edited

• URL - The site's live or developmental URL - this can be edited (keeping the same format. e.g. Staging/Trial Sites = https://sitename.staging.oregon.platform-os.com/ and Production/Live Sites = https://sitename.prod01.oregon.platform-os.com/ )

• Status - This will be 'Trial', 'Trial Expired - Locked', 'Trial Expired - Redirected' or 'Live'.

• Datacenter - One of three datacenters that was picked when this site was created (London, Oregon, Sydney)

• Company (listed as Owner in 'Sites' area) - The Agency or Client that owns this site

• Create Date - The date that this site was created

• Created By - Email address of the user that created this site

• Latest Activity - The date that this site was last edited

• API Key - You can click here to reveal your key

• CLI Command - A shortcut to add this Site to CLI to begin working with, e.g:

Note: Here, you can also see how long is left on your trial. When your trial has reached 0, an email will be sent out to the agency who owns this site, and this site will enter the expiry flow.

• You can extend this trial by clicking 'extend' next to the Status. Sites will automatically extend their trial when users visit this site's admin or connect to this site via CLI.

• After 14 days of this trial being locked and with no user extending this trial; a reminder email is sent out and this Site will now redirect to https://www.siteglide.com/ .

• After 13 days of this trial being redirected; another reminder email is sent to notify the agency owner that this Site will be deleted if no action is taken.

• After 1 day of this second email being sent out, this trial Site will be locked and greyed out in Siteglide.

• Within 24 hours of this site being greyed out, this Site will be fully deleted.

Using the buttons at the bottom, you can also 'View' this site, edit this Site's 'Admin', 'Save' any changes made to the name or URL, or 'Delete Site'.

User Roles determine what users can see and do within Siteglide. Account owners have granular control over this and can set others as Admins or limit what they can do.

Manage Roles

You can then change or add additional Roles for that User:

Roles stack, so you can have multiple different roles and receive a combination of permissions. This allows you to split your desired permissions into blocks, and apply them where needed without having to create specific roles for every user.

Create a New User Role

To create a New Role just give it a name and select the granular controls they have access to:

You can also copy permissions from an existing role to save time:

See Roles Assigned to Users

You can see what Role a User has by clicking the Roles tab on a User:

Access limits based on 'User Level'

A user has a 'User Level' of either 'Agency' or 'Client'. This is independent of their precise roles, and inflicts some limitations that are permanent and cannot be overcome by editing User Roles.

If the User Level is set to 'Client', then the Portal view is limited to:

Site List Site Details Client Profile User Profile Billing Setup, Plans, and Invoices (only shows if paying Siteglide directly)

Other restrictions:

Gist/Live Chat - Cannot access, so they have no direct line of communication with Siteglide and must instead to their agency Sites - Cannot see status, so they're not informed of any billing issues (Payment Failed) Billing - Cannot see anything related to Reseller Programme Client - Cannot edit 'Payee' to set to themselves as paying Siteglide directly

Site view has no limitations, and a client user has the same feature access as an agency user (unless limited via User Roles)

Next Steps:

Sites can be automatically upgraded to the next available plan on the 1st of the following month if the cost of Extras exceeds the difference in cost to upgrade to the appropriate plan. Automatic upgrades by the system ensure that if usage increases on a site, the cheapest option is chosen and charged.

The default "Agency Global Preferences" is to not allow automatic upgrades. The "Site Preferences Override" has no override set and so will follow your Agency Preference. You can change this setting by following the information below.

Setting Up Your Automatic Upgrade Preferences

Site owners and agencies have granular control over automatic upgrades via Siteglide Portal. You can choose to control the setting either Globally for all of your sites, or individually for specific sites.

Please ensure you set this up to suit your billing preferences.

Agency Global Preferences

Within your in Portal, you can choose for the default setting to enable or disable automatic upgrades for all sites within your Agency and Clients.

The "Automatic Site Upgrades?" toggle can be set to two different states:

• Yes - Automatic upgrades are turned on for all sites unless you override at site level. Upgrades will take place if it is cheaper than paying Extras

• No - Automatic upgrades are turned off for all sites unless you override at site level. No upgrades will take place unless you action them yourself

Once you have chosen a state, make sure to save.

Note: This preference can be overridden by a selected state applied at the site level.

Site Preferences Override

Within the for a site, you can choose to override the global preferences and control each site separately.

Above the peak usage table, you'll see the current state for this site and an option to change this.

Click "Change" to open a pop up modal, where you'll be shown the current state for this site and an option to override Global Preferences in two ways.

To override, tick the "Override?" checkbox and select the appropriate state you would like to apply as an override.

To remove an override, untick the "Override?" checkbox.

An override can be set to either of the following states:

• Automatic - Automatic upgrades are turned on for this site only. Upgrades will take place if it is cheaper than paying Extras

• Manual - Automatic upgrades are turned off for this site only. No upgrades will take place unless you action them yourself

Once you have chosen an override state, make sure you click save.

The Siteglide Marketplace has a variety of useful Modules, Templates, Themes and Integrations.

Core Modules

Some of which have been built by Siteglide so that you can pick and choose which to install onto each site and reduce clutter/usage if they're not required. These are called Core Modules and are denoted by the 'by Siteglide' text under each title:

Find out more about the Core Modules:

Community Modules, Templates, Themes & Integrations

Other Modules, Templates, Themes and Integrations have been built by the Siteglide Community of Experts including our services team, Sitegurus.

Sitegurus have built SiteBuilder, a tool to speed up development of web projects while ensuring best practice and quality. Check out the Marketplace Templates that leverage SiteBuilder:

​Whitelabelling enables your Agency to re-brand the Siteglide portal by replacing our logo with your own. Re-branding the platform in this way means you are able to provide a more consistent, branded and streamlined service to your clients and maintain a single point of contact with them.

Over time we will continue increasing coverage of the whitelabling capabilities to include things like domain name, among others.

Admin Logo

To re-brand your Portal and Admin, head over to the Agency Details page, upload your logo and enable "whitelabelling".

Login

Below is an Endpoint and example snippets of code you can use to enable your Clients to login to Admin directly from your own Agency website.

You'll need the code below as a minimum. You can then add your own HTML/CSS/JS designs and branding on top.

HTML

JavaScript

Siteglide CLI (Command Line Interface) is a tool that enables you to work on your project from your local IDE or Code Editor; it has similar behaviours to FTP (File Transfer Protocol), in that you can sync up and pull down changes from your website.

Who is it for?

Developers will be at home with the Siteglide CLI. It allows them to work faster than they can using the User Interface of the website. It also allows them to access the full suite of time-saving extensions and search tools in IDEs like and .

But it's not just for Developers! Designers, SEO specialists and Agency Leaders may also find benefits to learning and using Siteglide CLI - allowing them to see an overview over their entire project and quickly find the files they're looking for.

How to Navigate Around?

Check the "File Structure" in each documentation topic, and this will help you find your way around the folders and files.

Benefits of CLI over FTP:

Validation

With CLI, we can validate code sent to the site. This is especially useful if you are syncing Liquid or GraphQL code where there are fewer 3rd party tools for linting. If there is a problem we can pick up automatically- the sync will fail and an error message will try to help you find the problem.

Version Control

With Siteglide CLI we can keep track of the Code pushed to the Site from Admin and from local machines and make sure the Site always contains the most up to date pushes. It gives us scope to improve this functionality in the future.

Developer Tools

Other CLI commands like siteglide-cli graphql and siteglide-cli logs provide developers with advanced tools that would not be available with an FTP.

Ready to Start Using CLI?

An Agency only feature is being able to make copies of existing sites either to a blank Staging or to an existing Site (can be a Production Site):

To copy to a new Staging Site click the first radio button and then choose the Site Owner (your Agency or a Client folder) and give the Site a Name/URL:

To copy to an existing site (Trial or Production) click the second radio button and then choose the Site from the dropdown:

This is where you can contact us about an issue by logging a Support Ticket:

Just give it a title, select which site it relates to (if applicable) and please provide as much information as you can:

The Subscription tab will show your Site Usage and what plan you're on or which plan we recommend if the site is not yet Live:

The Records Table shows a breakdown of all Records and how many have been deleted this month:

The pOS documentation covers Liquid comprehensibly and includes Liquid functionality specific to the pOS Platform and Siteglide.

Siteglide runs on platformOS and we use their implementation of Liquid which adds a large range of useful functionality.

The best place to start learning is their documentation, which will explain the different types of Liquid syntax. From there, you can find more helpful documentation on the Liquid topic you are interested in.

Welcome to the Siteglide Site API Docs!

Siteglide is designed to give you total access to your data and to platform capabilities.

If you don't see an endpoint you need you can create your own or contact us if you think it should be platform wide.

Each Siteglide feature has it's own page with the various endpoints:

To find documentation for Siteglide Portal API, please follow this link -

Comfortable with code?

We recommend using our CLI (Command Line Interface).

New to Command Line Interfaces?

You can go further, faster with CLI but it's not for everyone, we recommend reading the following article before deciding:

Already installed CLI?

Useful links once CLI is installed:

You can set your Module up to require payment before a user can install it.

All payments are handled through your Stripe account.

Follow the steps below to add this requirement:

1. You need to link your Stripe account to your Agency in order to take payments. Go to your Agency edit view, and click the 'Marketplace Payment Details' tab. Read the details shown on this screen and then enter your Stripe Secret Key ()

2. Go to the Module edit view, and click the 'Payment Details' tab. Here you can toggle 'Take Payment?' to 'Yes' if it is required.

3. Enter the Stripe Product ID for your Module. This Product will need a Price attached to it in Stripe.

4. Select the Access Type you want to grant. There's 2 options:

   1. User only - This will grant access to the paying User

   2. Agency-wide - This will grant access to the entire Agency of the paying User

5. You can manually manage User/Agency IDs in the 'Access List' field if you need to do so. This field will auto-update when a User pays for your Module.

6. That's it! Now, when a User sees your Module in the Marketplace they'll be required to pay before they can install the Module.

Our Zapier Integration is easy to use straight out of the box and there are workflows setup that you can use:

Formatting Arrays

This section is for developers that want to build Templates and Modules for the Marketplace.

Customise Siteglide to suit your project requirements:

Field Types

There are 3 main components that make up your clients sites that we need to consider in terms of backups and disaster recovery: Code, Assets and Data. We will outline how each are handled below:

Code

• Every code change whether through CLI or Admin is stored in a Github repo controlled by Siteglide

• This also stores the UserID of the user that took the action for traceability

• This is mainly stored for disaster recovery purposes

• You can export using siteglide-cli pull <env>

Assets

• Stored on S3 by platformOS

• AWS/Google Cloud mirror assets across multiple data centres

• You can export using siteglide-cli export <env> -w

Data

• Stored in databases by platformOS

• platformOS have backups and store changelogs/versions of what happened

• Upon deletion, the data is recoverable for 30 days. After 30 days of being soft deleted the data is permanently deleted at 5am UTC.

• You can export data using siteglide-cli export <env>

We will be offering additional backup tools and automations in the future.

PlatformOS also have documentation on Backups and Disaster Recovery.

The following are key points taken from the platformOS documentation:

platformOS automatically backs up your applications and databases using real-time READ REPLICAs which exist across multiple Zones for further physical disaster recovery within a data-center.

Additionally, incremental transaction logs, daily and weekly backups are taken.

The retention period for monthly backups is 60 days.

These processes are internal to the platformOS DevOps team.

Learn more:

• Data Backup and Removal: Learn about how deleted data is backed up and when it is removed permanently. Includes explanation of automatic and manual permanent removal.

• GDPR Compliance in platformOS: Learn how platformOS approaches GDPR as just one of many compliance requirements and ensures that your project can easily comply with any number of government legislated privacy rules.

• AWS Backup: AWS Backup is a fully managed backup service that makes it easy to centralize and automate the backup of data across AWS services.

• Google Cloud Backups: How backups of your Cloud SQL instance work, and how they can be used to restore your data to the same or another instance.

How to check if a variable exists/ is null/ is false?

Not all the variables on Siteglide will be stored as either "true" or "false". In many scenarios something may exist in one location, and simply not exist in another . To better explain this i'll use a homepage as an example:

Whether a page is the homepage or not is determined by the is_homepage variable: is_homepage which has the value true. However if a Page is not the homepage, rather than is_homepage being set to false, the is_homepage variable doesn't exist.

Say I wanted to run some code on every Page that isn't the homepage, I'd write something like this:

{% if context.page.metadata.is_homepage == false %}
   output content.
{% else %}
   output homepage content.
{% endif %}

This would work fine if we were on the Homepage, as the variable's value would be true. However, on other Pages, it would not behave as expected, as is_homepage would be undefined..

Now lets look at the Liquid keyword "blank". This refers to having a value of either: Empty, Null or False.

If I now check "is_homepage" like so:

{% if context.page.metadata.is_homepage == blank %}
  {% comment %}output content.{% endcomment %}
{% else %}
  {% comment %}output homepage content.{% endcomment %}
{% endif %}

This will now work!

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 toggle at the top of the page.

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/ prettifier 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/. You can also install a VSCode extension to do this.

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.

2.0.0 - 25th June 2025

• Migrated to site-hosted API endpoints for more user control and better stability

1.1.2 - 14th April 2021

• added - Get all Categories

• added - Get Individual Category

• added - Create Category

• added - Update Category

1.1.1 - 30th March 2021

• added - Create Product

• added - Update Product

• fixed - When using Get Product endpoints, all attribute options are now displayed as an array.

• fixed - Added missing fields for Product Attribute Options

• improved - Improved the naming of ID's and Related Attribute ID to distinguish between the item ID and its parent. This is on both Product Attributes and Product Attribute Options

1.1.0 - 9th March 2021

• added - Get Module Item(s)

• added - Create Module Item

• added - Update Module Item

• fixed - Zapier - WebApp custom fields would not display when creating/updating an item

• fixed - CRM Custom Fields would not display when creating/updating a CRM user

Account Details

You can manage your company profile and account settings here:

Account Users

This is also where you invite Account level users who have access to all sites:

Simply add a name and email address of a person you'd like to add to the Account:

Sites

This shows all the Sites directly under your account (this will not show any Sites in Client folders):

Launchpad

Launchpad shows you how much of Siteglide you've used and setup. It's a great way to ensure your team learns the platform:

This guide will walk you through the process of creating a new site using Siteglide's admin area.

Step 1: Access the Dashboard

Once you're logged into the portal, you'll find yourself on the dashboard.

If you don't see a 'Create a Website' button (as per 2nd screenshot) please contact us via Live Chat to prove you're human and we'll get you setup!

Once you're account is approved you should see the Create a Website button:

If you already have 1 or more site you'll see options to create a site, manage existing sites, or manage your company:

Step 2: Choose Site Creation Method

You have the option to create a new site from scratch or use a Template.

If you're new to Siteglide or less technical, it's recommended to start with a template because they're built with SiteBuilder, a tool to help you rapidly build and customise websites:

The rest of this Quickstart guide will focus on building a Custom Site. Click the 'Build a Custom Site' button.

Step 3: Name your Custom Site

Give the site a name and it will automatically create the URL. You will need to ensure it's unique, if it turns red please amend by making it more unique. Then click Create Site.

Step 5: Manage Your New Site Once Ready

And that's it! You've successfully created a new site, you will need to wait for it to be ready to use:

You will receive an email when it's done but can also find it under the Sites area:

The Status will show as Trial and there will be a new blue button in the bottom bar that will likely say Sign up for Admin Access if you've not yet used it, otherwise it'll say Admin going forwards:

Next Steps:

Click through to Administer the Site and you'll end up on the Dashboard:

If you're a developer you'll likely want to set up our CLI:

Go to a specific site in Portal and click the Modules tab. This will show all Modules in the Marketplace but it will not show Marketplace Templates because they cannot be installed onto an existing site).

You can filter to see which Modules are installed:

You can filter in the Name field if you're looking for a specific module:

Clicking a module will give you more information:

When ready just click install to install it to that site.

Next Steps:

If you are an approved Siteglide Agency you will have additional features accessible from the tabs across the top:

Community Expert Details

The Community Expert Details tab is where you can brand Siteglide to your Agency and create a page on the Experts area so users in need of your services can find you:

Read more about Whitelabelling Siteglide to your Agency:

Marketplace Payment Details

The Marketplace Payment Details tab allows you to take payments for any Modules you sell in the Marketplace. You would need to use Stripe to take payments and insert your secret key:

Partner Programme

The Partner Programme tab provides more information on how you can partner with us:

Affiliate Programme

The Affiliate Programme tab lets you setup and control the affiliate commission for referring new users to Siteglide:

New to Liquid markup?

Liquid is a templating language (created by Shopify) that helps you build out Siteglide functionality.

Looking for a specific tag/function?

Check out our Reference guide:

Tutorials

Background

When working with Zapier, adding data to arrays needs some extra JavaScript to convert the data. Zapier calls arrays "Line Items" and formats them like so, [123,456,789] whereas Siteglide API expects a JavaScript formatted array such as, ["123","456","789"]

To convert these two data types, use the screenshots and code below. In this example we are getting a pre-existing user and their Secure Zones, then adding in a new item.

Zapier Setup

let data = inputData.sz.split(','); //Where sz is the name of the input data you picked above
let array = [];

data.forEach(item => array.push(item));
array.push("178375") //The ID of your secure zone

output = {output: JSON.stringify(array)};

The above javascript code and flow can be used for anywhere that you need to add an item to Line Items within Zapier

Orders

Products

Which Tools Should I Use to Work with Siteglide?

There are a few main ways to work with your Siteglide Site:

• Using the - Create an Account and use the User Interface to explore and build your Site. If you have any questions, use our live chat button to get help.

• Using the - Efficiently work directly with your Site's code on your own machine.

Which Coding Languages are used in Siteglide?

In the course of this Documentation, you will probably come across the following languages that we use in many of our features and examples:

• HTML - The standard Markup Language of the web.

• JavaScript - The standard client-side scripting language of the web.

• YAML - Used by Siteglide to store settings like page metadata, normally at the top of Liquid files.

• Liquid - Used by Siteglide for dynamic server-side rendering of HTML and other languages.

• GraphQL - Used by Siteglide to query the database and modify data. Often for beginners this will be tucked away inside our features, but learning it allows you to unlock more powerful possibilities.

Partner and 3rd Party Documentation

works very closely with our partners at to provide you with all the benefits of a modern cloud-based infrastructure like AWS, while at the same time making your life easier so you can focus on delivering the best for your clients.

platformOS are behind a lot of the code used on Siteglide sites, developing everything from new Liquid filters on top of Liquid's open-source starting point and a fully functional GraphQL schema you can plug into for making database queries and mutating to modify data. We also work with a range of other open-source and 3rd party technologies to bring you our full suite of features.

In our documentation we will often direct you to the and those of other 3rd parties to help you dig deeper into what it is possible to build. platformOS have won awards for their innovative documentation and we will try not to re-invent the wheel when we cover the same topics as them, but instead hope to present topics like GraphQL with a more beginner-friendly slant.

Most platformOS features can be built on Siteglide - if you find one you like and are not sure if it's supported yet, we encourage you to let us know about it.

Step 1: Add a Domain

Navigate to the Domains tab on the Site and click Add Domain:

Step 2: Choose Fully Delegated

Just click the Fully Delegated box:

Once you select Fully Delegated you need to type in your root domain (without www) and then decide if it's going to be your default domain (most likely):

You should also ensure 'Enable WWW Redirect is on unless you're adding a subdomain. Finally you can choose to add other DNS records but you can always do this later too. If you toggle to add them now you just add records and fill in the fields.

Step 3: Wait for it to process

Sit back and relax or go and make a coffee while the system does the work!

If you click the domain at this stage you'll just see the records you've added as Pending, there's nothing you can do at this stage so go grab that coffee!

Step 4: Change the Nameservers

You can refresh the page until you see the Status as 'Awaiting Propagation':

Then click into the domain and you'll see any records you've added plus the NS Records you need to add in your Domain Control Panel (GoDaddy etc):

To add more Records just click Edit Records and add new rows as required:

Step 5: Wait and Check it's Propagated

No matter how many times you've put sites live you'll no doubt be refreshing and questioning if it's worked from the moment you change the Nameservers!

You're looking for the Status to show as 'Live' in Siteglide but there are other ways to check progress listed below:

Typically you'll see some positive signals within minutes but you really do need to give it an hour or so (registrars will say 24-48 hours) before stepping in.

We recommend using the following tools to monitor propagation:

The following code example can be added to a Page Template and applied to the home/start page of a site to load a different start page for different domains added to the site.

This method does however remove some of the ease of editing for the client, as they will not be able to use Visual Editor to manage the pages that are setup this way. We'll look at adding a smoother point and click version to Admin later.

One use case for this approach would be where a client has a small chain of businesses that each have their own domain to target the area closest to them. Each of the sites are very small and the website structure is reasonably similar, and so it makes sense for the client to be able to manage all of them from the same Admin.

I'll now explain the code snippet above and how it works.

On the first line we get the current domain (context.location.host ) when the page loads and assign it so that it has a name of domain .

Next, we open a case to check the result of domain .

For each of the alternate domains we would like to check for, we create a when within the case . We include two versions of the domain to catch the majority of users. One that includes the . and another that does not.

Inside each when we call in a content section that should contain all of the page content. We also define an SEO page title to match our page and wrap that in siteglide_head_scripts to automatically move it to the head on page load (Check out this document to find out more: ).

We then add an else at the end of the case to cover the default domain e.g. "if neither of these alternate domains are used, then do this" which acts somewhat like a catch all.

Finally, we close the case.

Using the above example, visitors will see unique page content to each domain when they visit. When they click on links on the page, they will continue to other pages on the site while keeping the same domain unless you hard code a full domain URL on a link. Please note that by adding more than one domain to a site, technically all content is accessible via all domains. Though you can effectively make content hidden from domains by not adding it to pages, it could still be accessed.

Great news! You're ready to Go Live? Just follow these steps or contact us if you get stuck.

Step 1: Billing Setup

Head to the Go Live tab on the Site in the Siteglide Portal, if this is your first Site you'll likely see a message asking you to add your billing information:

Just click the link which will take you to the Billing Setup page, you just need to fill out the form:

More information on Billing Setup:

Step 2: Check Usage

The Subscription tab will show your current usage and recommend which plan you need, it'll only suggest the lowest plan that your Site currently fits into. We'd recommend considering picking a higher plan if you know usage is going to increase, this will help avoid paying overages:

Step 3: Go Live

On the Go Live tab there are a few options, firstly pick your currency then select the Plan (based on Step 2) and finally pick your preferred/closest Datacenter (this cannot be changed).

The button will not turn blue until you've selected a Plan:

It will then confirm the last 4 digits of the card that will be used and that you will be charged pro-rata for the remainder of the month based on the selected plan. When ready click Start Subscription. Please contact us if you are unsure about any of these steps, we cannot make changes once the site is Live.

Step 4: Site Copy to Production

You don't need to do anything but once you click Start Subscription the site will automatically be copied from Staging to Production. You will need to wait until this has been completed before you can work with the site or add domains.

Next Steps:

Ready to add your domain?

Ensure email deliverability via Sendgrid:

Our Agency Success team here at Siteglide are dedicated to providing exceptional support and assistance to Digital Agencies and Siteglide Experts which ensures they are able to deliver the best solutions for their customers.

Please note: Website owners need to contact their Digital Agency for assistance, if you do not have one let us know and we'll recommend a reliable local agency or you can use our services team, .

Here we'll outline the ways in which we can help you and a few things that fall outside of our scope that we cannot assist with but we'll point you in the right direction whether it's via our Community or external resources.

How do I access Siteglide Support?

• Live Chat - Click the blue bubble in the bottom right hand corner of our services to speak with the team. Please leave as much information as possible by answering any questions that appear.

• Documentation - Access our growing library of Docs, FAQs, examples, videos and more, right here

• Discord Community - Have a question that needs a creative solution or a project scope you'd would like some suggestions on from other experienced partners?

Please note our working hours are 8am - 6pm GMT (London). We aim to answer queries outside these hours where possible.

What kind of Support do we offer?

We assist agencies and developers with the following types of issues/queries:

1. Platform Issues/Bugs: If you experience an issue with the core platform please report it to us and we'll help resolve it asap.

2. High Level Platform Capabilities: We're always here to help answer questions about the platform and confirm whether it has specific features/capabilities.

3. Account and Sales Questions: If you have a billing, account or sales related question we're always here to assist.

4. Troubleshooting: If you're struggling with a feature in Siteglide we'll point you in the right direction.

5. Technical Queries: Initial guidance but then you would need to use Sitegurus for assistance implementing Siteglide features.

What can we not assist with?

1. 3rd Party Code and Custom Development: We only support the core platform code and functionality supplied out of the box as described in our documentation. We cannot support you on any 3rd party code or custom development even if we've recommended looking at 3rd party options. You are responsible for the implementation and maintenance of any custom code, design, bespoke functionality and any 3rd-party integrations. Note: Any custom code samples are provided as a guide only. We cannot provide support on use or implementation of any code that is not in our documentation. We want to focus on providing the best support of our code and platform that we possibly can. See below.

2. Specific project issues/assistance: We cannot help you build projects or scope out exactly how you will build each project. We will help answer high level capability questions but cannot map out how to implement Siteglide for specific project requirements. If you need help with using Siteglide for a project please review our options below.

3. Client/business specific questions: Siteglide is built primarily to help Digital Agencies and Expert Partners and to ensure we deliver on this mission we only provide basic account related support to end clients or Business plan users. See below for our options.

Community Support and Resources

We have a fantastic community of Siteglide Experts that can assist in various ways where we simply cannot (we want to stay focused on supporting you with the platform itself):

1. Discord Forum: The forum is the best place to start. Search to see if your question/issue already exists and post a new one if not! You can access the Forum via the Single Sign On link from the Welcome page in the Portal:

2. Siteglide Experts: We have various experts all over the globe ready to assist whether it's help scoping projects, solving issues, building projects, building specific functionality or even providing pre-built Modules or code. Browse our List of Experts here:

3. Sitegurus: Our services team, , are here to assist you with any task big or small.

4. External Resources: There are thousands of websites and resources to help with anything from project planning through to custom development and integrations. We've curated the ones that tend to be most useful to our partners here:

Introduction

A collection of 3rd party links that our partners find useful when developing websites.

These sites are full of useful content, but any advice and examples published by 3rd party Sites is their own. We do not recommend any particular Front End library and encourage your agency to find the front-end tools and techniques that work for you.

platformOS Features

Siteglide is built upon platformOS, so their documentation is a fantastic resource for adding custom functionality to your Siteglide Website:

Liquid Documentation:

We also recommend the platformOS docs as the ultimate authority on using Liquid in your Siteglide Site. They include documentation on the original Liquid features and the additional features platformOS have added themselves:

Working with JSON

You'll come across JSON when you are working on Migrations and commonly when working with Liquid. It's a common language for storing data-structures, so if you output {{this}} in a Layout- we'll show you the JSON which stores the fields you need.

Using a third party JSON tool is useful to actually take the raw data and make it easy to read. Everyone has a different favourite tool, but you can see a third party comparison here to help you get started and find one:

Front End Resources (CSS & JavaScript)

General Front End Reference:

w3schools give a fantastic introduction to all web development topics, including reference guides and examples on HTML, JS, CSS, accessibility and more. https://www.w3schools.com/

MDN is another fantastic reference guide. It's useful if you need a little bit of extra depth and context. https://developer.mozilla.org/en-US/

Bootstrap is a useful library of Front-End components and features that we've made fully compatible with the Siteglide Design System because it is so widely used and familiar. If you have Design System enabled on your Page, there is no need to install

Stack Overflow is fantastic for FAQs on every aspect of development.

Code Pen is a great source of inspiration for all things CSS and JavaScript. It is full of fancinating community generated examples of everything from User-interfaces to animations:

JavaScript

Wes Bos has earned a reputation for teaching courses in JavaScript that are accessible to beginners and experts alike:

We use the Glide.js plugin to power out Slider Module Layouts. Check out the docs to customise your Layouts and build new ones:

Google Maps are used by the Events Module. Read the docs and customise here:

FullCalendar.io is the plugin which powers the Calendar Layout of the Events Module. Read the docs and customise here:

CSS

CSS tricks is a great resource for staying up to date on the latest in CSS and specialises in helping you tackle those issues that leave you scratching your head:

In our Tutorial 4 challenge, we asked you to write a query which returned items matching multiple filter rules. Here's a possible solution.

Prerequisites

• This Article shows the Answers to a Challenge. If you've not had a go at the challenge yet, we'd recommend you

• - optional- Read more about GraphQL and when it might be best used.

Introduction

Last time, we asked you to write a single query which utilised a combination of filters to find recordswhich meet these criteria:

• They are Module Items

• They are enabled

• They have already been released

• They have not yet expired

• They have a `weighting` between 1 and 3

• They have a meta_title

• They fall into the posters Category

This challenge required you to modify and combine the queries we'd already looked at. If you were able to match at least some of the criteria, good work.

Challenge Answers

To find the category_id for the posters Category. One way to do it would have been to go to the Siteglide Admin:

After that, it was a case of combining what you'd learned so far to add multiple filters to a query:

Notes:

• For the range of weighting we've added a gte and lte setting, in order to demonstrate the possibility. This is not really necessary as there won't be values less than 0, but it's not a bad idea to rule these out, should data be entered incorrectly.

• The category_array ID may be different from one site to another. Check your site's category_id in the Admin.

Explorer: Unfortunately, as mentioned last time, Explorer does not yet support arrays, so it's not possible to show an Explorer demo for this challenge.

Next Time

It's time for the real thing! We'll look at how you can save your GraphQL query in a File and use Liquid to run it on a website Page.

Let's go!

We look at a possible answer to Tutorial 3's challenge. This shows how to write a query which fetches all WebApp items, not Module items.

Prerequisites

• This Article shows the Answers to a Challenge. If you've not had a go at the challenge yet, we'd recommend you .

• - optional- Read more about GraphQL and when it might be best used.

Challenge Answers

The trick here was to examine the tablesand spot the common patterns in their values.

The two types of recordswe wanted had these tables beginning with "webapp_":

• webapp_1

• webapp_2

The types of records we don't want have table values without "webapp_", for example:

• module_3 - (Blog Module)

• module_14 - (eCommerce Module)

• form_1 - Newsletter Sign Up Form Submissions

So, in order to filter for the recordswe do want and not the recordswe don't want, we need recordswhich start with the string webapp_.

Code:

Notes:

• In this method, there is no need to write one filter to include webapp items and another to remove module and form items from the Results. This is because the given rule efficiently achieves both at once.

Explorer:

This is just one possible answer, you may have found a different method.

Try and make sure you choose the best method for your use case. You should always be looking out for a more efficient way of doing things.

Next Time

We'll continue to look at filtering queries in more detail, including:

• filtering by different fields, or properties

• filtering with different kinds of rules

• using more than one filter at once

Let's go!

This Article will show how to use custom fields to fetch dynamic content in a WebApp Layout.

Introduction

Partners often ask us about outputting Liquid from a Rich Text Editor in their WebApps. Unfortunately it's not currently possible to do this- but here we'll explain a little about why- and a technique you can use to achieve the same effects.

Answer

Currently platformOS doesn't allow Liquid code to be executed within Liquid Fields (such as a Blog's description field). This policy improves security, by making sure it's impossible for user-submitted content to inject malicious Liquid code into your Site- giving you peace of mind that any Liquid code you write is for your eyes only.

We're working on a secure method to allow something like this in the future, but in the meantime, this Article will show you how to use custom fields to fetch dynamic content in the Layout- either above or below your Rich Text field output.

In this example, we'll be adding a Form below the WebApp rich text field.

Step 1) Add custom fields

You'll need to add the following fields to your WebApp structure:

• Show Form - Checkbox containing values True & False.

• Form ID - String field containing the ID of the Form you'd like to output.

• Form Layout - String field containing the name of the Forms Layout.

Step 2) Add data to a WebApp Item

Now the fields we'll be using have been defined, add the relevant information to the fields.

Step 3) Add Liquid to the WebApp Layout where the content will be displayed

Next, locate the WebApp Layout Folder where the Form will be outputted.

Here we can output the Form using the fields that have just been set- wrap the whole include within an IF statement checking whether "Show Form" is "true" if so the Form will be outputted (with the parameters being pulled in from our WebApp). In our example, the Form will be added underneath a Rich Text field.

Now the fields within the WebApp control whether a Form is outputted for each item.

Alternative options for moderating which content the Client can add

*Hardcoding parameters *If you only wish the Client to be able to display a single type of Form, you could hardcode the ID and Layout name of this Form straight to the WebApp Layout.

The Client would have control over whether or not to show a Form, but the Form type would always be the one you approved.

*Using Content Sections *Content Sections and Code Snippets can also be outputted depending on ID and could provide a range of ready-built content which you could allow the Client to add into their WebApp items.

*Expanding the Logic *You could use Liquid Logic in the Layout to only allow certain Form / Content Section IDs to be displayed and forbid others. In this example, Form 2 will never be displayed, even if it is selected:

Here we will outline the process involved in creating, building, submitting, and maintaining a Module in the following series of docs.

Prerequisites

• Know how to use CLI -

• Know how to use Github -

• Your IDE (Integrated Development Environment) of choice (VSCode, Atom, Sublime etc)

Introduction

We will use the as an example of a pre-built Module which is available on the Marketplace which you can install on your own staging site to view.

With that in mind, anywhere in this documentation where you see text wrapped in <> are placeholders. For example <module_name> would be module_76 with the Siteglide Theme Demo module (more on this later!).

Create your Module in Siteglide

The first step to building your module is to create a listing for it in Siteglide. Within your Portal from the left-hand menu, select “Custom Modules” and then click the blue “+ Add New Module” button in the top right-hand corner.

Next, fill in the Module Details form. For now, you only need to provide the following basic information:

• Name: The name of your module shown in the Marketplace and Siteglide Admin.

• Version: A version number following the standard. Usually this would start as 1.0.0.

• Description: Small text description of what the Module is - appears in ? icon in ‘name’ column on the Module installation page.

• Type: Which category you would put your module into.

• Show Menu Item: Does your module need to be within the sites menu under “Modules”? For example for a theme that has no items then this would be set to No.

We will come back later to enter information into the remaining fields, so for now click the blue “Save” button in the bottom right-hand corner to save your new module. Your module will only be visible to yourself at this point as it is not marked as “Public” and has not been approved for the Marketplace.

Vanity ID

Now that you have created your new module, when you view it you will see that it has a “Vanity ID” field. Make a note of this number for later as it will be used within the Module.

In this example we’re going walk through, step by step, how to create a Module with a Custom UI that could either be used as a private module for your agency or shared publicly in the marketplace to deliver turnkey site solutions to your clients and more.

It is recommended that you download our example so that you have all of the code and asset files available at each step of this guide and can easily follow along to and have your module end up looking exactly the same.

:::hint{type="info"} If developing a Custom UI then you will have to supply all elements of the Module, including but not limited to tables, GraphQL, data processing etc. :::

Custom UI

Custom UI modules open up the ability for complete flexibiltiy within Siteglide Admin and allows for truly unique experiences for your customers.

A module with a Custom UI will securely load a page within a frame in Siteglide Admin. This page can be developed in any language that can run on a Siteglide site.

Setting up your files

A Custom UI Modules will follow the same folder setup as other Modules, except when you come to build the UI itself to display in Siteglide Admin. The UI will be kept in the private folder of the module as we do not want it to be discoverable outside of the frame within Siteglide Admin.

Within our private folder we can store any files that Siteglide natively supports, such as GraphQL, Liquid, Assets etc. More information about folder structure can be found at .

Authentication

To ensure that the Custom UI is only being accessed by logging in users of Siteglide Admin, we require authentication to be added to each page that will be used within the Custom UI. This is stored in the YAML of the pages and is as follows:

The response_headers YML allows Siteglide Admin to view the content of the file when it is loaded. The authorization_policies YML will run a check to ensure that the user has an active session within Siteglide Admin, if not then it will display an error page.

As well as the YAML, any links within your Custom UI has to include a Liquid tag to apply the authencation string on the link. For example if you are linking from your Custom UI's index page to the add new item page, your link would be as follows:

This include will create a hash onto the end of the URL that is then used in the above authorization policy to decide whether to show the page. If the include is missing then following the link will throw an error within Siteglide Admin.

You can also control access to certain areas of a page with the module_is_in_admin function:

Module Details

Once your module is created, you will need to tell Siteglide Admin to load your Custom UI. You will need to take the slug of the Custom UI's homepage and enter that into your Module Detials within Portal. When editing the details about your module, there is a field called "Custom UI Path", entering in the slug there will change the menu item for your module to then load your Custom UI instead of the default Siteglide module UI. In our example the path for our Custom UI homepage is module_72/module_iframe/index

Step 1: Install the Siteglide CLI

The Siteglide CLI can be installed from NPM using:

Step 2: Connect to a Site

Setup a local folder and use the site specific command to connect directly to your site (you can find this on the site details page in Portal - ):

Step 3: Start Building!

You should now be ready to start work, you'll likely want to pull down the files from the server:

Check out our Reference article for a full list of useful Commands:

This is a brief overview of the GraphQL tutorials we currently provide and the topics we plan to cover in future.

Introduction

This Article aims to give an overview of the topics currently covered in our GraphQL tutorials, and the topics we aim to provide in the future.

For a longer introduction to GraphQL and how it can be used with Siteglide, check out the following article:

How the Tutorials Work

These GraphQL tutorials are organised by topic, but we'd recommend you work through them one by one.

This is because each tutorial will build upon the skills covered in previous ones.

We also include challenges- because when learning something like GraphQL it always helps to get hands-on experience exploring and applying the skills you've picked up. Don't worry if you can't quite manage the challenges straight away. Give them your best shot and then check the answer pages.

Tutorial Contents

The following Tutorials are currently available:

Challenge Answers

Some topics will be covered in our challenges. We'll challenge you to build upon what you've learned, before revealing a solution. If the topics interest you, try the tutorial with the same name first.

Planned GraphQL Tutorials

In the future, we intend to cover the following topics:

• Search for Results

• Use other types of Query e.g. users

Please let us know if you'd like to see anything else included.

Preparing GitHub Repository

Before submitting your Module for approval, you should check that your GitHub Repository is ready.

See the following checklist to confirm it is ready for submission:

• you've got all your files (assets, logic, layouts etc.) in the correct folders (private, or public)

• Your module folder is named in the correct format of <module_name>

• You have not included a marketplace_builder folder

• you've prepared your setup.json file if a model is required for this Module and the Module ID in setup.json matches the Vanity ID in Siteglide Admin

• you've prepared your ignore-on-update.json file

• you've prepared your install-process.json file if this is required for your module

• Your Module is in a branch named master in your GitHub Repository. This is the only branch Siteglide will read from. Note that Github may name your branch main by default. If that happens you can change that

Sending your Module to Siteglide

Now that you have created your module, you will need to update the Module item that you made in Admin earlier.

You will need to edit the item with the following information:

• Menu Name - If applicable, the name to show in the left hand menu when viewing a Site Admin: Modules > My Module.

• GitHub Repo Account - The name of the GitHub account that your Module’s repository is in.

• GitHub Repo Name - The name of the GitHub repository that your Module’s code is in

• Installation Notes - Any notes on installation - appears in ! icon in ‘action’ column on the Module installation page.

• Changelog- A link to your Module’s changelog documentation, this will display within the Marketplace and next to the “Install” button.

• Public - Do you want this Module to be visible within the marketplace?

You can also find these notes in the tooltips on each field.

Once you have clicked "Save" with the above fields populated, your module will be submitted to the Siteglide team for review.

After Submitting your Module

Once you've submitted your Module for approval you'll need to give us access to see the Module. This is needed for the initial approval, but also for ongoing access to be able to install the latest version of the Module.

To provide us with access you need to invite Siteglide API () as a collaborator for the GitHub Repository. You can do this in your .

After accepting the invitation we will review your module. This includes reading the code, installing the module onto a site and testing some of its functionality. We will create a ticket within our area so that you are kept up to date with progress. Once your Module is approved by us then we will allow it to be shown within the so any user can see and install the Module on their sites

Building Modules could be the perfect way to keep your workflow "DRY" (don't repeat yourself)! If you find a common requirement on more than one site, and no-one is currently offering a solution, or you think you can build a better one, building Modules might be for you.

What Skills do I Need?

For some types of Module, anyone can have a go, for example building a Site Template could be done by a Designer with a little bit of HTML and CSS knowledge:

For other kinds of Module, we recommend getting hold of a developer. If you don't have one, check out Sitegurus who can provide this service.

Getting Started

To Publish or Not?

One way to start building Modules is to build them as an internal tool for your Agency. This doesn't require any approval from Siteglide.

Or, you can publish your Module on the marketplace. This requires Siteglide approval so we can check the module is transparent about the kind of code it runs. You can either:

• Make the Module Open-Source

  • You can either all Siteglide users access, or require them to contact you before you decide whether to give their organisation access

  • You can optionally allow others to contribute to your Github repository

• or Accept Payments

In general there are two main types of folder structure for Modules, though within that, there will be variation on the types of file available, so check each individual module.

The form directory stores the form layout for Module create/ edit Forms.

Siteglide Published Modules

Most Siteglide published Modules will have a folder structure a little like this:

Newer Siteglide Published Modules & Marketplace Modules

Read more about Module Directory Structure on platformOS:

Usage-based Billing

The Subscriptions tab shows you exactly what each site uses broken down into high-level types of infrastructure usage and then down to specific Siteglide features to help show more value to clients.

For example, you can see the total number of Units but the real value is seeing that this is made up of CRM Contacts, Form Cases, WebApp items, Module Items, Products and much more.

Note: External API calls are unlikely to be used for many sites if you're not working on platformOS directly via CLI.

When comparing the cost of the various different tools required to achieve the same result and then trying to somehow connect them all together you can show huge savings to clients both in terms of cost and time.

Plans and Extras

You can see the individual Site Plan pricing on the Plans page:

Extras are charged pro-rata based on the plan price. Simply divide the Plan Price by the Units included you get the Unit Rate that you will be charged if you exceed the limit.

We replaced the old, more costly Overages with Extras. If your site subscription tab shows a 'Legacy' plan please refer to old old Overages pricing or speak to the team about switching to one of our new plans!

How our usage-based billing works:

1. Storage, Records, Domains and Client Admin Users do not reduce unless deleted.

2. Emails, API Calls and Bandwidth renew each month.

3. You are billed based on the peak usage each calendar month.

4. Deleted items count towards peak usage for that month but do not count in subsequent months.

5. Once you hit 70% usage of any metric it will be marked as orange as a warning.

6. Once you hit 100% usage of any metric you will start incurring Extras.

7. If you have Automatic Upgrades turned on and the cost of Extras exceeds the difference in cost to upgrade to the appropriate plan the site will automatically be upgraded on the 1st of the following month.

8. You can manually upgrade or downgrade to any plan once per month but if the new plan doesn't cover the usage you will be charged overages.

9. We do not downgrade automatically as we do not know what usage will be required in a given month and assume most sites increase in usage as the business grows and the site becomes more successful/popular.

Subscription Changes

To give you full use of the Siteglide platform we simply charge you based on your usage which can change over time and likely increase as you help your clients grow.

Please ensure you're aware of how subscription changes work before going live:

1. We monitor usage and provide the Subscriptions tab for each site to show if you are close to exceeding or exceeding the usage available on the current plan. Find out more about the Subscriptions Area in Portal.

2. We calculate usage at midnight on the 1st of each month for the whole of the previous month. If you have Automatic Upgrades turned on and exceed any usage limits we will apply the cheapest option at the time which will either be to charge Extras or Upgrade the plan. If you have Automatic Upgrades turned off we will only charge the Extras.

3. Extras are charged in blocks as a one-off charge for excess usage in that billing period. Typically you could use double the allowance of one usage metric before it’s cheaper to upgrade to the next plan.

4. For Monthly Upgrades the new plan will be applied immediately both for the new month and retrospectively for the previous month (to avoid paying more costly overages). We will charge for the new month and the increase between the new and previous plan. This will only be done to save higher overage costs, we will always apply the cheapest option.

5. Annual Upgrades will start a new 12 month subscription crediting the balance of the previous subscription prior to payment (e.g. $250 - $63 (6 months remaining of Starter plan).

6. For Sites on Connect Billing (deprecated) we will continue to pick the cheapest option based on our fees not what you charge your customer as this can vary (you could manually upgrade them to a higher plan if preferred).

7. If your site usage decreases and you believe it will not increase again then you might wish to Downgrade to a lower plan. Simply press Downgrade on the Subscriptions page, pick your chosen plan and request the Downgrade. The Downgrade will not take effect until the end of the current billing period. Note: You may prefer not to do this on Connect Billing to avoid lots of changes.

8. If you wish to cancel a site we recommend first discussing any issues with our Success team but alternatively you can delete the site via the portal. Please note deleting a site takes effect immediately and all data will be irretrievably lost. All payments are non-refundable so we recommend making full use of the current billing cycle before deleting the site (any remaining time will be forfeited).

9. Please see our full Payment Terms and Payment Failure Process in our End User Licence Agreement (sections 7 and 8).

Is your website project folder inside a Cloud Virtual Drive?

There are known issues with using the Siteglide CLI on a directory inside a Google Drive or Microsoft One Drive or equivalent. While this may be solved with complex settings changes, we are not able to guide you through this and recommend instead that you store your project directories in a standard hard drive e.g. C. For backups we recommend https://www.sitegurus.io/protect or for more advanced version control https://github.com/.

Not Sure if You've Set Up Siteglide CLI Already?

In a Command Line, in any directory, type in:

siteglide-cli -v

If you already have siteglide-cli installed globally, this will tell you which version you have installed.

You can find out which is the latest version here: https://www.npmjs.com/package/@siteglide/siteglide-cli

Have You Installed the Dependencies?

The CLI is distributed via Node Package Manager (NPM) and so you will need NodeJS installed on your machine. The easiest way to get this is to visit https://nodejs.org/ and download the LTS version as this has better support.

Open the download and follow the wizard with the default options to finish install.

Have you Installed the CLI Globally on your Machine?

You can use the following to install Siteglide CLI in any directory. The -g flag instructs your machine to make this command available in any directory (globally)- so you only need to do this on your machine once.

npm i -g @siteglide/siteglide-cli

When an update is released for the CLI, you can use the same command as above to install the updated version. Please note that the flags for commands below are not available on all versions of the CLI, updating to the latest version will allow you to use all of them.

Issues Installing on Windows?

The following video will give you a complete walkthrough guide for setting up Siteglide CLI on a Windows machine. Feel free to skip ahead to the parts you find the most useful.

Issues Installing on a Mac?

The following video will give you a complete walkthrough guide for setting up Siteglide CLI on a Mac. Feel free to skip ahead to the parts you find the most useful.

The steps followed in the video can be found here. If you are using zsh as your shell then the commands here will have to be run against the ~/.zshrc file, not ~/.profile. ZSH is the default for Macs since macOS Catalina, to find out which shell you are using you can run echo ${SHELL} in terminal. If the ~/.profile or ~/.zshrc files do not already exist then you may need to create them first before running the export PATH command

Struggling to Connect to a Site?

Read our in-depth guide:

Debug Mode

Sometimes Siteglide support may ask you to run the CLI in "debug mode". This provides more output into your terminal so that we can use it to aid in supporting you. To do this, you need to prefix the command you are running with some extra information. This prefix differs slightly on macOS, Linux and Windows, for example if you were to want to sync to a site with debug mode on:

DEBUG=true siteglide-cli sync production

DEBUG=true siteglide-cli sync production

set DEBUG=true && siteglide-cli sync production

$env:DEBUG='true'; siteglide-cli sync production

Note, for macOS and Linux, debugging will be turned on for that one command that you prefix. For Windows, debugging will be turned on for as long as Command Prompt or Powershell is open. Closing Command Prompt or Powershell and re-opening it will turn debug mode off.

About Site Templates

Templates are whole sites which have been saved so that you and other users can easily create copies of it moving forward. They are excellent for creating turnkey solutions for specific industries and client types, allowing you to sell a theme and then customise to each client on top.

Build out as much of a site as you’d like on a Trial site, then turn it into a template on the marketplace, making it publicly available to be installed during the creation of new sites.

How to Use a Template to Create a New Site of Your Own

First, find a template you’d like to use for a new site in the Marketplace. You can use the filter category at the top of the Marketplace page to filter ‘Templates’ only to find options more quickly.

Click on a template to view the popup for more information and images. If you would like to use this template, then continue to the next step below.

Once the template popup appears, you can create a new trial site using this template by selecting an owner in the “Site Owner” field, and then entering a name for your new site in the “Site Name” field.

Click the blue 'Create Site from Template' button, and then wait for the template copying process to complete.

Once you receive your email notification to tell you the site is ready, your new template site will appear in your sites list. From here you can edit the site just like any other, by clicking the 'Admin' button.

How to convert a Trial Site to a Template

Have you created a site that you’d like to turn into a reusable template?

Head over to Marketplace and click the blue “+add a new Module” button. Next, follow the usual Module creation process, but be sure to select the “Template” category from “Category” the dropdown field in the Module Details tab.

Select the trial site you want to convert to a Template Module using the “Site” dropdown field displayed below the Name, Category & Description fields.

Note: Only trial sites can be converted to a Template Module.

Once you have created your Template Module, you can either keep it for internal use within your team, or allow the template to be publicly viewable and installable.

If a template is both publicly viewable and installable, then the master trial site will be locked for editing (with a status of “Locked - Template”). The site is locked to prevent other users making copies of a site that has any ongoing work.

If the site were not locked, then the copy process could be triggered whilst there are unfinished changes from the managing development team. If you wish to make edits to the master trial site, at any time you can remove the template from the Marketplace by toggling either the 'Publicly viewable' or 'Publicly installable' values to 'No'.

The master trial site will then be editable again until you toggle both of those values back to 'Yes'.

Turning the Page! In tutorial 2, we'll control how many items Graph returns on each Page of results and retrieve specific Pages.

Prerequisites

• You have completed the .

• - optional- Read more about GraphQL and when it might be best used.

Introduction

When GraphQL returns results, it will organise them into pages.

This allows it to be more efficient, as it only returns the data that is needed straight away. At the same time, the rest of the pages are organised ready for the next request.

You'll always need to think about Pagination when using GraphQL, even you only want to retrieve the first Page of results.

Per Page

per page is an argument used to define the number of results that will be returned on each page.

It's now a mandatory argument on some types of query so we've already got the argument in our query from the last tutorial:

Experiment by changing the integer in the argument from 20 to another value, e.g. 1. Observe the difference. It's recommended to keep the per_page number as low as possible- for efficiency and performance.

Let's consider a few situations:

• You want to display 3 items - Set per_page to 3- only the three items you need will be retrieved.

• You want to display 20 items at a time, but allow the user to view the next 20 when they've finished reading - Set per_page to 20

• If you want the user to be able to change per_page dynamically, we'll cover this when we look at variables in a future tutorial.

• If you think you need to display more than 2000 items at a time (perhaps to provide data to a JavaScript plugin), consider using GET requests to a custom Liquid endpoint page to fetch each page of results asynchronously. You can learn more in but we recommend working through the other tutorials first.

Returning Pagination Metadata

You can return pagination metadata alongside your query results:

• current_page - Returns the number of the current page.

• per_page - Returns the number of items on every page.

• has_previous_page - A boolean which is true if there is a page before the current page.

• has_next_page - A boolean which is true if there is a page after the current page.

• total_pages - Returns an integer representing the total number of pages in these results.

These optional properties can be requested alongside total_entries and your results object, like in the example below. Try them out. Code:

Notes:

• Properties like has_next_page and has_previous_page are most useful for adding pagination buttons of your own.

• You can see that by default, we get the first page of results- so page returns 1.

Explorer:

Changing the Page

You can view other pages by setting the page argument to the page of results you'd like to see.

Code:

Explorer:

Next time

In the next Article, we'll look at how to filter results.

For example, we'll learn how to return items from only a specific WebApp.

Let's go!

Although it can feel like a big leap at first, using custom GraphQL gives you ultimate control over dynamic data. We'll guide you through.

Introduction

Firstly, let's go through a few frequently asked questions about GraphQL. In the next article, we'll then get started on our first Query on a new Starter Site.

What is it?

GraphQL is an open-source querying language which was originally developed by Facebook. The general idea was to create a language which allowed Developers to quickly develop flexible requests for data, while being efficient and only asking for exactly the data they needed. The structure of the query, including relationships between different tables, matches the structure of results- making it easy to iterate over the data after the query is complete. You can read about the open-source project on their website here:

How does Siteglide use GraphQL?

It's worth noting that you don't need to learn GraphQL to use Siteglide's core features. Most of the time, Siteglide does the querying for you. However, learning GraphQL will allow your Agency to take on more challenging projects- see the next question.

Although the language is open source, actual implementations of it can be quite different across platforms. This is because a GraphQL implementation has two parts:

• The Schema - this defines different types of Query you can use, which parameters you can add, and what sort of output you can request. It reflects, in part, the database structure that the Platform uses, so it varies from Platform to Platform. Siteglide runs on platformOS and we use of GraphQL.

• The Query Language - This is the syntax for writing queries- it is exactly the same across platforms, but can feel very different when the Schema is different.

If you've used GraphQL before with a different Schema, you will start to see lots of similarities.

How do Liquid and GraphQL work together?

Liquid is a templating language; GraphQL is a query language. To put it another way, think of GraphQL as a re-usable question.

Liquid will both ask the question- and listen to the answer, using it to build a dynamic website. The question itself is in a different language: GraphQL.

GraphQL files are stored inside the marketplace_builder folder. They can be called by Liquid and re-used as many times as you like.

How can I learn GraphQL?

GraphQL can be tricky to get started with, but most of our Developers report that at a certain stage, it just 'clicks' for them. We want to help any Agency who wants to learn to get there.

We'll provide a series of Tutorials, starting off simple and becoming progressively more challenging. As part of this, we'll aim to give you the skills you need to carry out further learning yourself- often this will mean learning to read the platformOS schema- finding the type of query you need, and experimenting with how to make it work.

Every time we add a new GraphQL Tutorial, you'll be able to access increased support on that topic via the Forum. You can see an overview of the topics we've covered so far

In the next Tutorial, we'll show you how to use the GraphQL sandbox to test out Queries.

I'm stuck. Can you help me build a Site with Custom GraphQL?

We want to give you all the tools you need to learn GraphQL and we'll give our general tips, tricks and links to help you solve problems. Unfortunately, Siteglide support can't build a custom Page for you or assist with custom GraphQL questions - we want to stick to providing first class support on the core product.

If you're stuck, here are some things you can try:

• Help us improve our general documentation on GraphQL. We'll keep adding and improving on our articles. See the "did this page help you" buttons at the bottom of each developer docs page.

• Ask the Community on . We have an ever-growing Community of developers from around the globe, join the discussion.

• Siteglide's custom support partner, Sitegurus, can provide developers who are experts in using GraphQL with Siteglide.

• Maybe this particular solution isn't suited to custom GraphQL, maybe it's better as an official feature? You can request features on the .

When should I use Custom GraphQL?

Writing GraphQL queries gives you ultimate control over your dynamic data. Now, for a small Site, it's probably faster to use Siteglide's pre-built features to cover this for you.

Here are some examples of where some custom GraphQL could open some doors for your Agency. We'll update this list with tutorials and suggestions in the future:

• Get any data from your Siteglide instance

• Reporting- Your Client wants several bespoke, complex queries of data, all organised into tables and charts? GraphQL can help you be this flexible and if implemented well, can maintain page speed.

• GraphQL works inside workflow and autoresponder emails. With mutations, it can also send transactional notifications and API calls from anywhere in your Site.

• Performance optimisation- We do our best to make sure all Siteglide features are delivered to you with the maximum flexibility and performance, but for very bespoke Sites we couldn't possibly make the Platform guess your priorities. Understanding GraphQL could help you optimise your most complex features for faster Page load time, while using ready-built features to save development time in other areas.

• Front End Mutations- Use at your own risk! With mutations, you can change data in the database and trigger this with Liquid. This can make a lot of complex projects possible- see the platformOS GraphQL schema for a full list:

• Update data without loading the Page- When changing Page in WebApp results, you currently have to wait for the Page to reload. Using Siteglide-CLI and GraphQL you can build an XHR endpoint to get updated data after the Page has loaded. (Note: you can do this with CLI, without GraphQL- GraphQL just gives you more flexibility.)

• Jump ahead of the Roadmap- We're always updating our Roadmap with new functionality and Community requests. But what if you have that one Client that cannot wait? It'll take more time to Develop and may not be as re-usable as a fully tested official feature, but with GraphQL and Liquid understanding, you've got the power to build your own solutions.

Start Learning now!

Our first tutorial will get you set up on the GraphQL playground/ sandbox which we make available through Siteglide-CLI.

Standard Module Fields

These Fields are available to all standard modules:

Output a Module Layout

List Layouts

Detail Layouts

Liquid Include Parameters

• id - the Module's ID

• item_ids - output one or more module items, comma separated

• category_ids - output all items in one or more categories, comma separated

• layout - default is /default/ - 'layout' values are relative to the folder: layouts/modules/Blog (module_3)/[layout name]

• per_page - defines the number of items outputted on the page

• show_pagination - default is true - defines if items should be paginated when the per_page is met.

• sort_type - defines the type by which items are ordered

  • properties.name - name of the Module item (alphabetical)

  • created_at - date the Module item was created

  • updated_at - date the Module item was last edited

  • properties.weighting - weighting of the Module item

  • properties.release_date - date the item is set to be released

  • properties.module_field_3_1 - Sort by a core or custom field

• sort_order - defines the order in which the type is sorted asc - sort items in ascending order desc - sort items in descending order

• collection - default is 'false' - If you set it as collection: 'true' then any layout is suppressed.Data is accessible via {{context.exports.webapp_1.data}}. For Example, name would be: {{context.exports.webapp_1.data.result.items[0]['name']}}

• use_search - Allows the Module to be searched by keyword parameter in URL

• use_adv_search - Allows the Module to be filtered by core/custom field IDs in URL parameters

• datasource - true/false - When outputting a "nested" module inside another, the inner module tag can be given this parameter to prevent it from inheriting parameters which would change its page etc.

Output the Most Recent Item

To get the most recently "released" item, you can use the sort_type parameter to sort by properties.release_date. You can alternatively use created_at to sort by the Item you most recently added to the Admin.

Then just output one post- to get the first Item. To do this, set per_page to 1.

Use the sort_order to control whether you get the first or last item. To get the latest Item by date, the date will have a higher value, so use 'desc' (starts with highest number) rather then 'asc' .

Take control over your WebApp Layouts by exposing the Data and making your own For Loop with Liquid

Prerequisites

In this Tutorial, we'll be using dot notation, so if you're not familiar with it, you may want to brush up here:

• Getting Started with Dot Notation

• Advanced Dot Notation - Arrays and Key Maps

You'll also need to be familiar with WebApps:

• Creating and Editing WebApps

• WebApp List Layouts

• WebApp Detail Layouts

Introduction

By default in Siteglide, when you include a WebApp, we query the database and loop over the items for you. We take the data inside the loop and assign it to a variable called this which holds dynamic data about the current item. In certain situations, you may want to do something different, so we have provided the optional parameter collection.

Setting collection to 'true' makes the data from the behind-the-scenes query available to you directly, without a layout.

Using Collection

In the following example, we show the difference between a WebApp list which does use Collection and one which doesn't:

<div class="container">

  <h2>Here we have an ordinary WebApp</h2>
  {%- include 'webapp'
      id: '1'
      layout: 'portfolio_2'
      per_page: '20'
      show_pagination: 'true'
      sort_type: 'properties.name'
      sort_order: 'asc' 
  -%}
  
  <h2>Here we have a WebApp Collection</h2>
  {%- include 'webapp'
      id: '1'
      layout: 'portfolio_2'
      per_page: '20'
      show_pagination: 'true'
      sort_type: 'properties.name'
      sort_order: 'asc'
      collection: 'true' 
  -%}
  
  {{context.exports.webapp_1.data | json}}
  
</div>

This outputs:

To break it down further, setting collection to true exports the data to {{context.exports}} Under that, you can access it by the id of the WebApp in the original include tag. In this example, it's 1 so we can access {{context.exports.webapp_1.data | json}}.

You can then use dot notation to access the data as you wish.

A Possible Use Case

When would you use collection?

Well some people will prefer to always use collection, others will prefer to use layouts. One possible use-case where Collection works better though is if you want to display the same WebApp twice on the Page but differently each time.

For example, what if you wanted to display the first item largely at the top, then display other items in smaller cards below?

You could use the `

` tag twice to achieve this, with different Layouts each time, but this would have a negative effect on performance. This would slow the Page down, because we would be querying the database behind the scenes twice (once for every time you include the tag).

Alternatively, you could include the webapp just once as a collection, then use Liquid to display the items you want in the way you want:

<div class="container">
  {%- include 'webapp'
      id: '1'
      per_page: '6'
      sort_type: 'properties.name'
      sort_order: 'asc'
      collection: 'true' 
  -%}
  <h2>Featured Item</h2>
  
{% assign this = context.exports.webapp_1.data.result.items[0] %}
  {{this.Title}}
  <h2>Other Items</h2>
  {% for this in context.exports.webapp_1.data.result.items %}
    {{this.Title}}
  {% endfor %}

</div>

This outputs:

Great! Only one query needed behind the scenes and we've nearly met the objective, but there's one problem. The item "A Special Guest Appearance" has been included twice!

Advanced Looping

We can use the offset parameter on our loop tag to start the loop at a different index. Let's skip the first index when we loop, as this item has already been displayed.

<div class="container">

  {%- include 'webapp'
      id: '1'
      per_page: '6'
      sort_type: 'properties.name'
      sort_order: 'asc'
      collection: 'true' 
  -%}

  <h2>Featured Item</h2>
  
  
{% assign this = context.exports.webapp_1.data.result.items[0] %}
  {{this.Title}}
  
  <h2>Other Items</h2>
  
  {% for this in context.exports.webapp_1.data.result.items offset: 1 %}
    {{this.Title}}
  {% endfor %}


  
</div>

</div>

You can do a lot with loops. Offset is just one of your options. Head to the pOS documentation to learn more about loops in Liquid: https://documentation.platformos.com/api-reference/liquid/loops

Using Layouts with Collections

Hang on, wasn't the point of Collections to avoid Layouts? Not quite! The idea was to give you control over the loop- layouts are still possible. I can still include my portfolio_2 layout, but I need to work out its path from SITE MANAGER / Code Editor in Admin.

I can now include the Layout at this Path: `

`

The Layout is expecting an object called this containing the data, but as in the example above we already assigned variables called this containing the right data, the Layout works without further modification:

How to use Liquid For Loops and Indexing to handle arrays. Also, how to use a key to access key maps, using categories as an example.

Prerequisites:

This Article is the second in a series on using Dot Notation in Siteglide. We strongly recommend reading the Article below first:

• Getting Started with Dot Notation

Introduction

If you're using dot notation, you'll probably come across arrays and maps. The syntax for dealing with them is slightly different, but this actually makes them more powerful when you're building complex Layouts.

The examples below focus mainly on Categories because they are a good example of arrays and maps.

Arrays

An array is a group or list of data. A key might have a single value, or an array of values.

In Siteglide for example, each WebApp item for example has a field called category_array which stores a list of the IDs of every Category assigned to that item. The more categories an item belongs to, the longer the array. E.g. { "category_array":["98479", "111111"] }

If you try to use standard dot notation as we practised in the previous Article, you will be able to output the array as it is using the key category_array and the liquid {{this.category_array}}:

["98479", "111111"]

However, there aren't many places where this would actually be helpful. It would probably be more useful to do one of the following:

• Access one of the Array items by its Index

• Loop over the array Items

• Find the length of the array (how many items are there?)

Accessing an Array by its Index

Arrays have an index, which means they are numbered. In Siteglide (and in JavaScript) Arrays are zero-indexed, meaning the first item has the index of 0 while the second item has the index of 1.

We can access the first value in the category_array by its index using the following Liquid: {{this.category_array[0]}}outputs 98479

Note that straight after the key, we give the index number of the value we want in square brackets. If the array contained objects, you could go a step further and access one of their properties with a dot after the square brackets.

Looping the Array to Access all Values in it

We can access all values in the Array using a Liquid For Loop:

{% for item in this.category_array %}

  {{item}}<br><br>

{% endfor %}

This outputs:

98479
111111

Finding the Length of an Array

You can find the length of an array using a Liquid filter: {{this.category_array | size}} outputs: 2

Maps

As well as arrays, you might come across a map of data. Here is an example which can be tried on any Siteglide Starter Site using the Liquid: {{context.exports.categories}}

It outputs something like this (but I've shortened it here!):

{
  "items": {
    "98490": {
      "id":"98490",
      "external_id":"category_57703",
      "name":"Womens",
      "parent":"98487",
      "slug":"women",
      "image":null,
      "description":null,
      "meta_title":"Womens",
      "meta_desc":null,
      "og_title":null,
      "og_desc":null,
      "og_type":null,
      "twitter_type":null,
      "full_slug":"/our-products/merch/clothes/womens"
    },
    {
      "98489":{
        "id":"98489",
        "external_id":"category_57701",
        "name":"Men",
        "parent":"98487",
        "slug":"men",
        "image":null,
        "description":null,
        "meta_title":"Men",
        "meta_desc":null,
        "og_title":null,
        "og_desc":null,
        "og_type":null,
        "twitter_type":null,
        "full_slug":"/our-products/merch/clothes/men"
      }
    }
  }
}

A map is used to store data when you know the ID of an item and want to fetch it using it's ID as a key. In Siteglide we use them for performance reasons. You can tell this is a map, because the key items contains several comma-separated objects instead of a single value. Each of these has a key representing an ID, instead of the name of a property.

Let's say you have the ID of a category, but you want to display the Category's name: {{context.exports.categories.items["98490"].name}}

This outputs: Women

This sounds odd, but it's the name of the eCommerce Category we wanted! You can achieve the same if you have the ID stored as a variable:

{% assign my_example_category_id = 98490 %}

{{context.exports.categories.items[my_example_category_id].name}}

Looping over a Map

You can loop over all keys in a key map using a Liquid FOR loop. Inside the loop, each key-value pair is treated as an array with the key being the first item in the array and the value being the second and last value in the array.

In this example, we'll loop over all Categories in context.exports.categories.data and see what data is available to output:

{% for item in context.exports.categories.data %}
  {{item[0]}} <!-- Outputs the key, which in this case is the ID of the category -->
  {{item[1]}} <!-- Outputs the value, which in this case is an object containing this category's fields. You can see all available fields by outputting it. -->
  {{item[1].name}} <!-- Outputs the name of the Category in this iteration of the loop. -->
{% endfor %}

Using what you've learned so far

Here's a challenge you can try.

Can you create a WebApp with Categories and in your Layout output a list of the Category names that belong to the item?

Step 1) Create a WebApp and assign more than one Category to each of the Items. Step 2) In the Layout, access the this object. Step 3) Use your Understanding of arrays to loop through every category belonging to the item. Step 4) Use your understanding of maps to find the name of each category in the Loop and output it.

Next Article

Next, we'll look at how you can use dot-notation to work with WebApp collections: Using WebApp Collections

You can change the type and order of sorting. You can also sort by multiple properties at once.

Introduction

In this Article, we'll look at how you can instruct the query to return items in an order of your choice.

Using sort along with pagination means you can make sure the first pagen of results shows you the items you're interested in. Using sort along with variables allows you to let your end-User customise the sort order themselves.

Sorting by a Single Property

In this example, we'll start with a query which fetches the Categories.

Code:

query sorted_categories {
  records(per_page: 2000, filter: {table: {contains: "category"}}) {
    results {
      table
      id
      properties
    }
  }
}

Step 1) First, we'll add in a sort parameter

Code:

query sorted_categories {
  records(per_page: 2000, sort: {}) {
    results {
      table
      id
      properties
    }
  }
}

Notes:

• As a parameter, sort is contained within the round brackets after the query type

Explorer:

Step 2) Next, you can add a sort method.

You can either use:

2) a) A field from the main options

Code:

query sorted_categories {
  records(per_page: 2000, sort: {created_at: {}}) {
    results {
      table
      id
      properties
    }
  }
}

Explorer:

2) b) a property from properties

Code:

query sorted_categories {

  records(per_page: 2000, sort: {properties: {name: "weighting"}}) {
    results {
      table
      id
      properties
    }
  }
}

Notes:

• Remember, any field which is not a Platform default field will be a property. This means any field not listed in the other options, including several Siteglide fields such as "weighting". Default fields tend to be like created_at automatically filled in when an item is created.

Explorer:

Step 3) Select a sort order

You can choose between the keywords DESC (descending) and ASC (ascending).

Code:

query sorted_categories {
  records(per_page: 2000, sort: {properties: {name: "weighting", order: DESC}}) {
    results {
      table
      id
      properties
    }
  }
}

Explorer:

Sorting by Multiple Properties

Sometimes you may want to initially sort by one property, e.g. weighting, but then some items may have a blank weighting property. Those items where the sort field is blank will go to the end of the results list, but you can add additional sort conditions to sort these further.

Let's say we wish to firstly sort by "weighting", then sort those items without a weighting by the "release date".

Code:

query sorted_categories {
  records(per_page: 2000, sort: {
    properties: [
      {name: "weighting", order: DESC}, 
      {name: "release_date", order: DESC}
    ]
  }) {
    results {
      table
      id
      properties
    }
  }
}

Notes:

• Here we use an array with square brackets [] to add multiple sorting objects with curly braces {}

• Unfortunately, arrays are not yet supported by the Explorer, so you'll need to add this code manually.

• You can use different sort orders for each condition

Next Time

If you want to challenge yourself, you could choose to try making a query which uses variables to change the order and field by which results are sorted.

Next time, we'll look at how you use what you've learned so far to start to build your own Application Programming Interface (API). This will use GraphQL to query the database, Liquid to display the results on an endpoint Page and JavaScript to GET those results on the client side.

If you have a domain that is managed in GoDaddy or another registrar and would like to point it to a Siteglide website you can use our External Domain feature. This means that you can continue to manage your DNS through GoDaddy/other registrar.

Note: If using OCI (Oracle+Cloudflare)

If your site is on one of our new OCI (Oracle+Cloudflare) stacks the UI will look slightly different, you will be able to add both CNAMEs at the same time. The records are as follows (replace www.yourdomain.com with the actual domain ensuring www is included unless you're adding a subdomain):

If you cannot put a CNAME on the root we recommend switching either to our fully delegated option or using Cloudflare to manage your DNS who offer flattened CNAMEs on the root.

If using AWS please follow the steps below, contact us if you're unsure which stack you are on.

Step 1: Add a Domain

Navigate to the Domains tab on the Site and click Add Domain:

Step 2: Choose External

Step 3: Enter Domain Details

Type in the root domain without www and you'll likely want to set it as the Default Domain and Enable WWW Redirect. Then click Add Domain:

Step 4: Add SSL Verification CNAME

Once your domain has finished creating in the system, it's status will change to "Ownership Verification Pending" which means it is now ready.

Add the generated CNAME record to in your DNS control panel to verify ownership, generate an SSL certificate and automatically apply it to your site during the next step.

GoDaddy example:

Once you have saved the record in your registrar, allow some time for propagation, check back and refresh the page.

Step 5: Add WWW CNAME Record

Once the verification CNAME record has propagated the WWW CNAME Record needs to be added in your DNS Control Panel (GoDaddy example):

The site will now be live via WWW (https://www.domain.com) but not via the root domain (https://domain.com). Complete Step 5 to fully setup the domain correctly. The domain should show as 'Live' under the Status column in Siteglide:

Step 5: Forward the Root/@ to the www (with SSL)

Most DNS Control Panels cannot correctly redirect the root traffic to the WWW over SSL so we recommend using an external service called Redirect.Pizza.

Just follow these steps to redirect your non-www to the www variant. The non-www is also sometimes called naked record or "apex" (screenshots below):

1. Create a redirect.pizza account.

2. Add your source. This should be the domain without www. For instance, enter example.com as your source.

3. Set the destination to the variant with www. Example: www.example.com

4. Press "Create redirect"

5. The required DNS change pops up. Go to your domain registrar to make this DNS change for the A record. This record may already exists '@'. Press 'edit' to edit it to the required DNS setting for redirect.pizza. For more info, see What are these DNS changes?

6. The DNS change is made! It may take up to 24 hours before the DNS is fully propagated.

These Steps can also be found here: https://redirect.pizza/support/redirecting-non-www-to-www

Introduction

In this article we'll look at how to delete a record with a GraphQL mutation, but first of all, let's look at what deleting a record means (and how to undo it!).

What is Soft Deletion?

When we delete records with GraphQL, they are soft-deleted by default.

If you accidentally delete data, it may have been "soft deleted", and you may be able to recover it if you act quickly.

Think of soft-deletion as being a bit like a recycle bin:

• Records are given a deleted_at property with a date in 30 days time in platformOS's datetime format (ISO 8601)

• When the date is reached, the record will be permanently deleted.

• They are removed from the results of all queries by default (this includes all Siteglide tags)

• You can get ordinary recordsqueries to display soft-deleted records (only), see below:

query seeDeletedRecords {
  records(
    per_page: 20,
    filter: {
      deleted_at: {
        exists: true
      }
    },
    sort: {
      deleted_at: {
        order: ASC
      }
    }
  ) {
    results {
      id
      deleted_at
    }
  }
}

The results will be the same as in a normal query; it's helpful to add deleted_at to the results so you can see when they will be permanently deleted:

{
  "data": {
    "record_delete": {
      "id": "3",
      "deleted_at": "2024-01-02T15:15:55.666Z"
    }
  }
}

Recovering Soft Deleted Records

If a record has been soft-deleted by mistake, and has not yet been permanently deleted, you can recover it by setting the deleted_at property to null. Make sure to use the query above to find the ID of the record you want to recover and pass it in as a variable to the mutation below.

mutation recoverSoftDeletedRecord($id: ID!) {
  record_update(id: $id, record: {deleted_at: "null"}) {
    id
    deleted_at
  }
}

After changing deleted_at to null, the record becomes an ordinary record. It appears in queries and is no longer scheduled to be deleted. The mutation results should confirm that deleted_at is no longer set:

{
  "data": {
    "record_update": {
      "id": "3",
      "deleted_at": null
    }
  }
}

If you want to extend the amount of time the record stays in soft-deleted state, you can change the deleted_at property to set the deletion date to be further in the future (but this is an advanced method we won't cover here).

Deleting a Record

Step 1) Find the ID of the Record you wish to Delete

Use another query to find the ID.

Step 2) Add the mutation keyword and a name

mutation deleteRecord {

}

Step 3) Add the records_delete mutation type

mutation deleteRecord {
  record_delete() {}
}

Step 4) Add the id of the record you wish to delete, with a variable if you like

mutation deleteRecord($id: ID!) {
  record_delete(
    id: $id
  ) {}
}

Step 5) Add a result to confirm the mutation's success

mutation deleteRecord($id: ID!) {
  record_delete(
    id: $id
  ) {
    id
    deleted_at
  }
}

A successful deletion may look like this:

{
  "data": {
    "record_delete": {
      "id": "3",
      "deleted_at": "2024-01-02T15:15:55.666Z"
    }
  }
}

Summary and Further Learning

You've now learned how to perform all four CRUD operations using GraphQL:

1. Create

2. Read (query)

3. Update

4. Delete

If you wish to programatically create, update or delete multiple records at once, it may be more efficient to use the following mutation types instead of looping:

• records_create_all

• records_update_all

• records_delete_all

Be very careful with those and make sure you test with data which is backed up. We recommend using any_table: false as a precaution.

In these mutation types, you use a filter to determine which records should be affected instead of only passing id. You need to add count to the results.

Next Time

Next time we'll look at how you can use a query to access data from multiple relational database tables, or in other words, view data from Siteglide datasources.

Introduction

Last time we looked at how you can use mutations to create a record.

This time, we will look at a mutation to update a single record.

The syntax is very similar to creating a record, but the main differences are:

1) using a different mutation type

2) We need to pass in an ID- to identify the record which needs to be changed.

Steps to Edit a Record

Step 1) Add the mutation keyword

All queries started with the query keyword; mutations start with the mutation keyword.

mutation editItem {

}

We've also named our mutation editItem.

Step 2) Add the recordUpdate mutation type

mutation editItem {
  record_update() {
  
  }
}

Step 3) Add the ID of the Record which should be updated

In this example, we'll add the ID as a variable:

mutation editItem($id: ID!) {
  record_update(id: $id, record: {})
}

Note, we don't need to add an object for the ID as we might when filtering a query.

Step 4) Define the new Properties in the Record Object

As with record_create mutations, the record object defines the properties the record will have after the mutation has run.

Any properties you set will be updated. Any properties you omit will stay in their current state.

mutation MyMutation($id: ID!) {
  record_update(
    id: $id
    record: {
      properties: [
        {
          name: "module_field_3_1",
          value: "Updated Blog Title"
        }
      ]
    }
  )
}

You do not need to specify a table. By default, the record will remain in its current table. Attempting to change the table may not be supported on Siteglide as the new table would not have compatible fields.

As in our last tutorial, it is possible to pass in properties as a single large JSON variable, if you see a convenience in doing so.

Step 5) Add Results

As in the last tutorial, it is required to add something to the object which returns with the results of the mutation. This can be useful to confirm results and show you what has changed. However, if you don't need many details, the best performing option is just to ask for id.

mutation MyMutation($id: ID!) {
  record_update(
    id: $id
    record: {
      properties: [
        {
          name: "module_field_3_1",
          value: "Updated Blog Title"
        }
      ]
    }
  ) {
    id
  }
}

A successful mutation result will look like this:

{
  "data": {
    "record_update": {
      "id": "96"
    }
  }
}

Handling Race Conditions

Imagine you have two different forms, each with an automation attached to them and you want to count how many times the automation runs.

You set up a WebApp with a custom integer field. Each time the automation runs, you:

1. query the WebApp, get the current count

2. add 1 to the value with the add Liquid filter and

3. update the count with a record_update mutation.

9 times out of 10, this will behave as expected, but what if two people submit the form at the same time?

If both automations check the current count at the same time, they will both read the same value e.g. 5 and after adding 5, will save 6 as the updated count in the database. Even though the automation ran twice, the count would only increase by 1.

It is to combat this scenario that record_update contains the following special operations:

1. array_append will push the provided value to the end of an existing array stored in a property.

2. array_remove will remove the provided value from an existing array stored in a property, (wherever in the array it currently is)

3. decrement will reduce an existing integer value by the provided integer value (could be 1 or some other integer)

4. increment will increase an existing integer value by the provided integer value (could be 1 or some other integer)

In our example, we could do the following:

mutation MyMutation($id: ID!) {
  record_update(
    id: $id
    record: {
      properties: [
        {
          name: "webapp_field_1_1",
          increment: 1
        }
      ]
    }
  ) {
    id
  }
}

This safely increases the counter by one per mutation run, even if the two mutations are triggered by Liquid simultaneously. There is no need to query the existing value.

Summary

Nice work following through this tutorial.

If you want to try updating users, you can experiement with the user_update mutation.

Next Time

Next time, we'll look at how to delete records.

You shall not pass! This time, we'll look at how you can use filters to only return results based on specified rules.

Prerequisites

• You have completed the Learning GraphQL tutorials 1 - 2. You can find the previous tutorial

• - optional- Read more about GraphQL and when it might be best used.

Introduction

recordsin the database have a tablewhich tells us which WebApp or Module they belong to.

This time, we'll look at how you can use filters to only return results with a particular table, or with a table which matches a certain pattern.

Returning The Gallery WebApp

The Starter Site comes packaged with a ready-built WebApp with the id of 1 and the name webapp_1.

Step 1: Load the previous query

We'll return to our query from the previous tutorial, but this time, we'll rename it from get_all_records to get_webapp_1 to reflect the different purpose we intend for it. We'll also be wanting to look at page 1 again.

Code:

Explorer:

Step 2: Add the filter argument

Next, we'll add a filter argument:

Code:

Notes:

• As an argument for the recordsquery, this goes inside the round brackets after records.

• Like the other arguments, filter is followed by a colon :

• We have more settings to choose next (filter is an object) so we add curly braces { }

Explorer:

Step 3: Filter by the table

In this tutorial we'll choose the tableto apply the filter to, because we're looking for items with the tableof webapp_1.

Code:

Notes:

• We've chosen table as the only filter. In the next tutorial we'll explore using other fields, and filtering by more than one field at once.

• This field also contains further options, so we use a colon : followed by curly braces { } to contain the next set of options.

Explorer:

Step 4: Define the filtering rule

We now have a choice about:

1. How closely our value should match with the contents of a field before a match is returned. We'll use value (the exact value).

2. The value we are matching against. We'll use webapp_1 .

Notes:

• value is a key and is followed by a colon :

• Our value "webapp_1" must be a String, so we wrap it in double quotes.

Documentation panel:

• Selecting RecordsFilterInput gives you options for different filtering rules you can apply:

• After the colons : you can see the type of value expected for each of these keys. They are mostly strings String or arrays of strings [String]. This topic will be covered in more detail in later tutorials. Keep an eye out for the different data types expected by GraphQL in the meantime.

Explorer: When implementing this using the Explorer, the wizard will help you get the type of value correct. In this case, it provides you with quotes so that you can enter the value as a String:

Returning Items from the Blog Module

You can adjust the filter to return items from a specific Module item only. In this example, we'll specify module_3 which is the Blog Module.

Code:

Explorer:

This should return Blog Posts from the Blog Module.

Returning Form Submissions

You can adjust the filter to return Form Submissions from a specific Form only. In this example, we'll specify form_1 which is the Newsletter Sign Up Form.

Code:

Explorer:

Challenge!

Introduction to GraphQL Challenges

In order to learn GraphQL, you'll need to start experimenting with what you've picked up from this tutorials.

To help you do this, we'll now start to set you some challenges. These will ask you to tweak the examples we've given you so far and see if you can achieve the desired results.

We'll always give you the answers to the challenge in the following Article, so don't worry if you get stuck.

Your Challenge is to Write a Query which returns Items from all WebApps but not Module items

To carry out this challenge, you will need to create a second WebApp and add a couple of items in the Admin. By experimenting with the options in the documentation panel, see if you can filter the results so that:

• your query returns all items with the tableof webapp_1

• your query returns all items with the tableof webapp_2

• your query does not return items which start with module_

• your query does not return Form submissions which start with form_

We'll go over the answer to this challenge in the next Article.

Next Time

We'll look at a possible solution to our challenge. After that, we'll continue to look at filtering queries in more detail, including:

• filtering by different fields, or properties

• filtering with different kinds of rules

• using more than one filter at once

Last Time we challenged you to pull together everything you'd learned to create some Pagination Buttons powered by Graph. Answers here!

Challenge Objective

For this challenge, we'd asked you to set up your own simple Pagination controls. This combined several of the skills you've learned so far. As usual, don't worry if you need to check these answers before completing the challenge on your own.

On a new Page you create, the User should be able to see the first three Items in the Gallery WebApp.

Then, when they press the Page 2 button, the Page should refresh and they should see the second Page of Results.

Step 1) Writing the Graph Query

Firstly, here's the query without variables.

query gallery_by_page {
  records(per_page: 3, page: 1, filter: {table: {value: "webapp_1"}}) {
    page #optional
    results {
      properties
      id
    }
  }
}

Now let's add the variables:

query gallery_by_page($page: Int) {
  records(per_page: 3, page: $page, filter: {table: {value: "webapp_1"}}) {
    results {
      page #optional
      properties
      id
    }
  }
}

Notes:

• The most difficult part here might have been working out the type. Here the query expects Page to be an integer. The documentation panel confirms this:

• From the documentation panel, you can also see "= 1" after the type. This is a default, which means if no variable is passed through, the variable will be given a default value of 1. Not all variables will have defaults.

• The type here does not have an exclamation mark ! so the query won't deliberately fail if no value is passed in.

• We set per_page to 3

Step 2) Sync the Query to the Site using Siteglide-CLI

Refer back to Tutorial 5 to refresh these steps.

Step 3) Adding the HTML Controls

We gave you these in the tips. You'll have needed to add them on a Page of your choice.

<ul>
  <li><a href="{{context.headers.PATH_NAME}}?page=1">1</a></li>
  <li><a href="{{context.headers.PATH_NAME}}?page=2">2</a></li>
  <li><a href="{{context.headers.PATH_NAME}}?page=3">3</a></li>
</ul>

Pressing one of the buttons will redirect us to the same Page, but will be adding a page query parameter to the URL. This is the easiest way to pass variables to Liquid- because Liquid runs before the Page loads, and the URL is one of the only available sources of dynamic information at this point.

It's also possible to pass information to Liquid on another Page via an XHR request. This can lead to smoother UX, but is more challenging and will be covered in a future tutorial.

Step 4) Reading the URL Parameters

Let's say we pressed the second button, our relative URL will now be:/my-page-slug?page=2

As we showed you in the tips, Liquid can read this parameter at the following dot-notation path. This will output the value on the Page: {{context.params.page}}

Or you can store this in a variable, which we'll need to do here:

{% assign current_page = context.params.page %}

By the way, the keys in context.params are dynamically generated for any query parameter in the URL, so you can pass through any variable you like with this method.

Step 5) Feeding the Variables into the Query

a) First, let's set a default value, just in case a User arrives at the Page without setting the Parameter:

{% assign current_page = context.params.page | default: 1 %}

b) The query is expecting an integer, so let's apply an Integer filter that will change the type to an Int without changing the value:

{% assign current_page = context.params.page | default: 1 | plus: 0 %}

c) Let's add the graphql tag with the variable parameter.

{% assign current_page = context.params.page | default: 1 | plus: 0 %}
{% graphql my_result = "gallery_by_page",
page: current_page
%}

Step 6) Output the Results

We can output the results using the variable name we defined in the graphql tag.

{% assign current_page = context.params.page | default: 1 | plus: 0 %}
{% graphql my_result = "gallery_by_page",
page: current_page
%}
{{my_result}}

If pressing the HTML anchors changes the results by fetching different "pages" of JSON results, you've been successful. Congratulations.

If you're having difficulty with any of these steps still, please don't hesitate to ask for help on the Forum.

Full Code

Liquid

{% graphql my_result = "gallery_by_page",
page: current_page
%}
<pre>{{my_result}}</pre>
<ul>
  <li><a href="{{context.headers.PATH_NAME}}?page=1">1</a></li>
  <li><a href="{{context.headers.PATH_NAME}}?page=2">2</a></li>
  <li><a href="{{context.headers.PATH_NAME}}?page=3">3</a></li>
</ul>

GraphQL

query gallery_by_page($page: Int) {
  records(per_page: 2, page: $page, filter: {table: {value: "webapp_1"}}) {
    current_page #optional
    results {
      properties
      id
    }
  }
}

Optional- Taking this further

The next steps give you ideas for how to take this further. They are not part of the initial challenge!

Step 7) Output a Layout (Optional)

These JSON results don't look great. Remember, you can use Liquid to pass the results into a Layout- if you can find that Layout's relative path in Code Editor.

{% assign current_page = context.params.page | default: 1 | plus: 0 %}
{% graphql my_result = "gallery_by_page",
page: current_page
%}
{% assign result_array = my_result.records.results %}
{% for this in result_array %}
  {% include 'layouts/webapps/webapp_1/list/my_layout_name', this: this %}
{% endfor %}

However, you won't have access to the user-friendly names for fields in that Layout, because GraphQL will output the raw database IDs for fields.

You'll want to target fields in this Layout with syntax like:{{this.properties.webapp_field_1_2}}

You can view the database IDs for fields in the Admin using the toggle in the top-right of the screenshot, or you can look at the keys in the JSON results.

Step 8) Use the Results of the Query to only show buttons you need. (Optional)

By returning total_pages from the query, we'll know exactly how many Pagination buttons to display:

query gallery_by_page($page: Int) {
  records(per_page: 3, page: $page, filter: {table: {value: "webapp_1"}}) {
    current_page
    total_pages
    results {
      properties
      id
    }
  }
}

You can then use this to manipulate the HTML pagination controls:

<ul>
  {% for page in (1..my_result.records.total_pages) %}
    <li><a href="{{context.headers.PATH_NAME}}?page={{page}}">1</a></li>
  {% endfor %}
</ul>

Next Time

Next time, we'll learn how to sort the results of your Query.

Let's go!

In this example we're going walk through, step by step, how to create a Website Theme Module that could either be used as a private module for your agency or shared publicly in the marketplace to deliver turnkey site solutions to your clients and more.

It is recommended that you download our example Theme Demo Module Repository from GitHub so that you have all of the code and asset files available at each step of this guide and can easily follow along to and have your module end up looking exactly the same.

Create Your Module

The first step to building your module is to create a listing for it in Siteglide. Within your Portal from the left-hand menu, select "Custom Modules" and then click the blue "+ Add New Module" button in the top right-hand corner.

You only need to fill in basic information into the core fields. Checkout the Create your Module in Siteglide doc for more information.

Remember to note down your newly generated Vanity ID.

Create Your Folder Structure

First, create a fresh staging site for your module. Checkout Create Your Staging Site : for more information on this step.

Second, create a folder for your project on your local machine. Working within your new project folder, connect to your new staging site via CLI to pull the initial site files down onto your computer.

Next, create a top level folder called modules/<module_name>/public within your project folder. Because we are creating a basic theme Module, we don’t need to create the private top level folder. Checkout Top Level Folders for more info.

Assets

Within the public folder, we want to add in the core assets our Theme Module will use. There are three folders we want to copy in to our own Module project folder:

• bootstrap5-plain-assets - Core Bootstrap 5 image assets which our Theme pages will display.

• js - Core Bootstrap 5 JS files along with a custom JS file which our Theme pages will run using.

• scss - Core Bootstrap 5 CSS files along with a custom CSS file which will Style our Theme pages.

Open the Module_Siteglide_ThemeDemo project folder you downloaded earlier and navigate into modules/<module_name>/public/assets. From here, drag and drop all three bootstrap5-plain-assets, js & scss folders into your own Module project assets folder.

Views

Next we’re going to add in various core elements such as Pages, a Page Template, Header & Footer.

First, within your modules/<module_name>/public folder, create a new folder called views. Inside the views folder, we'll be creating several new folder structures to house the various files we’d like to include. Below I’ll list each of these directories and give an explanation as to what they will be used for:

• layouts/templates - A Page Template file used to wrap all of our theme pages.

• pages - Several Pages we would like to include in our module and display on the site.

• partials/includes/header - Page Header file used to store the Header including main navigation.

• partials/includes/footer - Page Footer file used to store the Footer including secondary navigation.

Setting Pages up with appropriate Template, Header & Footer files allows us to only write the code once and apply it consistently across all of our theme pages. It also makes it easier to update later if we’d like to. For more information on page structure checkout: Templates - Getting Started.

Open the Module_Siteglide_ThemeDemo project folder you downloaded earlier and navigate into modules/<module_name>/public/views. From here, drag and drop all three layouts, pages & partials folders into your own Module project views folder.

Correcting Your Files

As we’ve been copying files from the Theme Demo Module, we'll need to update the module name in some paths written in the files. Open up your IDE and bulk find/replace module_76 with your <module_name>.

Module Setup Files

Next, we want to create one of the setup file options available: install-process.json.

Create a file called install-process.json on the root folder of your Module Project (alongside /modules/). Checkout Module Setup Files for more info.

Add the following Code Snippet to your newly created Install Process file:

{
  "1.0.0": "set_homepage"
}

Adding this line of code to the install-process.json file will ensure that when a user installs our module, the home/start page is automatically applied as part of the installation. Otherwise, the existing home/start page on a site will be honoured.

View Your Staging Module Site

Now that we have added all of the core assets and views to our module, let’s see it in action!

Using CLI run the deploy command to send all of the files within your project folder up to your staging site.

Open your staging site to view your work both front-end and back end.

Your site should now look and behave like this front-end: Module Siteglide Theme Demo.

If you’re happy everything looks as it should, continue to the final step. If not, check back along the steps above to make sure you've not missed anything.

Submit Module For Approval

First, delete the marketplace_builder folder from your project folder on your local machine. We don’t want to include this to avoid overwriting any pre-existing content on sites which install our module.

Preparing To Submit

Follow the checklist to confirm your Theme Module is ready for submission:

• you've got all your files (assets, logic, layouts etc.) in the correct folders (private, or public)

• Your module folder is named in the correct format of <module_name>

• You have not included a marketplace_builder folder

• you've prepared your setup.json file if a model is required for this Module and the Module ID in setup.json matches the Vanity ID in Siteglide Admin

Here is what your project folder should now look like:

GitHub

Now that we have prepared our files, if you haven’t already create a new GitHub Repository and commit your project folder to it.