Page Settings

Page Settings control how an individual Page, Form, or Structured Page is published, accessed, described, styled, and configured within an ioLoop Project.

Each page has its own settings, allowing you to customize its behavior independently of other pages. Where applicable, page-level settings can override defaults defined at the Project level.

To open Page Settings, open the page in the Page Editor and select Settings.

The Page Settings dialog is organized into six sections:

• Publishing — Page availability and URL configuration.
• Access (Security) — Public and restricted access.
• Page Info, SEO & Social — Browser metadata, search information, and social sharing.
• Fonts — Page-specific typography.
• Code — JavaScript and CSS assets included on the page.
• Advanced — Custom HTML head content, CSS, and specialized layout options.

Select Save to apply your changes. Changes saved in Page Settings become part of the Project's development state and must be published before they affect the published application.

Publishing

Publishing settings determine whether a page is available in the published application and the URL path used to access it.

Setting	Description
Active	Controls whether the page is available in the published Project.
Page URL	Defines the URL path for accessing the page.

Active

The Active setting determines whether the page is enabled in the published application.

• On — The page is available through its configured URL, subject to its Access settings.
• Off — The page remains in the Project but is not available as an active published page.

Deactivating a page is useful when it is under development, temporarily withdrawn, or being retained for future use.

Deactivation does not delete the page, its Page Flow, or its associated configuration.

If other pages or workflows reference a deactivated page, those references may no longer work as expected in the published application. Review dependencies when changing a page's availability.

Page URL

Page URL defines the path used to access the page within the published Project.

The Project domain is configured separately. Page URL specifies the path relative to that domain.

The URL format depends on the page type.

Page Type	URL Prefix
Page	https://your-domain/
Structured Page	https://your-domain/
Form	https://your-domain/forms/

For example, a Page configured with the URL events is accessible at:

https://your-domain/events

A Form configured with the URL EventRegistration uses:

https://your-domain/forms/EventRegistration

If Page URL is blank, ioLoop uses the Page/Form ID as the default path.

The Page/Form ID and Page URL are separate properties. Changing Page URL does not change the page's ID or its display name in the Project Editor.

URL Rules

The following restrictions apply when configuring Page URL:

• Do not begin the path with /.
• Forms cannot contain a directory path.
• Pages and Structured Pages can contain at most one directory path.
• The first path segment cannot be a reserved Project path, such as forms, assets, or runner.

For Pages and Structured Pages, these examples illustrate the path structure:

Page URL	Valid	Explanation
dashboard	Yes	A single path segment.
account/profile	Yes	One directory level.
account/settings/profile	No	More than one directory level.
/dashboard	No	Begins with /.
assets/images	No	Uses a reserved first path segment.

For Forms, use a single path segment, such as ContactForm, rather than contact/ContactForm.

Changing an Existing URL

Changing a page's URL may affect other parts of the application.

Review references in:

• Menus and navigation elements.
• Buttons and hyperlinks.
• Page Flow navigation actions.
• Widgets and other pages that open or reference the page.
• External websites, shared links, and bookmarks.

The page's previous URL should not be assumed to remain available after the change is published.

After changing a URL, save the settings, test the new path, and update affected references before publishing.

Access (Security)

Access (Security) controls who is permitted to open the page in the published application.

A page can be configured for public access or restricted to authorized Project Users and User Groups.

The available controls include:

• Password Protected
• Project User access
• User Group access

Password Protected

Password Protected is a read-only status that reflects the page's configured access restrictions. It cannot be changed independently.

The status is automatically determined by the selected access configuration:

Access Configuration	Password Protected
Public access is allowed	No
Access is restricted to Project Users or User Groups	Yes

To change whether a page is password protected, modify its access configuration.

Password Protected indicates that access is restricted through the Project's authentication and authorization system. It does not represent a separate password assigned specifically to the page.

Project Users and User Groups

Project Users are the people who use the published application. They are different from Creators, who collaborate on developing the Project through the Project Editor.

User Groups provide a way to organize Project Users and configure access for multiple users together.

For example, an application might contain:

Page	Intended Access
Public Landing Page	Public
Customer Dashboard	Authorized customers
Administration Page	Authorized administrators
Internal Reports	Selected Project Users or User Groups

Use the page's access configuration to determine which users or groups can open it.

Project Users and User Groups are managed under the Project Editor's Settings area. See Users to create application accounts and assign membership. See User Groups for Public, All Users, custom groups, Admin, and role-level behavior.

Page Access vs. Data Authorization

Page-level access restrictions control access to the page itself. They do not automatically secure every Database operation, API, or Cloud Flow function associated with it.

For example, protecting an administration page does not by itself guarantee that the Database records displayed on that page cannot be accessed through other interfaces.

For protected application functionality:

• Configure appropriate Database access rules.
• Enforce authorization in Cloud Flow when operations require trusted server-side checks.
• Do not rely on hidden interface elements or Page Flow conditions as security controls.

Page Flow executes in the browser. It is appropriate for client-side interaction and presentation, but must not be the sole enforcement point for sensitive permissions.

Page Info, SEO & Social

Page Info, SEO & Social configures information used by browsers, search engines, and social sharing services.

These settings are particularly useful for public websites, landing pages, product pages, event pages, and other content intended to be discovered or shared.

Setting	Description
Title	The page title used by the browser and potentially by search engines.
HTML Meta Desc	The page's HTML meta description.
Page Theme Color	A page-specific browser theme color.
OG Title	Title used in Open Graph social metadata.
OG Desc	Description used in Open Graph social metadata.
OG Image	Image URL used for social sharing previews.
OG Type	Open Graph content type.
OG URL	URL representing the shared page.

Title and HTML Meta Description

Title defines the document title, commonly displayed in the browser tab and used as a candidate title in search results.

For example:

Upcoming Events | My Events Portal

HTML Meta Desc defines the page's meta description.

For example:

Browse upcoming events, view availability, and register online.

Search engines may use the meta description when generating result snippets, but they can also generate descriptions from page content.

Use descriptive, page-specific titles and descriptions rather than repeating the same values across unrelated public pages.

Page Theme Color

Page Theme Color defines a page-specific theme color that supporting browsers may use for parts of their interface.

Leave the field blank to use the Project's default theme color.

This setting is separate from the colors used in the page's HTML elements and CSS.

Open Graph Metadata

Open Graph metadata describes a page when its URL is shared through compatible social networks, messaging applications, and other services.

The available fields include:

• OG Title — The title representing the shared content.
• OG Desc — A short description of the content.
• OG Image — An image associated with the shared page.
• OG Type — The type of content represented.
• OG URL — The URL representing the content.

For example, an event details page might use:

Field	Example
OG Title	Annual Technology Conference
OG Desc	Explore sessions, speakers, and registration information.
OG Image	https://your-domain/assets/event-banner.jpg
OG Type	website
OG URL	https://your-domain/events

The examples illustrate commonly used Open Graph values. Use values supported by the corresponding settings fields.

OG Image

The OG Image field accepts an image URL.

You can also select Browse to choose an image from the Project's Media library.

Use an image that clearly represents the page and can be accessed by external services.

A commonly used Open Graph image size is 1200 × 630 pixels, with an approximately 1.91:1 aspect ratio. This is a general compatibility recommendation, not a required ioLoop image dimension.

Social platforms may cache metadata and images, so changes to a shared page's preview might not appear immediately.

OG URL

OG URL should represent the public URL associated with the page.

For public pages, use a complete URL that corresponds to the intended published location.

If you change a page's URL or Project domain, review its OG URL configuration as well.

Search and Social Visibility

Metadata helps describe content but does not guarantee search indexing or a specific sharing preview.

Search engines and social platforms determine how they crawl and present content. Pages that require authentication may not be accessible to external crawlers.

For public-facing content, verify the published URL and inspect how its metadata appears when shared.

Fonts

Fonts controls typography at the individual page level.

Page-specific font settings are useful when a particular page requires different typography from the rest of the Project, while Project-level typography provides a consistent default across the application.

The available options depend on the page type.

Pages and Forms

For Pages and Forms, the Fonts section includes:

Setting	Description
Font List	Fonts available specifically to the page.
Heading Font	Font selection for headings.
Body Font	Font selection for body content.

You can add fonts to the page-level Font List and select fonts for headings and body content.

Fonts configured at the Project level are also available in the font selectors.

Structured Pages

Structured Pages use the Project's font list.

Their Page Settings provide Heading Font and Body Font selections without a separate page-level Font List.

Choosing Page-Level Fonts

Use page-level typography when a page needs a distinct visual treatment, such as a campaign landing page or branded experience.

For consistent application-wide styling, prefer defining fonts at the Project level.

Remember that individual element styling and custom CSS can also affect how text is rendered. When typography differs from the selected fonts, review the page's element styles and CSS.

Code

The Code section allows you to include JavaScript and CSS assets authored under Frontend → Code in the current page.

These assets can provide reusable functionality, custom styling, or third-party browser libraries.

Page-level Code configuration is useful when specific JavaScript or CSS assets are required by an individual page rather than the entire Project.

Common uses include:

• Page-specific CSS styles.
• JavaScript utility functions used by the page.
• Third-party JavaScript libraries.
• Custom functionality supporting Page Flow.
• Specialized styling or behavior for individual pages.

Selecting Code Assets

Use the Code section to select which JavaScript and CSS assets should be included on the page.

Only the selected assets are included through this page-level configuration.

Assets are authored and maintained under Frontend → Code, allowing the same asset to be reused across multiple pages when needed.

Load Order

The load order of selected Code assets can be adjusted.

Load order determines the sequence in which the selected assets are included on the page.

This is particularly important for JavaScript assets that depend on functionality defined by another asset.

For example, consider the following JavaScript assets:

Load Order	Asset	Purpose
1	chart-library	Provides charting functionality.
2	chart-helpers	Defines utilities that use the charting library.
3	dashboard	Implements page-specific dashboard behavior.

In this example, the charting library should be loaded before the code that depends on it.

CSS asset ordering can also influence the resulting appearance when styles have the same specificity and otherwise equal cascade precedence.

Arrange the selected assets in the appropriate order to account for dependencies and styling requirements.

Page-Level vs. Project-Level Code

Scope	When to Use
Page-level Code	Include assets required only by a particular page.
Project-level Code	Include assets intended to be available across the application.

Use Project-level Code for shared utilities or styles and page-level Code for functionality or styling specific to one page.

Security Consideration: JavaScript included on a page runs in the browser and must not contain secrets, private API keys, or privileged server-side logic. Use Cloud Flow for operations requiring trusted server-side execution.

For more information, see Code.

Advanced

Advanced contains specialized settings for customizing the page beyond the standard configuration options.

The available settings include:

Setting	Description
HTML Head Additions	Adds page-specific content to the HTML document's head.
Custom Style definitions	Defines CSS styles for the page.
Footer Type	Configures footer behavior for Structured Pages.

HTML Head Additions

Select Edit next to HTML Head Additions to open the editor.

This setting allows additional content to be included in the HTML <head> section of the page.

Common uses include:

• Additional metadata.
• Links to external stylesheets.
• Supported external scripts and third-party browser libraries.
• Page-specific head-level configuration.
• Integrations that require supported HTML head markup.

For example, an external stylesheet can be referenced using:

<link rel="stylesheet" href="https://example.com/styles.css">

Use HTML Head Additions when a page requires head-level content that is not provided by the standard Page Settings fields.

Avoid adding duplicate or conflicting metadata when equivalent settings already exist under Page Info, SEO & Social.

For JavaScript and CSS assets managed within ioLoop, prefer using Frontend Code when appropriate. For a broader explanation of using Head Additions with custom frontend development, see Standards-Based Frontend.

Custom Style Definitions

Select Edit next to Custom Style definitions to open the CSS editor.

This setting lets you define CSS that applies to the page.

For example:

.page-highlight {
  background-color: #f5f7fa;
  border-radius: 8px;
  padding: 16px;
}

These styles can be used by matching page elements, allowing specialized presentation beyond the visual editor's standard options.

Use Custom Style definitions for small or localized CSS requirements.

For larger stylesheets, reusable classes, or styling shared across multiple pages, use a CSS asset managed through Frontend → Code.

When creating custom CSS, consider selector specificity and potential conflicts with styles already defined by the page or Project.

Footer Type

Footer Type is available for Structured Pages and controls how the page's footer behaves within the layout.

Two options are available:

Footer Type	Behavior
Fixed	Makes the footer sticky, allowing it to remain in its fixed position as the page is viewed or scrolled.
Standard	Places the footer at the end of the page content. The footer is not fixed and appears when the user reaches the bottom of the page.

Use Fixed when the footer should remain accessible as part of the page's persistent interface.

Use Standard when the footer should follow the natural document layout and appear after the page content.

For example, a page containing a long article or report may use Standard, while a page requiring persistent footer controls may use Fixed.

Preview the Structured Page at different viewport sizes to verify that the selected footer behavior works with the page's content and layout.

Saving and Applying Settings

After changing Page Settings, select Save to apply the configuration to the Project's development state.

Settings are validated before they are saved.

If an invalid value is found, the dialog displays an error. Use Back to return to the settings and correct the problem.

For example, an invalid Page URL may prevent the settings from being saved until the path satisfies the supported URL rules.

Closing the settings dialog without saving does not apply unsaved changes.

Saving vs. Publishing

Saving Page Settings does not immediately update the published application.

The normal workflow is:

1. Configure and save the page settings.
2. Use Preview to test the page in the development environment.
3. Review the configuration and any affected page references.
4. Use Publish Project to release the changes.
5. Use Launch Project to verify the published application.

This separation allows you to prepare and test configuration changes without immediately affecting application users.

Common Configuration Patterns

Keep a Page as a Draft

Turn Active off and save the settings.

The page remains available in the Project Editor for further development but is not served as an active page after the updated Project is published.

Change a Page's Public URL

Update Page URL and save the settings.

Review navigation links, buttons, Page Flow operations, and external references to the previous URL before publishing.

Restrict an Administration Page

Configure Access so that only the intended Project Users or User Groups can open the administration page.

Also configure Database access rules and server-side authorization for protected records and operations.

Prepare a Public Landing Page for Sharing

Configure Title, HTML Meta Desc, OG Title, OG Desc, OG Image, OG Type, and OG URL.

Verify that the published page and its social image are publicly accessible where intended.

Add Page-Specific JavaScript or CSS

Use Code to attach managed JavaScript and CSS assets to the page.

Use Custom Style definitions for localized CSS or HTML Head Additions for specialized head-level content.

Where to Go Next

• Managing Pages — Learn how to manage pages, including their status, access, and URLs.
• Page Editor — Configure and edit page content.
• Previewing — Test your page before publishing.
• Page Flow — Add client-side behavior, data interactions, and Cloud Flow calls.
• Code — Manage reusable JavaScript and CSS assets.
• Users — Create and manage the Project Users who can authenticate to the application.
• User Groups — Configure the group identities and role levels used by Page access.