Organizing Pages Under Login Pages

Overview

Knack now supports more flexible organization of login-protected pages. You can add new parent pages under an existing login page and move public page groups into a login-protected parent page. This makes it easier to build clean, well-structured apps without login pages scattered throughout your page tree.

👍

This feature is available in Next-Gen only

Adding a Parent Page Under an Existing Login Page

You can create a new parent page as a child of an existing login page. This is useful when you want to expand a protected area of your app — for example, adding a new section to a member portal that already has a login page in place.

Because the new parent page sits under the login page, it inherits the login requirement. Any child pages you add beneath it are also protected, giving you a clean hierarchy where the authentication boundary is clear.

Moving Public Page Groups Into a Login Parent Page

You can move existing public page groups into a login-protected parent page. This lets you convert public areas of your app into protected ones without rebuilding pages or reconfiguring views.

When you move a page group under a login parent, all pages in that group become protected by the login page. This is particularly helpful when your app evolves and pages that were originally public now need to sit behind authentication.

When to Use This

• Building member portals. Start with a login page, then add parent pages underneath it for different sections — dashboards, account settings, resources — all protected by a single login.
• Restructuring your app. If your page tree has become cluttered with individual login pages, you can consolidate by moving page groups under a shared login parent.
• Converting public pages to protected. When a set of pages that started as public needs to be locked down, move the group into a login parent rather than recreating the pages behind a new login.

Tips

• Use login parent pages to reduce sprawl. Instead of creating a new login page for every protected section, nest related pages under a single login parent. This keeps your page tree focused on content rather than authentication scaffolding.
• Plan your hierarchy around access boundaries. Group pages by who needs to see them. A single login page with well-organized parent pages underneath is easier to manage — and easier for new builders to understand — than multiple login pages scattered across the tree.

The improvements in this release are built around eliminating page sprawl

• Moves preserve everything. Views, rules, permissions, and nested child pages travel with the page when it moves into or out of a Login.

The net result is fewer orphaned pages, fewer duplicates, and a Page Editor that more closely reflects how the app is actually used.

Adding a new page under a Login

To create a new page that's protected by an existing Login:

1. In the Page Editor, locate the Login page you want to nest the new page under.
2. Add a new page using the Add Page option on the Login.
3. Configure the new page as you normally would.

The new page is created as a direct child of the Login, automatically inherits its protection, and isn't accessible without authentication.

Moving a public page under a Login

You can move a top-level public page into an existing Login page:

1. From the public page's three-dot menu, choose Move page group.
2. Pick a destination from the list. Only Login pages appear as eligible destinations — public pages aren't shown, since public-to-public nesting isn't supported.
3. Review the confirmation modal warning that the page will become login-protected.
4. Confirm the move.

After confirmation:

• The page and all nested child pages move under the Login and inherit its protection.
• Existing views, rules, and permissions on the moved page are preserved as-is.
• The page now requires authentication; visiting it without a session redirects to login.
• The page appears in the nav for users with access to that Login.

If you cancel, no changes are made and the page stays public.

Removing login protection from a page group

To make a protected page group public:

1. From the protected parent page's three-dot menu, choose the option to remove the login.

1. Review the confirmation modal warning that the page will become publicly accessible.
2. Confirm.

After confirmation:

• The page and all nested child pages become accessible without authentication.
• If the page is set to appear in the nav menu, it will show in the Live App nav for all users.

Note: Move page group is disabled while a page is still under a Login. Remove parent login protection first, then move the page if you'd like to relocate it.

Adding a dropdown menu with mixed pages

Dropdown menus can include any existing parent pages, regardless of login protection:

1. Add a new dropdown menu from the page editor.
2. Select the parent pages to include. Both public and protected pages are eligible.
3. Save.

A few details worth knowing:

• Each page in the dropdown keeps its existing access settings — no confirmation modal is needed because nothing about the page's protection is changing.
• Nested child pages come along with their parent and keep their original settings.
• A single dropdown menu can mix public and protected pages; each page respects its own login rules independently.
• To move a page group that lives inside a dropdown, remove it from the dropdown first. Move page group is disabled for pages within a dropdown.

👍

To move a page group that lives inside a dropdown, remove it from the dropdown first

What's not supported with this feature

These move types aren't available:

• Moving a protected page from one Login page to a different Login page. You will need to remove the login protection first.
• Nesting a public page under another public page.