<commit_before>---
title: Pages
taxonomy:
    category: docs
process:
    twig: true
---

In Grav-speak, **Pages** are the fundamental building-blocks of your site. They are how you write content and provide navigation in the Grav system.

Combining content and navigation ensures that the system is intuitive to use for even the most inexperienced of content authors. However, this system, in conjunction with powerful taxonomy capabilities, is still powerful enough to handle complex content requirements.

Grav natively supports **3 types of Pages** that allow you to create a rich selection of web content. Those types are:

![Grav Page Types](page-types.png)

#### Regular Page

![Standard Page](content-standard.jpg?classes=shadow)

A regular Page is generally a single page such as a **blog post**, **contact form**, **error page** etc. This is the most common type of page that you will create. By default a Page is considered a regular page unless you tell Grav otherwise.

When you download and install the **Core Grav** package, you are greeted by a standard page. We covered creating a simple regular Page in the [Basic Tutorial](/basics/basic-tutorial).

#### Listing Page

![Listing Page](content-listing.jpg?classes=shadow)

This is really an extension of a regular Page. This is a page that has a reference to a collection of pages.

The simplest approach to setting this up is to create **child-pages** below the Listing Page. An example of this would be a **blog listing page**, where you would display a summary list of blog posts that exist as child-pages.

There is also some configuration settings to **control the order** of the listing as well as a **limit on the number of items**, and whether or not **pagination** should be enabled.

!! A sample **Blog Skeleton** using a **Listing Page** can be found in the [Grav Downloads](https://getgrav.org/downloads/skeletons).

#### Modular Page

![Modular Page](content-modular.jpg?classes=shadow)

A Modular Page is a special type of listing page because it actually builds a **single page** from its **child-pages**. This allows for the ability to build very complex **one-page layouts** from Modules. This is accomplished by constructing the **Modular Page** from multiple **Module-folders** found in the page's primary folder.

!! A sample **One-Page Skeleton** using a **Modular Page** can be found in the [Grav Downloads](https://getgrav.org/downloads/skeletons).

Each of these page types follow the same basic structure, so before we can get into the nitty-gritty of each type, we must explain how pages in Grav are constructed.

!! A Module, because it is intended to be part of another page, is inherently not a page you can reach directly via a URL. Because of this, all modular pages are by default set as **non-routable**.

## Folders

All content pages are located in the `/user/pages` folder. Each **Page** should be placed in its own folder.

!! Folder names should also be valid **slugs**. Slugs are entirely lowercase, with accented characters replaced by letters from the Latin alphabet and whitespace characters replaced by a dash or an underscore, in order to avoid being encoded.

Grav understands that any integer value followed by a period will be solely for the purpose of ordering, and is removed internally in the system. For example, if you have a folder named `01.home`, Grav will treat this folder as `home`, but will ensure that with default ordering, it comes before `02.blog`.

![Grav Folder Example](page-folders.png)

Your site must have an entry-point so that it knows where to go when you point your browser to the root of your site. For example if you were to enter `http://yoursite.com` in your browser, by default Grav expects an alias `home/`, but you can override the home-location by changing the `home.alias` option in the [Grav configuration file](/basics/grav-configuration).

**Module-folders** are identified by an underscore (`_`) before the folder name. This is a special folder type that is intended to be used only with **modular content**.  These are **not routable** and **not visible** in the navigation. An example of a Module-folder would be a folder such as `user/pages/01.home/_header`. Home is actually configured as a **modular page** and would be constructed from the `_header`, `_features`, and `_body` Modules.

The textual name of each folder defaults to the _slug_ that the system uses as part of the URL. For example if you have a folder such as `/user/pages/02.blog`, the slug for this page would default to `blog`, and the full URL would be `http://yoursite.com/blog`. A blog item page, located in `/user/pages/02.blog/blog-item-5` would be accessible via `http://yoursite.com/blog/blog-item-5`.

If no number is provided as a prefix of the folder name, the page is considered to be **invisible**, and will not show up in the navigation. An example of this would be the `error` page in the above folder-structure.

!! This can actually be overridden in the page itself by setting the [visible parameter](/headers#visible) in the headers.

## Ordering

When dealing with collections, there are several options available to control how folders are ordered. The most important option is set in the `content.order.by` of the page configuration settings. The options are:

| Ordering     | Details                                                                                                                                              |
| :----------  | :----------                                                                                                                                          |
| **default**  | The order based on the file system, i.e. `01.home` before `02.advark`                                                                                |
| **title**    | The order is based on the title as defined in each page                                                                                              |
| **basename** | The order is based on the alphabetic folder without numeric order                                                                                    |
| **date**     | The order based on the date as defined in each page                                                                                                  |
| **modified** | The order based on the modified timestamp of the page                                                                                                |<commit_msg>Corrected link under Folders block (#540)<commit_after>---
title: Pages
taxonomy:
    category: docs
process:
    twig: true
---

In Grav-speak, **Pages** are the fundamental building-blocks of your site. They are how you write content and provide navigation in the Grav system.

Combining content and navigation ensures that the system is intuitive to use for even the most inexperienced of content authors. However, this system, in conjunction with powerful taxonomy capabilities, is still powerful enough to handle complex content requirements.

Grav natively supports **3 types of Pages** that allow you to create a rich selection of web content. Those types are:

![Grav Page Types](page-types.png)

#### Regular Page

![Standard Page](content-standard.jpg?classes=shadow)

A regular Page is generally a single page such as a **blog post**, **contact form**, **error page** etc. This is the most common type of page that you will create. By default a Page is considered a regular page unless you tell Grav otherwise.

When you download and install the **Core Grav** package, you are greeted by a standard page. We covered creating a simple regular Page in the [Basic Tutorial](/basics/basic-tutorial).

#### Listing Page

![Listing Page](content-listing.jpg?classes=shadow)

This is really an extension of a regular Page. This is a page that has a reference to a collection of pages.

The simplest approach to setting this up is to create **child-pages** below the Listing Page. An example of this would be a **blog listing page**, where you would display a summary list of blog posts that exist as child-pages.

There is also some configuration settings to **control the order** of the listing as well as a **limit on the number of items**, and whether or not **pagination** should be enabled.

!! A sample **Blog Skeleton** using a **Listing Page** can be found in the [Grav Downloads](https://getgrav.org/downloads/skeletons).

#### Modular Page

![Modular Page](content-modular.jpg?classes=shadow)

A Modular Page is a special type of listing page because it actually builds a **single page** from its **child-pages**. This allows for the ability to build very complex **one-page layouts** from Modules. This is accomplished by constructing the **Modular Page** from multiple **Module-folders** found in the page's primary folder.

!! A sample **One-Page Skeleton** using a **Modular Page** can be found in the [Grav Downloads](https://getgrav.org/downloads/skeletons).

Each of these page types follow the same basic structure, so before we can get into the nitty-gritty of each type, we must explain how pages in Grav are constructed.

!! A Module, because it is intended to be part of another page, is inherently not a page you can reach directly via a URL. Because of this, all modular pages are by default set as **non-routable**.

## Folders

All content pages are located in the `/user/pages` folder. Each **Page** should be placed in its own folder.

!! Folder names should also be valid **slugs**. Slugs are entirely lowercase, with accented characters replaced by letters from the Latin alphabet and whitespace characters replaced by a dash or an underscore, in order to avoid being encoded.

Grav understands that any integer value followed by a period will be solely for the purpose of ordering, and is removed internally in the system. For example, if you have a folder named `01.home`, Grav will treat this folder as `home`, but will ensure that with default ordering, it comes before `02.blog`.

![Grav Folder Example](page-folders.png)

Your site must have an entry-point so that it knows where to go when you point your browser to the root of your site. For example if you were to enter `http://yoursite.com` in your browser, by default Grav expects an alias `home/`, but you can override the home-location by changing the `home.alias` option in the [Grav configuration file](/basics/grav-configuration).

**Module-folders** are identified by an underscore (`_`) before the folder name. This is a special folder type that is intended to be used only with **modular content**.  These are **not routable** and **not visible** in the navigation. An example of a Module-folder would be a folder such as `user/pages/01.home/_header`. Home is actually configured as a **modular page** and would be constructed from the `_header`, `_features`, and `_body` Modules.

The textual name of each folder defaults to the _slug_ that the system uses as part of the URL. For example if you have a folder such as `/user/pages/02.blog`, the slug for this page would default to `blog`, and the full URL would be `http://yoursite.com/blog`. A blog item page, located in `/user/pages/02.blog/blog-item-5` would be accessible via `http://yoursite.com/blog/blog-item-5`.

If no number is provided as a prefix of the folder name, the page is considered to be **invisible**, and will not show up in the navigation. An example of this would be the `error` page in the above folder-structure.

!! This can actually be overridden in the page itself by setting the [visible parameter](/content/headers#visible) in the headers.

## Ordering

When dealing with collections, there are several options available to control how folders are ordered. The most important option is set in the `content.order.by` of the page configuration settings. The options are:

| Ordering     | Details                                                                                                                                              |
| :----------  | :----------                                                                                                                                          |
| **default**  | The order based on the file system, i.e. `01.home` before `02.advark`                                                                                |
| **title**    | The order is based on the title as defined in each page                                                                                              |
| **basename** | The order is based on the alphabetic folder without numeric order                                                                                    |
| **date**     | The order based on the date as defined in each page                                                                                                  |
| **modified** | The order based on the modified timestamp of the page                                                                                                |
{'fraction_non_alphanumeric': 0.07433573951773921, 'fraction_numerical': 0.0028413454154507757, 'mean_word_length': 2.557224801966676, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 71, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5204753', 'n_tokens_mistral': 2991, 'n_tokens_neox': 2878, 'n_words': 1725}