@geekity/cms 0.4.0 → 0.6.0

package/themes/default/README.md

@@ -21,13 +21,14 @@ themes/default/
     post-list.njk     the h-feed a listing is made of
     pagination.njk    previous/next pager
     tags.njk          macros for tag and category links
-    bio.njk           who an entry is by, as an h-card, with the site menu
+    bio.njk           who an entry is by, as an h-card
+    menu.njk          one named menu, as a nav of links
     feeds.njk         macros for the feed links in <head>
     conversation.njk  the replies, likes and boosts under a post
     comment-form.njk  the form under a post that is taking comments
     contact-form.njk  the form on a page whose front matter says contact: true
     archive.njk       every post by month, on a page that says archive: true
-    search-form.njk   the search box, in the footer and on the search page
+    search-form.njk   the search box, on the search page
   mail/
     test.*.njk              the Send test email message
     password-reset.*.njk    the forgot-password link
@@ -141,24 +142,36 @@ words above the posts; `layouts/home.njk` already does.
 skip link, one `.global-wrapper` at the 42rem measure, `.global-header`,
 `<main id="main">` and the footer, in that order.
 
-**The header has one rule.** On the front page it is the site title as
-`h1.main-heading`, linked home, with `site.tagline` in a paragraph under it; on
-every other page it is `a.header-link-home`, the site title small and linked
-home, and no tagline. The wrapper carries `data-is-root-path="true"` at `/` and
-nothing anywhere else, which is how the stylesheet tells the two apart. There is
-no navigation in the header — see [Navigation](#navigation).
+**One home for each kind of link.** The header carries the site menu, on every
+page. [The bio](#the-bio) carries the person whose page or post it is. The
+footer carries the site's own links. The search box is on the search page and
+nowhere else.
+
+**The header has one rule, and the menu under it.** On the front page it is the
+site title as `h1.main-heading`, linked home, with `site.tagline` in a
+paragraph under it; on every other page it is `a.header-link-home`, the site
+title small and linked home, and no tagline. The wrapper carries
+`data-is-root-path="true"` at `/` and nothing anywhere else, which is how the
+stylesheet tells the two apart. `menus.primary` is printed inside the
+`.global-header` on both: at the root it is a line of its own under the
+tagline, and everywhere else the stylesheet lays the header out as one line so
+it sits beside the link home. See [Navigation](#navigation).
 
 **The footer** prints the copyright with the current year and `site.author`,
-`Published with Geekity`, and then one `ul.hlist` holding an RSS link to
-`/feed/` and one `rel="me"` link per entry of `siteAuthor.links`. A site whose
-`author` setting names nobody with an account here gets the line and the RSS
-link and no identity links, because `siteAuthor` is absent. The year is
+`Published with Geekity`, and then `menus.footer` — the `footer` area this
+theme declares, and the whole of what the footer links. A site that wants its
+feed there types an `RSS | /feed/` line into it, the way the starter site does.
+Nothing in the footer is read off an account: it used to hold one `rel="me"`
+link per entry of `siteAuthor.links`, which was one nominated user's profile
+presented as the site's. An empty or missing footer menu prints no list at all,
+and the copyright line stands on its own. The year is
 `{{ "now" | date("year") }}` — `now` is the one word the `date` filter reads
 rather than parses — so it is the year at the moment the page is rendered, in
 the site's own timezone.
 
-Webrings, badges, a licence notice and anything else particular to one site are
-deliberately not in the package. They go in a site theme's `footer` block:
+Webrings, badges, a licence notice and anything else that is markup rather than
+a link are deliberately not in the package. They go in a site theme's `footer`
+block:
 
 ```njk
 {% extends "layouts/base.njk" %}
@@ -244,25 +257,31 @@ meta line, and this is the whole credit.
 `bioAuthor` is the one thing to set, and nothing renders when it is absent.
 It is one of the profile objects the context already carries: `author` on a
 post, falling back to `siteAuthor`; `siteAuthor` on a page; the archive's
-person on an author archive. `layouts/base.njk` reads it too — see
-[Navigation](#navigation).
+person on an author archive.
 
 What the bio prints: a round `u-photo` at 50px when they have an avatar,
 "Written by" and their name as a `p-name u-url` linked `rel="author me"` to
-their archive, then `p-job-title` and `p-locality` when the profile says. A
-name this site has no account for is printed unlinked, because the file still
-said somebody wrote this. Then the site menu.
+their archive, then `p-job-title` and `p-locality` when the profile says, then
+their `p-note` and their `rel="me"` links as a `ul.hlist.bio-links` — each
+link's `rel` is on it ready to print, `me` first and then whatever else the
+Links box typed. Each of
+those is printed only when the profile says it, so a profile holding a name
+alone prints a name alone. A name this site has no account for is printed
+unlinked, because the file still said somebody wrote this.
+
+**The person and only the person.** The site menu used to be printed here as
+well, because the design had no header navigation; it is in the header on
+every page now — see [Navigation](#navigation) — so the bio says nothing about
+the site. The note and the links used to be behind a `bioProfile` switch that
+an author archive set and an entry did not, on the grounds that the page
+footer already carried the site's identity links. It carries nobody's, so the
+switch is gone and the card is the same wherever it appears: at the top of
+somebody's archive, and under each of their posts.
 
 `bioLead` is what the line opens with, `Written by` unless a layout sets
 another; `layouts/author.njk` sets `Posts by`, because the card there heads
 somebody's writing rather than crediting one piece of it.
 
-Set `bioProfile` as well and it also prints their `p-note` and their `rel="me"`
-links; `layouts/author.njk` does, because that page is about the person rather
-than about something they wrote. An entry leaves it unset: the page footer
-already prints the site's identity links, and the `rel="author me"` link leads
-to the archive where this person's own are.
-
 **A site that used `partials/byline.njk`** — `{{ byline.line(author) }}` from
 an overridden layout — either includes this partial instead or writes the line
 itself. It was four lines of markup, and the object behind it has not changed:
@@ -363,17 +382,17 @@ saying how many documents matched, a `div.search-results` of
 indexed with `<meta name="robots" content="noindex">` in its `head` block.
 
 The context is a listing's with two differences. `query` is the words searched
-for, trimmed, and an empty string on the page before a search; it is defined
-only on this page, which is how `layouts/base.njk` knows to leave the footer's
-search box off it. Each entry in `posts` carries a `snippet`: a few words of
+for, trimmed, and an empty string on the page before a search. Each entry in
+`posts` carries a `snippet`: a few words of
 HTML around the match, escaped, with every matched word in `<mark>`. Print it
 with `safe`. The results are best match first rather than newest first, and
 only what the public site would serve is ever among them.
 
 `partials/search-form.njk` is a `GET` form to `/search/` with the words in `q`,
-so it needs no JavaScript and a search is a URL. `layouts/base.njk` puts it in
-the footer of every other page. The search page takes the path `/search/` ahead
-of any document permalinked there.
+so it needs no JavaScript and a search is a URL. This layout is the only thing
+that includes it: the box used to be in the footer of every page as well, and
+search is a menu item now — a `Search | /search/` line like any other. The
+search page takes the path `/search/` ahead of any document permalinked there.
 
 ### The front page
 
@@ -393,8 +412,8 @@ It draws the page's own words and then what the site has been writing:
 3. `p.front-links`, a line of links to where the writing is. The posts page is
    linked by its own title when the site names one, and the search always is
    (TASK-22).
-4. The bio, under a rule, exactly as an entry ends — so the site menu is there
-   too, because that is where this design keeps it.
+4. The bio, under a rule, exactly as an entry ends: whoever the site's author
+   setting names, with their note and their own links.
 
 Two context keys are the front page's alone. `recentPosts` is the entries to
 list, in the same shape a listing's are: the posts of the current month when
@@ -691,7 +710,7 @@ Every template gets:
 | Key          | What it holds                                                                                                                                                                                           |
 | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `site`       | `content/_data/site.json`, if the site has one, over the defaults `title` and `url`. Any key in the file is readable, so `site.tagline`, `site.author` and anything else a site adds are all available. |
-| `menu`       | The site menu for this page: a list of `{ label, url, current }`. See [Navigation](#navigation).                                                                                                        |
+| `menus`      | Every menu the site stores, by name, marked for this page: `menus.primary`, `menus.footer`, and any other name. See [Navigation](#navigation).                                                          |
 | `siteAuthor` | Who the page is by, as a profile. **Absent** when nobody matches. See [Bylines and author archives](#bylines-and-author-archives).                                                                      |
 | `icons`      | The site's icons, as `{ rel, sizes, href }`. Empty until the site has an avatar to derive them from. See [The head](#the-head).                                                                         |
 
@@ -774,17 +793,18 @@ the `partials/byline.njk` it used to have.
 
 `layouts/author.njk` is that person's archive, at `/author/{username}/`, with
 their pages at `/author/{username}/page/2/` and their three feeds under
-`/author/{username}/feed/`. It is headed with their name and then the bio with
-`bioProfile` set — the avatar, the note and the `rel="me"` links — and lists
-their published posts newest first. The source design has no author archive, so
+`/author/{username}/feed/`. It is headed with their name and then the bio —
+the avatar, the note and the `rel="me"` links, the same card that ends each of
+their posts — and lists their published posts newest first. The source design has no author archive, so
 the heading is the CMS's own; the h-card under it is the one partial the theme
 has. A user with no profile still has one; they are called by their username.
 
 `siteAuthor` is the same object on a different question: not who wrote this
-document, but who the page in front of the reader is by. It is what the bio,
-the footer's `rel="me"` links and any structured data a theme emits should all
-read, so that what a reader sees and what a machine reads cannot drift apart.
-It resolves in this order:
+document, but who the page in front of the reader is by. It is what the bio and
+any structured data a theme emits should both read, so that what a reader sees
+and what a machine reads cannot drift apart. The footer does not read it at
+all: the site's links are `menus.footer`, typed rather than borrowed from an
+account. It resolves in this order:
 
 - the document's own `author`, on a post or a page that names one;
 - the person whose archive it is, on an author archive;
@@ -795,8 +815,7 @@ It is **absent** when none of those name anybody this site has. The site
 setting is read more strictly than a byline is: a byline prints the name a file
 gives whether or not somebody answers to it, but a site author with no profile
 behind it has no picture, no bio and nowhere to link, so there is nothing to
-print and the key is not there. Write `{% if siteAuthor %}` around the bio and
-the identity links.
+print and the key is not there. Write `{% if siteAuthor %}` around the bio.
 
 The URL is not only a page. Each user is an ActivityPub actor at that address,
 so it is the page a follower lands on when they click through from the
@@ -806,50 +825,126 @@ it.
 
 ## Navigation
 
-`menu` is the site menu, already in order and already knowing which of its items
-is the page being looked at. Every template gets it.
+A site stores its menus by name in `content/_data/site.json`:
 
-The design has no header navigation: the menu is the horizontal list inside
-[the bio](#the-bio). So it is printed once, in one of two places. A page with a
-bio — an entry, an author archive — carries it there. A page without one — a
-listing, the 404, a layout of a site's own — gets it from the `footer` block of
-`layouts/base.njk`. What decides is `bioAuthor`: a layout that renders the bio
-sets it, and the footer then leaves the menu out. A layout that sets nothing
-keeps the footer menu, which is why an overridden `layouts/post.njk` does not
-lose the navigation by not having a bio.
+```json
+{
+  "menus": {
+    "primary": [
+      { "label": "Home", "url": "/" },
+      { "label": "About", "url": "/about/" }
+    ],
+    "footer": [
+      { "label": "Colophon", "url": "/colophon/" },
+      { "label": "Mastodon", "url": "https://example.social/@me", "rel": "me" }
+    ]
+  }
+}
+```
 
-The markup is the same either way, and a layout that overrides `header` or
-`footer` writes it the same way:
+Every template gets them as `menus`, keyed by the same names, already in order
+and already knowing which item is the page being looked at:
 
 ```njk
-{% if menu.length %}
-<nav class="site-nav" aria-label="Site">
-  <ul class="hlist">
-    {% for item in menu %}
-    <li><a href="{{ item.url | url }}"{% if item.current %} class="is-current" aria-current="page"{% endif %}>{{ item.label }}</a></li>
-    {% endfor %}
-  </ul>
-</nav>
-{% endif %}
+{% for item in menus.footer %}
+<a href="{{ item.url | url }}">{{ item.label }}</a>
+{% endfor %}
 ```
 
-Each item is `{ label, url, current }`. `url` is a site-root path or an absolute
-URL for somewhere else, so put it through the `url` filter as above and a site
-served from a subdirectory still links correctly. `current` is true for the item
-whose path is the one being rendered, comparing without the trailing slash; an
-item pointing off the site is never current.
+That is the whole interface, so a theme renders a menu this one has never heard
+of by looping over the name a site stored it under.
+
+### The areas a theme declares
+
+`theme.json` says where a theme renders a menu, so the Navigation screen can
+offer those places and nowhere else. This theme declares two:
+
+```json
+{
+  "name": "Default",
+  "kind": "site",
+  "areas": [
+    { "name": "primary", "label": "Site menu" },
+    { "name": "footer", "label": "Footer links" }
+  ]
+}
+```
+
+`name` is the key under `menus`, in `site.json` and on the context. `label` is
+what a person choosing an area reads; leave it out and it falls back to the
+name. Declare a third area and a site can fill it in; declare none and the
+theme renders no menu.
+
+The declaration is for the screen, not for the render. Every menu the site
+stores is on the context whether or not a theme declared an area for it — a
+menu nothing loops over is rendered nowhere and kept, which is what lets
+somebody write the menu a theme will use before switching to that theme. An
+`areas` that is missing, or that will not read, leaves the theme with none
+rather than failing to load it.
 
-The list is the `navigation` setting first, in the order the settings screen
-names it, and then every published page whose front matter says
-`navigation: true`, ordered by `navigationOrder` and then by title. A page that
-names no order sorts after every page that does.
+### One item
 
-It is called `menu` rather than `navigation` because `navigation` is the
-front-matter key a page opts in with, and a document's own front matter goes on
-top of the globals exactly as Eleventy's data cascade does. The setting is
-mirrored to `navigation` in `content/_data/site.json`, so an Eleventy build of
-the same content renders the same menu; `docs/eleventy.config.example.js` builds
-it as `collections.menu`.
+Each item is `{ label, url, current }`, plus `rel` on a link that carries `rel`
+values. `url` is a site-root path or an absolute URL for somewhere else, so put
+it through the `url` filter and a site served from a subdirectory still links
+correctly. `current` is true for the item whose path is the one being rendered,
+comparing without the trailing slash; an item pointing off the site is never
+current. `rel` is one string holding every value the line carried, already
+lower case and each said once — print it as the whole attribute,
+`rel="{{ item.rel }}"`, rather than building one of your own. `me` is the value
+most menus have, for the IndieWeb's identity check: Mastodon verifies a link on
+a profile by looking for a `rel="me"` link back, so a footer link to a profile
+marked `me` is what makes the tick appear.
+
+### Where this theme prints them
+
+`partials/menu.njk` holds the markup, as one macro:
+
+```njk
+{% import "partials/menu.njk" as nav %}
+{{ nav.list(menus.footer, "Footer") }}
+```
+
+The second argument is the `aria-label`, which is what tells a reader on a
+screen reader which of a page's menus this one is. Nothing is printed for a
+menu with nothing in it.
+
+`menus.primary` is printed once, in `header.global-header`, on every page
+(TASK-105). At the root, where the header is the site title with the tagline
+under it, the menu is a line of its own under the tagline; everywhere else,
+where the header is the small link home, the stylesheet lays the header out as
+one line and the menu sits beside it. Nothing decides between two places any
+more: a reader looks in the same spot whatever they are reading, and a layout
+that overrides the `content` block cannot lose the navigation by not printing
+a bio.
+
+`menus.footer` is printed in the `footer` block of `layouts/base.njk`, under
+the copyright line, and is the whole of what the footer links — a feed, a
+colophon, a webring, a profile marked `me`. The footer reads nothing off an
+account: it used to print one `rel="me"` link per entry of `siteAuthor.links`,
+which meant one nominated user's links stood for the site and nobody else's
+appeared at all.
+
+Every menu reads the same: a link in one is the colour, the underline and the
+size of a link in the page's prose, in the sans heading font a `nav` is set in
+(TASK-111). A menu is navigation somebody is meant to use rather than a
+footnote, so none of them is set smaller than the words around it, and the same
+goes for the `rel="me"` links `partials/bio.njk` prints under a post. The two
+links that read as plain text instead are the site title and
+`a.header-link-home`, which are the page saying where it is rather than
+somewhere to go, and the stylesheet names those two rather than reaching for
+every link that happens to sit in a `<header>`.
+
+`menus.primary` is the whole of the site menu, in the order the Navigation
+screen names it. Both areas are declared in this theme's `theme.json`, which is
+what puts them on `/admin/navigation` with those labels; a theme that renders a
+third menu declares a third area. A page cannot put itself in a menu; a page
+that should be linked — including the one a site serves as its front page,
+typed `Home | /` — is typed into the box there.
+
+Because the menus live in `site.json`, an Eleventy build of the same content
+renders the same ones; `docs/eleventy.config.example.js` builds them as
+`collections.menus`.
 
 ## Feeds
 
@@ -1084,7 +1179,7 @@ that has CSS for the WordPress theme can bring it.
 | Key                        | What it holds                                                                                                                                                             |
 | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `action`                   | Where the form posts. One fixed path; the post travels as a field.                                                                                                        |
-| `fields`                   | The name each field is submitted under: `post`, `name`, `email`, `url`, `body`, `inReplyTo`, `trap`, `loaded`, `notify`. Use these rather than typing the names.          |
+| `fields`                   | The name each field is submitted under: `post`, `name`, `email`, `url`, `body`, `inReplyTo`, `trap`, `loaded`, `notify`, `csrf`. Use these rather than typing the names.  |
 | `post`                     | The post's slug, for the hidden field.                                                                                                                                    |
 | `loaded`                   | When this form was rendered, in epoch milliseconds, for the hidden field. A submission that comes back too fast is refused.                                               |
 | `values`                   | What is in the fields: empty on a fresh form, what was typed on a refused one.                                                                                            |
@@ -1098,6 +1193,46 @@ technology, and give it `tabindex="-1"` and `autocomplete="off"`. A submission
 that filled it is dropped. **Do not** remove it from a replacement partial —
 it is one of three things standing between the site and a spam queue.
 
+### When somebody is signed in
+
+Two more keys are on `commentForm` when — and only when — the request carries a
+valid session for this site's admin:
+
+| Key          | What it holds                                                                                                                       |
+| ------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
+| `signedInAs` | Who the comment will be posted as: `name`, which is their display name or their username, and `url`, which is their author archive. |
+| `csrfToken`  | The value for a hidden `fields.csrf`, without which the submission is refused.                                                      |
+
+**A replacement partial has to draw both forms**, because the site draws this
+one for its own author and the stranger's one for everybody else:
+
+```njk
+{% if commentForm.signedInAs %}
+<input type="hidden" name="{{ commentForm.fields.csrf }}" value="{{ commentForm.csrfToken }}" />
+<p class="comment-signed-in">
+  Commenting as <a href="{{ commentForm.signedInAs.url }}">{{ commentForm.signedInAs.name }}</a>.
+</p>
+{% else %}
+{# fields.loaded, fields.trap, and the name, email and website boxes #}
+{% endif %}
+```
+
+The signed-in branch renders **no** name, email or website box, **no**
+`fields.trap` and **no** `fields.loaded`: the site already knows all three
+answers, and a session is better evidence that this is a person than a honeypot
+or a stopwatch. It renders `fields.csrf` instead, because this is the one form
+on the public site that acts on somebody's behalf — without the token, a page
+on another site could make them post under their own name. The comment box, the
+reply-to field and the notify box are the same in both branches.
+
+The account's email address is **never** on the context. The comment is stored
+with it, exactly as a stranger's is, and it is no more printable than theirs.
+
+A page carrying this form is one reader's page rather than the post, so the CMS
+answers it `Cache-Control: private, no-store` and with no ETag. A theme does
+not have to do anything about that, but it is why printing somebody's name into
+a page is safe here.
+
 Two more keys travel beside it, both from the URL rather than from the post:
 
 | Key                                   | What it holds                                                                                                                   |

package/themes/default/layouts/author.njk

@@ -9,14 +9,13 @@
 
   The source design has no author archive, so there is nothing to port: the
   heading is the CMS's own. What it does not keep is an h-card of its own.
-  `partials/bio.njk` is the one the theme has, and `bioProfile` asks it for the
-  whole profile — the note and the `rel="me"` links — because this page is
-  about that person rather than about something they wrote.
+  `partials/bio.njk` is the one the theme has, and it prints the whole profile
+  — the note and the `rel="me"` links — wherever it is, so this page is headed
+  with the same card that ends each of their posts.
 #}
 {% extends "layouts/base.njk" %}
 
 {% set bioAuthor = author %}
-{% set bioProfile = true %}
 {% set bioLead = "Posts by" %}
 
 {% block title %}{{ author.name }}{% if pagination.pageNumber > 0 %}, page {{ pagination.pageNumber + 1 }}{% endif %} · {{ site.title }}{% endblock %}

package/themes/default/layouts/base.njk

@@ -3,25 +3,26 @@
 
   The shell of the andrewshell.org design (decision-16): one wrapper at the
   measure, a big site title and tagline on the front page and a small link home
-  everywhere else, and a footer holding the copyright, the colophon, the feed
-  and whoever the site is by. There is no navigation in the header — the site
-  menu belongs with the bio under an entry — and `data-is-root-path` on the
-  wrapper is how the stylesheet tells the front page from every other one.
+  everywhere else, and a footer holding the copyright, the colophon and the
+  site's own links. `data-is-root-path` on the wrapper is how the stylesheet
+  tells the front page from every other one.
+
+  One home for each kind of link (TASK-105). The header carries the site menu,
+  on every page. `partials/bio.njk` carries the person whose page or post it
+  is. The footer carries `menus.footer`, the site's own list, and nothing read
+  off an account. The search form is on the search page and nowhere else.
 
   Blocks a site can override without copying the whole file:
     title       the contents of <title>
     head        the cards, the icons and the structured data, at the end of
                 <head>. Call `super()` from an override that only adds to it.
     alternates  <link rel="alternate"> tags, where the feeds go
-    header      the site header
+    header      the site header, with the site menu
     content     the page body
-    footer      the site footer, with the search box
+    footer      the site footer
     scripts     scripts at the end of <body>
-
-  One variable crosses between a layout and this file: `bioAuthor`, whoever an
-  entry's bio credits. A layout that prints `partials/bio.njk` sets it, and the
-  footer here leaves the site menu out because the bio is carrying it.
 #}{% import "partials/feeds.njk" as feeds %}
+{%- import "partials/menu.njk" as nav %}
 {#- Whether this is the front page, which is the one page the header and the
     stylesheet treat differently. `page.url` is the URL being served rather
     than the document's own permalink, so a static homepage under the Reading
@@ -107,6 +108,16 @@
     <a class="screen-reader-text" href="#main">Skip to content</a>
     <div class="global-wrapper"{% if atRoot %} data-is-root-path="true"{% endif %}>
       {% block header %}
+      {#
+        The header, and the site menu inside it on every page (TASK-105): one
+        place a reader looks for the navigation, whatever they are reading.
+
+        The header is two shapes and the menu sits differently in each. At the
+        root it is the site title and the tagline, and the menu is a line of
+        its own under them; everywhere else it is the small link home, and the
+        menu is beside it on that line. The stylesheet does the beside part,
+        off `data-is-root-path` on the wrapper.
+      #}
       <header class="global-header">
         {% if atRoot %}
         <h1 class="main-heading">
@@ -118,6 +129,7 @@
         {% else %}
         <a class="header-link-home" href="{{ "/" | url }}">{{ site.title }}</a>
         {% endif %}
+        {{ nav.list(menus.primary, "Site") }}
       </header>
       {% endblock %}
 
@@ -129,47 +141,24 @@
       <footer>
         <p>&copy; {{ "now" | date("year") }}{% if site.author %}, {{ site.author }}{% endif %} &middot; Published with Geekity</p>
         {#
-          The feed and whoever the site is by, as one horizontal list. The links
-          come from the site author's profile (decision-16), so what a reader
-          sees and what a consumer of `rel="me"` reads are the same list, and a
-          site whose author setting names nobody with an account here simply has
-          none. Webrings, badges and anything else particular to one site are
-          deliberately not here: they go in a site theme's `footer` override.
-        #}
-        <ul class="hlist">
-          <li><a href="{{ "/feed/" | url }}">RSS</a></li>
-          {% if siteAuthor.links %}
-          {% for link in siteAuthor.links %}
-          <li><a rel="me" href="{{ link.href }}">{{ link.label }}</a></li>
-          {% endfor %}
-          {% endif %}
-        </ul>
-        {#
-          The site menu, on a page that has no bio to carry it.
+          The footer menu: the `footer` area this theme declares in its
+          `theme.json`, which a site fills in on the Navigation screen, and the
+          whole of what the footer links (TASK-105). It is the site's own list
+          — the feed, a colophon, a webring, a Mastodon link it wants verified
+          — rather than anything read off an account: one nominated user's
+          profile links presented as the site's were nobody's to give, and on a
+          site with more than one person nobody else's appeared at all. An item
+          marked `me` carries `rel="me"`, which is what a site moving a
+          verified profile link in here needs.
 
-          The design has no header navigation: the menu is the horizontal list
-          inside the bio (TASK-83), which an entry and an author archive print
-          and a listing, a 404 or a layout of a site's own does not. So a
-          layout that renders a bio sets `bioAuthor`, and this prints the menu
-          only where nothing else did — the menu is on every page, once.
-        #}
-        {#
-          The search box, on every page but the one that already has it at the
-          top: `query` is on the context of the search page alone, empty or
-          not, so its being defined is what says this is that page.
+          Nothing is printed until a site has filled the area in: an empty
+          footer menu is no list rather than an empty one, and the copyright
+          line above stands on its own.
+
+          Webrings, badges and anything else that is markup rather than a link
+          go in a site theme's `footer` override.
         #}
-        {% if query is not defined %}
-        {% include "partials/search-form.njk" %}
-        {% endif %}
-        {% if menu.length and not bioAuthor %}
-        <nav class="site-nav" aria-label="Site">
-          <ul class="hlist">
-            {% for item in menu %}
-            <li><a href="{{ item.url | url }}"{% if item.current %} class="is-current" aria-current="page"{% endif %}>{{ item.label }}</a></li>
-            {% endfor %}
-          </ul>
-        </nav>
-        {% endif %}
+        {{ nav.list(menus.footer, "Footer") }}
       </footer>
       {% endblock %}
     </div>

package/themes/default/layouts/front-page.njk

@@ -15,8 +15,7 @@
 #}
 {% extends "layouts/base.njk" %}
 
-{#- Who the bio credits, and what tells `layouts/base.njk` the site menu is in
-    the bio rather than in the page footer. -#}
+{#- Who the bio credits: the person the site's author setting names. -#}
 {% set bioAuthor = siteAuthor %}
 
 {% block content %}