New Starterkit: 3 improvements

I have some comments on the Kirby version 2.4.0 code.
To show everything in one example, I picked out the webpage de/ueber-uns of the Kirby Langkit, but most is the same with the Kirby Starterkit, if I use it with German language:

<!doctype html>
<html lang="de">

  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1.0" />

  <title>Kirby Sprachen-Kit | &Uuml;ber uns</title>
  <meta name="description" content="Dies ist Kirby's Sprachen-Kit.">

  <link rel="stylesheet" href="">

  <header class="header wrap wide" role="banner">
    <nav class="languages" role="navigation">
  <ul class="languages-menu">
        <li class="languages-item">
      <a href="" data-code="en">
        <li class="languages-item is-active">
      <a href="" data-code="de">


The first line “<!doctype html>” says, that the code is html5. This is fine, but the lines

  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1.0" />

are coded in xhtml (the lines end with “/>” instead of “>”).


My next look is on the line

  <title>Kirby Sprachen-Kit | &Uuml;ber uns</title>

namely the creation of “&Uuml;ber uns” in the snippets file site\snippets\header.php, which correctly is displayed as “Über uns”. It is coded as <?= $page->title()->html() ?>, which is fine.
I think the code of $field->html() ignores, that Kirby generates “short” html5. If I process $field->kirbytext()with the same field I get the short “Über uns”.
Please change the Kirby code of $field->html() to get “short” html5 output (no Html entities for German Umlauts etc., use UTF8 instead).


Look at

      <a href="" data-code="en">


      <a href="" data-code="de">

for “data-code”.
I think following the html5 recommendation this should be “hreflang”.

1 Like

Ad 1: The trailing slash is optional in HTML5, but I guess we might as well remove it.
Ad 2: I can’t reproduce this, maybe an issue with your server config?
Ad 3: data-code is a custom data attribute used for CSS content:

1 Like


I don’t think so, because there is no difference, if the webserver runs on Linux nor Windows, independent of the running PHP version.

I have invited Fabian, the creator of the new Starterkit, to the topic.

Hey @anon77445132,

it’s a shame that I — as the creator of the Starterkit — am late to this topic.

I took a look at your feedback:

On 1: Like @texnixe already said, the trailing slash is valid HTML5, but I removed it for consitency as Kirby omits it everywhere else.

On 2: It also happens on my test server. The HTML excape function used by the html() field methods internally uses the toolkit’s html::encode() option. As that function internally uses htmlentities(), which produces html entities for special characters. But I agree, that entities are unneccessary for every HTML character outside the ASCII charset. There are 2 possibilities: use htmlspecialchars() within the header snippet file instad of a field method or to change the field method in one of our next releases. I don’t know if there are characters which could cause trouble when htmlspecialchars is used to escape HTML or if there are any other drawbacks. Maybe one of you knows?

On 3: This was a left-over from a development version that displayed longform language names on desktop and short language codes on mobile. We removed that functionality, but forgot to delete the superflous code. Thanks for your hint.

I fixed 1 and 3 and pushed the changes to the repositories of starterkit and langkit.

1 Like

Thank you so much for your changes!

Ad 2: I don’t understand why $field->html() and $field->kirbytext() render differently for the same field content in relation to Html entities or UTF8 for German Umlauts.
This affects all Kirby installations with 2.4.0.

In fact, both functions are responsible for totally different things and the implementation of each one does not have very much in common with the other one. While kirbytext() keeps HTML tags and parses Kirbytags (and Markdown), while html() strips HTML tags and also encodes special characters. But as long as you don’t want to edit the HTML output by hand, this is more an aesthetical issue than a technical one. It will only become an issue, if you want to strip HTML tags from a string to use it in a non-HTML file format, where HTML entities are not supported.

1 Like

I would like to have an Kirby option to disable

That option would be “don’t use the html() method and helpers”. Kirby doesn’t do that on its own, only if you tell it to. :slight_smile:


Ad 1: The same I find at one time.


Sorry, totally forgot about plainkit. Thanks again! :wink:

1 Like

Thanks you all from your team for the updates yesterday.

what do you think of updating , which link was announced with

I just updated it! Thanks for the hint.

1 Like

What do you think of updating the homepage at

with a hardcopy from like

or a detail of that hardcopy?

Sorry, I’m old-fashioned…