Documentation Kenii Catalog How it works
About the catalog year lifecycle
Explains the four states a catalog year moves through and how the public year window works
About the catalog year lifecycle
A college catalog is not a single document that lives forever. It is a series of
yearly editions, each one a snapshot of what the college offered and promised
during a particular period. Kenii models that reality directly. Every program,
credential, course, policy, and term belongs to a catalog year, and each
catalog year moves through a small, predictable set of states over its life. This
article explains those states, how a year passes from one to the next, and why the
public side of your site only ever shows a bounded window of them.
The scope here is the lifecycle itself: the meaning of each state and the
transitions between them. It does not cover the versioned archive (the snapshot
system that preserves an exact copy of a year’s data), which is a separate and
optional mechanism, nor does it walk through the screens where you make these
changes. For those, see the related documents linked at the end.
Four states, one at a time
A catalog year sits in exactly one of four states: draft, active,
published, or offline. The names are deliberately plain, because each one
answers a plain question about who can see the year and who can change it.
A draft year is a workspace. It exists so that staff can build out next year’s
catalog (adding programs, revising credentials, adjusting courses) without any of
that work leaking onto the public site. Nothing in a draft year is visible to a
student, and everything in it remains fully editable. Most of a catalog year’s
useful working life happens here, quietly, before anyone outside the office sees
it.
The active year is the one the college is currently operating under. There is
normally one active year at a time, and Kenii treats it as the default edition:
when a visitor lands on your program listing or course directory without asking for
anything more specific, the active year is what they see. The active year is also
the one year that always remains open for edits, because the institution needs to
be able to correct and update the catalog it is living in.
A published year is a finished edition that is visible to the public but closed
to routine editing. Publishing is the act of saying “this edition is settled.” A
year typically becomes published when a newer year takes over as active: last
year’s catalog does not disappear, it simply moves into the published, read-only
state where it stands as an accurate record of what was in effect. Why published
years are locked rather than merely discouraged from editing is a question with an
accreditation and compliance answer, and it is treated on its own in
why published years are read-only.
An offline year is one that has been retired from public view. Its data still
exists in the system, but the programs, credentials, and courses tied to it are
switched out of the published state and into an internal, private status, so they
no longer appear in listings, detail pages, or search results. Offline is where old
editions go once they fall outside the window the public is meant to see.
Internally, the current state is recorded against the catalog year itself. When a
year has never been explicitly set, Kenii infers a sensible state (the configured
active year reads as active, a year flagged offline reads as offline, and anything
else reads as published), so a year always has a well-defined status even before
anyone touches it.
How a year moves through the states
The transitions follow the rhythm of an academic institution rather than an
arbitrary workflow. A year begins as a draft while it is being assembled. When the
institution adopts it, it becomes the active edition, and whatever was active before
settles into the published state. Over time, as more years accumulate, the oldest
published editions are taken offline so that the public catalog does not stretch back
indefinitely.
Two of these transitions are worth understanding in mechanical terms, because they
do more than flip a label. Taking a year offline does not just hide it; it walks
through every program, credential, and course attached to that year and moves each
one from the public “published” post status into a dedicated internal status that
is marked private and excluded from search. Bringing a year back online reverses
that exact operation, restoring those items to public visibility. This is why an
offline year is genuinely absent from the front end rather than simply de-emphasised:
the underlying content has been switched off, not just filtered out.
The active year holds a special place in this movement. Because it is both public
and editable, it is the one state where the two axes of the lifecycle (visibility
and editability) do not move together. Draft is private and open, offline is private
and closed, published is public and closed, and active is the deliberate exception:
public and open. Keeping that exception narrow, to a single year, is part of what
lets the rest of the model stay simple.
The public window
Left alone, the number of published years would grow by one every year, and a
catalog site would eventually offer a student a choice among a decade of editions.
Kenii avoids that with a public year window: a setting that caps how many
recent years the public can browse. The window defaults to five and cannot be set
below one.
The window works by counting from the most recent edition backward. The active
year and the newest published years fill the window; once a published year falls
past that count, Kenii takes it offline automatically. This enforcement runs
whenever the window setting changes and again on a daily schedule, so the public
catalog trims itself without anyone having to remember to retire old years by hand.
The reasoning behind a fixed window rather than an ever-growing archive is partly
practical (a shorter list is easier for a student to navigate) and partly
institutional: many states expect a specific number of recent catalog editions to
remain available, and a configurable window lets a college match whatever its own
requirement happens to be.
It is worth being clear about what the window does and does not touch. It governs
what the public can reach, by moving surplus published years offline. It does not
delete anything, and it does not affect draft years, which are invisible regardless
of the window because they were never public in the first place. An offline year
pushed out by the window is still in the system and can be brought back online if a
need arises.
One reasonable objection to an automatic window is that it can retire a year a
college would rather keep visible for a little longer, for example during a
transition when students on an older catalog still need to consult it. The window is
a single number applied uniformly, so the way to keep an edition public beyond the
default is to widen the window rather than to exempt one year. That trade, simplicity
of one setting against the flexibility of per-year exceptions, is a deliberate choice
in favor of a model that is easy to reason about.
How the public year connects to what a visitor sees
The lifecycle is not an abstraction sitting off to the side; it decides which
data a visitor actually receives. On listing pages, Kenii scopes the query to a
single display year. By default that is the active year, but a visitor can ask
for any other year that is currently public (active or published) and see the
catalog as it stood then. A year that is offline or draft is not a valid choice,
because it is not public, so the scoping quietly ignores requests for it. Detail
pages for an individual program or course are addressed directly and are not
year-scoped in the same way, since a specific record is being requested by name
rather than a list being filtered.
This is the payoff of the whole model. Because every catalog item carries its year
and every year carries its state, “show the 2024 catalog” and “show only the
editions we are allowed to publish” become straightforward filters rather than
manual curation. The states are what make the front end honest about which edition
a student is reading.
Related reading
- Why published years are read-only explains
the compliance reasoning behind locking a published edition, which is the
counterpart to the visibility story told here. - The settings reference documents the exact options
that back this behavior, including the active catalog year and the public year
window. - The post types and taxonomies reference
describes thecatalog_yeartaxonomy that ties every catalog item to its edition.