Eleventy and private school
The term dates page a school site builds once and forgets
School sites on this generator are almost always assembled from data files: the term dates, the events, the staff list, the newsletters. A page then renders a filtered view of one of those files, usually whatever is coming up, and the filter runs during the build rather than when somebody reads the page. On a site that deploys twice a term, that page is a photograph of the calendar taken on the day of the last deploy, and the crawl takes a photograph of the photograph.
Why this pairing is its own job
The Eleventy install guide covers the tag, and the private school guide covers what the assistant has to know. What follows is the part that belongs to neither.
- A global data file holds the whole year. The page built from it commonly shows only what is upcoming, so most of the file never becomes text on any URL and is invisible to anything that reads pages.
- The filter is evaluated during the build. A school that deploys when there is news, which is not often, serves a page saying next up for months after the thing happened, and neither the page nor the material knows.
- Almost everything a parent asks about is dated: the deadline for entry at eleven, the assessment day, the open morning, the end of the summer term. This is the one trade whose entire enquiry pattern runs through the material most likely to have gone quietly stale.
- Layouts chain here and a school site accumulates one off pages, so the admissions page a newsletter links to is frequently the page that does not use the layout carrying the tag.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Eleventy guide. Everything below is about where it goes on a private school site specifically.
Put the tag at the top of the chain, then check the one off pages
Follow the layout key from a page upward until you reach the file holding the html and body elements, and put the tag there. Then open the pages a school builds separately, the entrance assessment page, the bursary page, the one somebody made for last year's appeal, and look at the corner of each.
Those are the pages traffic lands on. A parent arriving from a newsletter link arrives on exactly one of them, and if it declares its own layout in front matter it never reaches the file you edited.
A build is what publishes, so the calendar and the tag arrive together
The widget and the current state of every date filtered page come out of the same build. A site that has not been rebuilt since half term is serving an old calendar whether or not anybody edited the data file, and your tag will not be live until that build runs either.
If the site rebuilds only when somebody pushes a change, say so to whoever looks after the content, because the assistant answers from whatever the last build produced. A scheduled rebuild is worth considering on its own merits for any site whose pages filter by date.
Read the material again after a rebuild, not on a calendar of your own
The corpus is a copy of the built pages at the moment they were read. A rebuild that advances the term dates page changes the site and leaves the material alone, so the assistant carries on describing the term that finished.
Tie the re-index to the deploy that publishes a new calendar. It is the one maintenance habit this pairing genuinely needs, and it replaces any attempt to keep a separate document in step by hand.
Where the answerable material lives
| The whole calendar, which lives in a data file rather than on a page | Term starts and ends, inset days, half terms, open mornings, assessment days. The file holds the year and the page usually renders a slice of it, so most of the answers a parent wants were never text on any URL. Publishing the full year as a page is the highest value content change available on this pairing. |
|---|---|
| The admissions timeline, per entry point rather than as one merged list | Registration deadlines, assessment dates, offer dates and acceptance deadlines differ by entry year, and a page that blends them produces answers mixing entry at seven with the sixth form. Build one section per entry point, from the same data file if that is where the dates already are. |
| The fee schedule with the compulsory extras in the same document | Termly tuition, the deposits, and the charges nobody can opt out of: lunches, examination entries, the trip a whole year group goes on. A figure quoted without them is an incomplete price given in the school's name, and the assistant inherits exactly the completeness the indexed page had. |
| Files linked from pages, which a page crawl reads as links | The uniform list, the policy library and the joining pack are usually documents sitting in the assets folder with a link to them. What a crawl takes from that page is a file name. Where the answer to a parent's question is inside one of those files, upload the file rather than assuming the link carried its contents. |
The first thing to get right
Publish the full year of dates as a page instead of the next three entries, rebuild, and index that page.
It repairs the site and the corpus in one move, and it repairs them for the questions that make up most of a school's enquiry traffic. Everything else on this pairing is arrangement. This is the difference between an assistant that can tell a parent when the summer term ends and one that can only repeat what was coming up on the day somebody last deployed.
The failure that belongs to this combination
An assistant that is confidently three months behind the term
The events page says next up and names an open morning. That was true at the last build, the crawl read it then, and now both the page and the material describe a morning that happened in October. A parent is told about it in March, in the school's voice, with a link that appears to prove it.
Nothing went wrong with the crawl and nothing went wrong with the wording. A build time filter produced a sentence that was accurate for a day and has been served ever since, which is a property of the site rather than of anything done with it afterwards.
Test it by asking for the next open morning and the end of the current term. If the answer is behind, look at the date of the last build before looking at anything else, because on this stack a stale page and a stale corpus have one shared cause.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a private school visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Can it tell parents whether there is a place in a year group?
- Only if that is published and kept current, and on a site rebuilt when somebody has time it will not be. The safer material is how the waiting list works and who to contact, followed by taking the family's details for the registrar. Availability changes with a single withdrawal and no static page keeps up with that.
- The dates are in a data file. Can it read the file instead of the page?
- No. It reads published pages and documents you upload, and a data file in the repository is neither of those. Either render the whole file as a page, which is the better answer for parents as well, or export it and upload it as a document so the content exists somewhere it can be read from.
- How often should the material be read again?
- Whenever a build changes a page you answer from, which on a school site means at least at the start of each term and after any admissions change. There is no benefit in a schedule more frequent than your deploys, because between builds the site itself is not moving.
Keep reading
- Installing on EleventyThe tag belongs in the base layout under your includes directory, written as literal markup so template escaping cannot mangle it.
- Everything for a private schoolAdmissions timelines, fees, bursaries and uniform lists are safe ground for a school assistant. Anything about a named pupil or applicant is not.
- A school on Joomla, where access levels have already decided the scopePolicies filed under Registered access are invisible to a crawl, and menu item assignment is how you keep the launcher off the pupil area.
- Open mornings, member areas, and an install you cannot subtract fromPast open mornings stay published, the member area shows a launcher to parents while hiding its pages from a crawl, and injection can add but not subtract.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.