The âone-pagerâ tutorial shows us how Kirby can be used to setup a single-page site, where the page has multiple sections.
All sites I do have more than one page - the site itself is usually divided into at least a âhomeâ page and a âblogâ, and then it often might have other features required by the client, like a product catalog, event calendar, or forum. I donât think Iâve ever done a single-page site, however in all my sites, I do need to have a âmulti-sectionâ page, exactly as described in the âone-pagerâ tutorial.
Iâm currently doing my first two sites in Kirby, and both are going to be essentially âone-pagerâ sites, with a blog. That is: the âhomeâ page will be divided into sections, layed out with sub-pages and snippets, and then there will also be a blog. Iâve managed to do the multi-sectioned homepage by slightly altering the instructions on the âone-pagerâ tutorial - in my version, the pages that represent the sections are subpages of âhomeâ, not at the top level of the site.
The whole process, however, made me feel as if âsectioned pagesâ like that are âsecond-class citizensâ in Kirby. The pages representing the different sub-sections of the parent are inserted as snippets in the parentâs template, and this has limitations - ie, snippets do not have their own controllers. Also, pagesâ URLs are by default made available by the router, so all page sections end up with their own URL. In order to avoid the user reaching these URLs, the developer has to either setup redirection manually in the âdefaultâ template for the site, or - if the default is already being used for another purpose - setup redirection in a template for each section page. It feels like a workaround.
Considering that multi-section pages are such a common use-case, perhaps setting them up could be made easier in the future, with a few alterations/additions to Kirby. For instance:
-
we create âsectionâ objects: they are basically page objects, but they DO NOT ROUTE - ie, they route to the error page, or another route specified by the developer in a special config. In the filesystem, sections might be indicated by a name starting with an underscore - so that, for instance, a directory called âcontactâ would indicate a page, but one called â_contactâ would indicate a section, and would not be accessible directly via http.
-
a âpageâ should then be able to have sections, sub-pages and files displayed in the panel.
-
sections can have their own templates, blueprints and controllers, perhaps stored in the siteâs templates/blueprints/controllers folder in a sub-directory with the same name as their parent pageâs.
-
the page object should be given a âsections()â method, to fetch a collection of the pageâs sections. The section object should be given a ârender()â method, that would run the sectionâs controller, then output the sectionâs template. This would enable us to do:
foreach($page->sections() as $section) {
$section->render($optionalData);
}
I havenât looked at the Kirby core code, so I cannot gauge whether this would be an incredible amount of work, or whether it would be realistic⌠but itâs worthwhile dreaming!