Page Collections

In Grav, the most common type of collection is a list of pages that can be defined either in the page's frontmatter or in the twig itself. The most common is to define a collection in the frontmatter. With a collection defined, it is available in the Twig of the page to do with as you wish.

By using page collection methods or looping through each page object and using the page methods or properties you can do powerful things. Common examples of this include displaying a list of blog posts or displaying modular sub-pages to render a complex page design.

Collection Object

When you define a collection in the page header, you are dynamically creating a Grav Collection that is available in the page's Twig. This Collection object is iterable and can be treated like an array which allows you to do things such as:

 1{{ dump(page.collection[page.path]) }}

Example Collection Definition

An example collection defined in the page's frontmatter:

 1content:
 2    items: '@self.children'
 3    order:
 4        by: date
 5        dir: desc
 6    limit: 10
 7    pagination: true

The content.items value in the page's frontmatter tells Grav to gather up a collection of items and information passed to this defines how the collection is to be built.

This definition creates a collection for the page that consists of all child pages sorted by date in descending order with pagination showing 10 items per-page.

Pagination links are added only if Pagination plugin is installed and enabled.

Accessing Collections in Twig

When this collection is defined in the header, Grav creates a collection page.collection that you can access in a twig template with:

 1{% for p in page.collection %}
 2<h2>{{ p.title|e }}</h2>
 3{{ p.summary|raw }}
 4{% endfor %}

This simply loops over the pages in the collection displaying the title and summary.

You can also include an order parameter to change the default ordering of pages:

 1{% for p in page.collection.order('folder','asc') %}
 2<h2>{{ p.title|e }}</h2>
 3{{ p.summary|raw }}
 4{% endfor %}

Collection Headers

To tell Grav that a specific page should be a listing page and contain child-pages, there are a number of variables that can be used:

Summary of collection options

We will cover these more in detail.

Root Collections

@root.pages - Top level pages

This can be used to retrieve the top/root level published pages of a site. Particular useful for getting the items that make up the primary navigation for example:

 1content:
 2    items: '@root.pages'

An alias of '@root.children' is also valid. Using '@root' is deprecated as its meaning can change in the future.

@root.descendants - All the pages

This will effectively get every page in your site as it recursively navigates through all the children from the root page down, and builds a collection of all the published pages of a site:

 1content:
 2    items: '@root.descendants'

@root.all - All the pages and modules

This will do the same as above, but it includes all the published pages and modules of the site.

 1content:
 2    items: '@root.all'

Self Collections

@self.page - Current page only

This will return a collection containing only the current page.

 1content:
 2    items: '@self.page'

An alias of '@self.self' is also valid.

@self.parent - The parent page of the current page

This is a special case collection because it will always return just the parent of the current page:

 1content:
 2    items: '@self.parent'

@self.siblings - Siblings of the current page

This collection will collect all the published pages at the same level of the current page, excluding the current page:

 1content:
 2    items: '@self.siblings'

@self.children - Children of the current page

This is used to list the published children of the current page:

 1content:
 2    items: '@self.children'

An alias of '@self.pages' is also valid. Using '@self' is deprecated as its meaning can change in the future.

@self.modules - Modules of the current page

This method retrieves only published modules of the current page (_features, _showcase, etc.):

 1content:
 2    items: '@self.modules'

Using alias of '@self.modular' is deprecated.

@self.all - Children and modules of the current page

This method retrieves only published children and modules of the current page:

 1content:
 2    items: '@self.all'

@self.descendants - Children + all descendants of the current page

Similar to .children, the .descendants collection will retrieve all the published children but continue to recurse through all their children:

 1content:
 2    items: '@self.descendants'

Page Collections

@page.page - Collection of just the specific page

This collection takes a slug route of a page as an argument and will return collection containing that page (if it is a published page):

 1content:
 2    items:
 3      '@page.page': '/blog'

An alias of '@page.self': '/blog' is also valid.

@page.parent - The parent page of a specific page

This is a special case collection because it will always return just the parent of the current page:

 1content:
 2    items:
 3      '@page.parent': '/blog'

@

@page.siblings - Siblings of a specific page

This collection will collect all the published pages at the same level of the page, excluding the page itself:

 1content:
 2    items:
 3        '@page.siblings': '/blog'

@page.children - Children of a specific page

This collection takes a slug route of a page as an argument and will return all the published children of that page:

 1content:
 2    items:
 3      '@page.children': '/blog'

An alias of '@page.pages': '/blog' is also valid. Using '@page': '/blog' is deprecated as its meaning can change in the future.

@page.modules - Modules of a specific page

This collection takes a slug route of a page as an argument and will return all the published modules of that page:

 1content:
 2    items:
 3      '@page.modules': '/blog'

Using alias of '@page.modular': '/blog' is deprecated.

@page.all - Children and modules of a specific page

This method retrieves only published children and modules of the specific page:

 1content:
 2    items:
 3      '@page.all': '/blog'

@page.descendants - Collection of children + all descendants of a specific page

This collection takes a slug route of a page as an argument and will return all the published children and all their descendants of that page:

 1content:
 2    items:
 3      '@page.descendants': '/blog'

Taxonomy Collections

 1content:
 2   items:
 3      '@taxonomy.tag': foo

Using the @taxonomy option, you can utilize Grav's powerful taxonomy functionality. This is where the taxonomy variable in the Site Configuration file comes into play. There must be a definition for the taxonomy defined in that configuration file for Grav to interpret a page reference to it as valid.

By setting @taxonomy.tag: foo, Grav will find all the published pages in the /user/pages folder that have themselves set tag: foo in their taxonomy variable:

 1content:
 2    items:
 3       '@taxonomy.tag': [foo, bar]

The content.items variable can take an array of taxonomies and it will gather up all pages that satisfy these rules. Published pages that have both foo and bar tags will be collected. The Taxonomy chapter will cover this concept in more detail.

If you have multiple variables in a single parent to set, you can do this using the inline method, but for simplicity, we recommend using the standard method. Here is an example:

 1content:
 2  items:
 3    '@taxonomy':
 4      category: [blog, featured]
 5      tag: [foo, bar]

Each level in the hierarchy adds two whitespaces before the variable. YAML will allow you to use as many spaces as you want here, but two is standard practice. In the above example, both the category and tag variables are set under @taxonomy.

Page collections will automatically be filtered by taxonomy when one has been set in the URL (e.g. /archive/category:news). This enables you to build a single blog archive template but filter the collection dynamically using the URL. If your page collection should ignore the taxonomy set in the URL use the flag url_taxonomy_filters:false to disable this feature.

Complex Collections

You can also provide multiple complex collection definitions and the resulting collection will be the sum of all the pages found from each of the collection definitions. For example:

 1content:
 2  items:
 3    - '@self.children'
 4    - '@taxonomy':
 5         category: [blog, featured]

Additionally, you can filter the collection by using filter: type: value. The type can be any of the following: published, visible, page, module, routable. These correspond to the Collection-specific methods, and you can use several to filter your collection. They are all either true or false. Additionally, there is type which takes a single template-name, types which takes an array of template-names, and access which takes an array of access-levels. For example:

 1content:
 2 items: '@self.siblings'
 3 filter:
 4   visible: true
 5   type: 'blog'
 6   access: ['site.login']

The type can also be negative: non-published, non-visible, non-page (=module), non-module (=page) and non-routable, but it preferred if you use the positive version with the value false.

 1content:
 2 items: '@self.children'
 3 filter:
 4   published: false

Ordering Options

 1content:
 2    order:
 3        by: date
 4        dir: desc
 5    limit: 5
 6    pagination: true

Ordering of sub-pages follows the same rules as ordering of folders, the available options are:

The content.order.dir variable controls which direction the ordering should be in. Valid values are either desc or asc.

 1content:
 2    order:
 3        by: default
 4        custom:
 5            - _showcase
 6            - _highlights
 7            - _callout
 8            - _features
 9    limit: 5
10    pagination: true

In the above configuration, you can see that content.order.custom is defining a custom manual ordering to ensure the page is constructed with the showcase first, highlights section second etc. Please note that if a page is not specified in the custom ordering list, then Grav falls back on the content.order.by for the unspecified pages.

If a page has a custom slug, you must use that slug in the content.order.custom list.

The content.pagination is a simple boolean flag to be used by plugins etc to know if pagination should be initialized for this collection. content.limit is the number of items displayed per-page when pagination is enabled.

Date Range

There is also an ability to filter pages by a date range:

 1content:
 2    items: '@self.children'
 3    dateRange:
 4        start: 1/1/2014
 5        end: 1/1/2015

You can use any string date format supported by strtotime() such as -6 weeks or last Monday as well as more traditional dates such as 01/23/2014 or 23 January 2014. The dateRange will filter out any pages that have a date outside the provided dateRange. Both start and end dates are optional, but at least one should be provided.

Multiple Collections

When you create a collection with content: items: in your YAML, you are defining a single collection based on several conditions. However, Grav does let you create an arbitrary set of collections per page, you just need to create another one:

 1content:
 2    items: '@self.children'
 3    order:
 4        by: date
 5        dir: desc
 6    limit: 10
 7    pagination: true
 8
 9fruit:
10    items:
11       '@taxonomy.tag': [fruit]

This sets up 2 collections for this page, the first uses the default content collection, but the second one defines a taxonomy-based collection called fruit. To access these two collections via Twig you can use the following syntax:

 1{% set default_collection = page.collection %}
 2{% set fruit_collection = page.collection('fruit') %}

Collection Object Methods

Iterable methods include:

Also has several useful Collection-specific methods:

Here is an example taken from the Learn2 theme's docs.html.twig that defines a collection based on taxonomy (and optionally tags if they exist) and uses the Collection::isFirst and Collection::isLast methods to conditionally add page navigation:

 1{% set tags = page.taxonomy.tag %}
 2{% if tags %}
 3    {% set progress = page.collection({'items':{'@taxonomy':{'category': 'docs', 'tag': tags}},'order': {'by': 'default', 'dir': 'asc'}}) %}
 4{% else %}
 5    {% set progress = page.collection({'items':{'@taxonomy':{'category': 'docs'}},'order': {'by': 'default', 'dir': 'asc'}}) %}
 6{% endif %}
 7
 8{% block navigation %}
 9        <div id="navigation">
10        {% if not progress.isFirst(page.path) %}
11            <a class="nav nav-prev" href="{{ progress.nextSibling(page.path).url|e }}"> <i class="fa fa-chevron-left"></i></a>
12        {% endif %}
13
14        {% if not progress.isLast(page.path) %}
15            <a class="nav nav-next" href="{{ progress.prevSibling(page.path).url|e }}"><i class="fa fa-chevron-right"></i></a>
16        {% endif %}
17        </div>
18{% endblock %}

nextSibling() is up the list and prevSibling() is down the list, this is how it works:

Assuming you have the pages:

 1Project A
 2Project B
 3Project C

You are on Project A, the previous page is Project B. If you are on Project B, the previous page is Project C and next is Project A

Programmatic Collections

You can take full control of collections directly from PHP in Grav plugins, themes, or even from Twig. This is a more hard-coded approach compared to defining them in your page frontmatter, but it also allows for more complex and flexible collections logic.

PHP Collections

You can perform advanced collection logic with PHP, for example:

 1$collection = new Collection($pages);
 2$collection->setParams(['taxonomies' => ['tag' => ['dog', 'cat']]])->dateRange('01/01/2016', '12/31/2016')->published()->ofType('blog-item')->order('date', 'desc');
 3
 4$titles = [];
 5
 6foreach ($collection as $page) {
 7    $titles[] = $page->title();
 8}

The order()-function can also, in addition to the by- and dir-parameters, take a manual- and sort_flags-parameter. These are documented above. You can also use the same evaluate() method that the frontmatter-based page collections make use of:

 1$page = Grav::instance()['page'];
 2$collection = $page->evaluate(['@page.children' => '/blog', '@taxonomy.tag' => 'photography']);
 3$ordered_collection = $collection->order('date', 'desc');

And another example of custom ordering would be:

 1$ordered_collection = $collection->order('header.price','asc',null,SORT_NUMERIC);

You can also do similar directly in Twig Templates:

 1{% set collection = page.evaluate([{'@page.children':'/blog', '@taxonomy.tag':'photography'}]) %}
 2{% set ordered_collection = collection.order('date','desc') %}

Advanced Collections

By default when you call page.collection() in the Twig of a page that has a collection defined in the header, Grav looks for a collection called content. This allows the ability to define multiple collections, but you can even take this a step further.

If you need to programmatically generate a collection, you can do so by calling page.collection() and passing in an array in the same format as the page header collection definition. For example:

 1{% set options = { items: {'@page.children': '/my/pages'}, 'limit': 5, 'order': {'by': 'date', 'dir': 'desc'}, 'pagination': true } %}
 2{% set my_collection = page.collection(options) %}
 3
 4<ul>
 5{% for p in my_collection %}
 6<li>{{ p.title|e }}</li>
 7{% endfor %}
 8</ul>

Generating menu for the whole site (you need to set menu property in the page's frontmatter):

 1---
 2title: Home
 3menu: Home
 4---

 1{% set options = { items: {'@root.descendants':''}, 'order': {'by': 'folder', 'dir': 'asc'}} %}
 2{% set my_collection = page.collection(options) %}
 3
 4{% for p in my_collection %}
 5{% if p.header.menu %}
 6   <ul>
 7   {% if page.slug == p.slug %}
 8       <li class="{{ p.slug|e }} active"><span>{{ p.menu|e }}</span></li>
 9   {% else %}
10       <li class="{{ p.slug|e }}"><a href="{{ p.url|e }}">{{ p.menu|e }}</a></li>
11   {% endif %}
12   </ul>
13{% endif %}
14{% endfor %}

Pagination with Advanced Collections

A common question we hear is regarding how to enable pagiation for custom collections. Pagination is a plugin that can be installed via GPM with the name pagination. Once installed it works "out-of-the-box" with page configured collections, but knows nothing about custom collections created in Twig. To make this process easier, pagination comes with it's own Twig function called paginate() that will provide the pagination functionality we need.

After we pass the collection and the limit to the paginate() function, we also need to pass the pagination information directly to the partials/pagination.html.twig template to render properly.

 1{% set options = { items: {'@root.descendants':''}, 'order': {'by': 'folder', 'dir': 'asc'}} %}
 2{% set my_collection = page.collection(options) %}
 3{% do paginate( my_collection, 5 ) %}
 4
 5{% for p in my_collection %}
 6    <ul>
 7        {% if page.slug == p.slug %}
 8            <li class="{{ p.slug|e }} active"><span>{{ p.menu|e }}</span></li>
 9        {% else %}
10            <li class="{{ p.slug|e }}"><a href="{{ p.url|e }}">{{ p.menu|e }}</a></li>
11        {% endif %}
12    </ul>
13{% endfor %}
14
15{% include 'partials/pagination.html.twig' with {'base_url':page.url, 'pagination':my_collection.params.pagination} %}

Custom Collection Handling with onCollectionProcessed() Event

There are times when the event options are just not enough. Times when you want to get a collection but then further manipulate the collection based on something very custom. Imagine if you will, a use case where you have what seems like a rather bog-standard blog listing, but your client wants to have fine grain control over what displays in the listing. They want to have a custom toggle on every blog item that lets them remove it from the listing, but still have it published and available via a direct link.

To make this happen, we can simply add a custom display_in_listing: false option in the page header for the item:

 1---
 2title: 'My Story'
 3date: '13:34 04/14/2020'
 4taxonomy:
 5    tag:
 6        - journal
 7display_in_listing: false
 8---
 9...

The problem is that there is no way to define or include this filter when defining a collection in the listing page. It probably is defined something like this:

 1---
 2menu: News
 3title: 'My Blog'
 4content:
 5    items:
 6        - s[email protected]
 7    order:
 8        by: date
 9        dir: desc
10    limit: 8
11    pagination: true
12    url_taxonomy_filters: true
13---
14...

So the collection is simply defined by the [email protected] directive to get all the published children of the current page. So what about those pages that have the display_in_listing: false set? We need to do some extra work on that collection before it is returned to ensure we remove any items that we don't want to see. To do this we can use the onCollectionProcessed() event in a custom plugin. We need to add the listener:

 1public static function getSubscribedEvents(): array
 2{
 3    return [
 4        ['autoload', 100000],
 5        'onPluginsInitialized' => ['onPluginsInitialized', 0],
 6        'onCollectionProcessed' => ['onCollectionProcessed', 10]
 7    ];
 8}

Then, we need to define the method and loop over the collection items, looking for any pages with that display_in_listing: field set, then remove it if it is false:

 1/**
 2 * Remove any page from collection with display_in_listing: false|0
 3 *
 4 * @param Event $event
 5 */
 6public function onCollectionProcessed(Event $event): void
 7{
 8    /** @var Collection $collection */
 9    $collection = $event['collection'];
10
11    foreach ($collection as $item) {
12        $display_in_listing = $item->header()->display_in_listing ?? true;
13        if ((bool) $display_in_listing === false) {
14            $collection->remove($item->path());
15        }
16    }
17
18}

Now your collection has the correct items, and all other plugins or Twig templates that rely on that collection will see this modified collection so things like pagination will work as expected.