Kirby CMS Bug Report: Template Field Stripped from Content Data

The CMS Questions
1

Is this the right place to ask for help?

Kirby CMS Bug Report: Template Field Stripped from Content Data

Summary

Critical Issue: The template field is completely removed from content data during Kirby’s content parsing process, rendering the custom template system non-functional.

Environment

  • Kirby Version: 4.8.0
  • PHP Version: 8.3.21
  • Server: Laravel Herd (local development)
  • Theme: Zero One theme
  • Plugins: zohner-arts custom plugin
  • Setup: Multi-language (en, de, it)

Expected Behavior

When a content file contains:

Title: About
----
Template: about
----
Status: listed
----
Text: Content here

The template field should be:

  1. Available in $page->content()->data()
  2. Accessible via $page->content()->get('template')
  3. Used for template resolution by Kirby core

Actual Behavior

  • Template field is completely missing from parsed content data
  • $page->content()->has('template') returns false
  • $page->content()->get('template') returns empty string
  • All pages default to ‘default’ template regardless of content file declarations
  • $page->intendedTemplate() returns ‘default’ instead of specified template

Reproduction Steps

  1. Create content file with explicit Template: [name] field
  2. Parse content using $page->content()->data()
  3. Observe that template field is missing from returned array
  4. Check $page->content()->has('template') - returns false
  5. Verify file contains template field with file_get_contents()

Diagnostic Evidence

Raw File Content

Title: About
----
Template: about
----
Status: listed
----
Text: About page content

Parsed Content Data

// $page->content()->data() returns:
[
    'title' => 'About',
    'status' => 'listed', 
    'text' => 'About page content',
    'uuid' => '[uuid-string]'
    // 'template' => MISSING!
]

Template Resolution Failure

$page->content()->get('template'); // Returns: ""
$page->content()->has('template'); // Returns: false
$page->intendedTemplate();         // Returns: "default"
$page->template();                 // Returns: "default"

Impact Assessment

Critical Severity - This bug breaks core Kirby functionality:

  1. Custom templates unusable - All pages fall back to default template
  2. Panel interface broken - Custom blueprints not loaded
  3. Plugin templates ignored - Registered templates never used
  4. Development workflow disrupted - Template system non-functional

Troubleshooting Attempted

Configuration Checks

  • :white_check_mark: Template files exist in correct locations
  • :white_check_mark: Blueprint files properly configured
  • :white_check_mark: Plugin registration verified
  • :white_check_mark: File permissions correct
  • :white_check_mark: No conflicting site templates

Technical Attempts

  • :cross_mark: Forcing template via hooks (page.render:before)
  • :cross_mark: Route-based template override
  • :cross_mark: Explicit blueprint declaration in content
  • :cross_mark: Multiple cache clears and server restarts
  • :cross_mark: Removing all conflicting files

Multi-language Verification

  • :white_check_mark: Template field present in ALL language files
  • :white_check_mark: Same issue occurs with languages disabled
  • :white_check_mark: Problem persists with single-language test

Potential Root Cause

The template field appears to be filtered out during content parsing, possibly due to:

  1. Reserved field name conflict in Kirby 4.8.0
  2. Theme/plugin interference with content loading
  3. Multi-language content processing bug
  4. Core regression in content field parsing

Workaround Status

No viable workaround found. Attempted solutions:

  • Custom field names (e.g., Pagetype: about)
  • Hook-based template forcing
  • Route-based template selection

All workarounds fail because the underlying content parsing system is affected.

Files for Investigation

  • /content/1_about/about.txt - Contains template field
  • /content/1_about/about.en.txt - Language-specific file
  • /site/config/config.php - Site configuration
  • /site/plugins/zero-one/ - Theme files
  • /site/plugins/zohner-arts/ - Custom plugin

Request for Support

This appears to be a core Kirby regression that requires investigation by the development team. The template field parsing mechanism seems fundamentally broken in this configuration.

Priority: Critical - Core functionality non-operational Urgency: High - Blocks all development progress

Additional Information Available

  • Complete diagnostic scripts and outputs
  • Full site configuration files
  • Step-by-step reproduction case
  • Plugin and theme file structures

Please let us know what additional information would be helpful for debugging this critical issue.

2

The template Kirby uses to render the page is determined by the content file name (e.g. about.txt), not a template field added in the content file.

No, it should not, as outlined above.

Unless that is some special implementation of the theme you are using, in which case you would need to ask the template developer for support.

Apart from that, I cannot reproduce the issue in a Kirby 4.8.0 Starterkit. A template field added in the content file is accessible via $page->content()->get('template').

The same applies to the page status, in the Kirby core, this is handled by a number (zero, sorting number or date) prepended to the page slug (folder name), not by a field status in content.

3

Just out of curiosity, are you used to systems that use front matter in the content files? Like maybe 11ty, something like that? Whilst kirby is flat file, it doesnt quite work like that. Whilst i dont know how Zero One is setup as its a paid theme, and ive not tried it. You dont need to set the template in the content files.

As @texnixe said…

On a side note, I dont believe setting the listed status in the content file is a thing. May I ask where you saw to do that? You can set the page listed/unlisted/draft status via the panel, rather in the in content files. As @texnixe said thats down to the prefix to the folder. You can either do the prefixes manually in the file system (there are Kirby devs out there actually dont use the panel) or you can set it with kirbys panel and let that handle it.

4

you can not use the names of methods and properties defined by kirby as names for content fields, like template, image, images, video, videos,…

see here for a full list

5

Well, you can, and then access them via the content field. We don’t really recommend it, though.

I think this issue is either a misunderstanding of how Kirby works, or something implemented in the theme (ping @mrfreedom, do you use such a custom implementation in your Zero One Theme?).

6

Hi Sonja, thanks for the ping. :slightly_smiling_face:

Hi @markusz, I see you let the AI play with Zero One. Please don’t do that. AI is not ready (and I doubt it will ever will be) for large scale projects. Use it only for small chunks of code, for understanding, suggestions and code review.

What you’ve got here are AI hallucinations. Nobody knows what it says there, and it doesn’t make any sense. :slightly_smiling_face:

I just updated Zero One to Kirby 4.8.0, and everything runs smoothly as usual, no issues whatsoever.

Please, if you have some issues, contact me through Zero One support

But use your own words, don’t let AI talk for you. It really doesn’t have a clue what it is talking about. :slightly_smiling_face:

7

Thank you all for your kind answers and your help! We could resolve it - I’ll be back later, at the moment we’re really swamped. Thanks again! Cheers!