How to get Blueprint list of pages to display in browser

I’ve got a Blueprint, for a parent page. With a list of child pages that use a certain template and are listed.

columns:
	block1:
		width: 1/2
		sections:
			section1:
				type: pages
				image: icon
				label: Weekly workshops
				template: workshop-weekly-template
				status: listed

I’m trying to connect my template to this list of pages. Based on code from here: Pages | Kirby CMS

<ul>
	<?php $jam =  $page->section1()->toPages(); foreach($jam as $moon): ?>
		<li>
			<a href="<?= $moon->url() ?>">
				<h2><?= $moon->title() ?></h2>
			</a>
		</li>
	<?php endforeach ?>
</ul>

But nothing is showing up in the browser

You can only fetch content from pages, not from sections.

The stuff in your sections are the child pages of either the current page (in your case) or of another page defined with the parent prop.

So, you need to fetch the children

$children = $page->children();

And since you have filtered them in your sections, you also want to filter them in your template:

$children = $page->children()->template('workshop-weekly-template');
1 Like

Thanks that works. But will this also pull into the template draft pages – do I also need to filter by listed? Or are draft pages not counted as child pages?

Thanks.

Still not sure why the code on this page doesn’t work.

Because that documentation refers to a pages field, not a pages section.

Urm, what’s the difference between a field and a section? Is there a comparison of the two things I can swot up on?

I’ve Googled and had a look around this forum. I can feel my brain crashing trying to understand the difference between a page field and a page section.

type: pages

looks the same to me, but somehow one type: page is a section and one type: pages is a field.

Am I right in thinking that if a type: pages is preceded by type: fields – it’s a page field. And if it isn’t it is a page section?

And that you can do different things with a type: page depending on whether it is a field or a section?

They look a little different, their properties are a little different and they do different stuff:

A field (except for some fields that only serve layout purposes like info, gap, line) saves something in the content file. A section does not.

A pages field and also a files field are basically SELECT/MULTISELECT fields, i.e. you select something out of a pool of options, which is then stored in the content file.

So, to oversimplify a bit:

fields => content
sections => organization/displaying stuff and additionally uploading/creating files/pages, deleting, sorting, publishing

Hey, that’s a great explanation. Thank you. I was wondering why some things get added to a pages content .txt file and some things don’t. I can kinda of start to vaguely understand it.

Is this correct?
If a type: pages is preceded by type: fields – it’s a page field. And if it isn’t it is a page section?

I wonder if Kirby has considered renaming pages fields and sections? Sections doesn’t seem very descriptive and is easy to confuse with sections used in Blueprints to divide the content up?

I guess that’s right.

In a Blueprint is there any other way of knowing if a

type: pages

is a field or a section?

So if my pages have a hero image, would I set this up in the Blueprint as a:

type: file (field)
or
type: file (section)

Or if both routes work, are there any advantages to one route?

A suggestion for future versions. To avoid confusion and make things simpler could there be two different “types”:

type: file_field
type: file_section
type: page_field
type: page_section

etc?

No, but while adding one or the other, why don’t you add a comment or name the field/section accordingly in your blueprint? Usually, it is clear from the context.

sections:
  files_section:
    type: files
    # props
  content_section:
    fields:
      files_field:
        type: files

If you have multiple files sections/files fields, they need to have different names, though.