About the Kenii plugin and its modules

About the Kenii plugin and its modules

Kenii is delivered as a single WordPress plugin, simply named Kenii, even though it
provides several distinct capabilities. A college running it might use only the course
catalog, or it might also use career pathways and curriculum management. Those
capabilities are not separate plugins that have to be installed, updated, and kept
compatible with each other. They are modules inside one plugin, switched on or off
by the college’s license. This article explains why the product is built that way, how
the module system decides what is active, and which modules actually exist today.

The scope here is the architecture: what a module is, how the base-and-modules
relationship works, and how licensing gates it. It does not cover pricing or how to
purchase a module, and it is honest about the difference between what ships and what is
merely planned.

One plugin instead of many

The obvious alternative to a single plugin would be a family of plugins: a catalog
plugin, a pathways plugin, a curriculum plugin, each installed separately. That model is
common, and it has a real cost. Separate plugins drift apart in version, share code
awkwardly or duplicate it, and put the burden of keeping a compatible set on whoever
administers the site. When one plugin expects a newer version of another, the college
discovers the mismatch at the worst time.

Kenii avoids that by shipping everything in one plugin and treating the capabilities as
modules within it. There is one thing to install and one thing to update, and because
the modules live in the same codebase and are released together, they cannot fall out of
step with one another. Cohesion becomes a property of how the product is built rather
than something the administrator has to maintain. The trade is that a college downloads
the whole plugin even if it is licensed for only part of it, but the inactive parts stay
dormant, so the cost of carrying them is negligible.

Catalog is the required base

The modules are not peers. Catalog is the foundation, and it is marked in the code as
the required base of the platform. Everything else builds on the data Catalog owns: the
programs, credentials, courses, campuses, terms, and the taxonomies that organise them.
A pathways feature that maps careers to programs, or a curriculum feature that manages
proposals to change courses, has nothing to describe without the catalog data underneath
it.

This is why the other modules declare a dependency on Catalog rather than standing alone.
The dependency is not a suggestion; it is checked. A module is only treated as active if
its own license is present and the license for everything it depends on is present too. A
pathways license without a catalog license does not produce a half-working pathways
feature, it produces an inactive one, because the module system recognises that the
dependency is unmet. The reasoning is that a module running on absent data would fail in
confusing ways, and it is better to keep it cleanly off than to let it half-run.

How a module becomes active

Every module registers itself with a central registry when the plugin loads, declaring a
short key (such as catalog, pathways, or curriculum), a human label, and any modules
it depends on. The registry is what the rest of the plugin consults to ask “which modules
exist” and, separately, “which modules are active right now.”

The distinction between existing and being active is worth drawing out, because the plugin
treats the two differently on purpose. The data foundations of every registered module,
its post types and taxonomies, are registered whether or not the module is active. The
practical reason is that content should not vanish or become unregisterable just because a
license lapses; the shapes that hold the data stay defined. What an inactive module does
not get is the visible, working surface: its shortcodes, its REST endpoints, its front-end
assets, and its admin menu are only wired up when the module is active. So an inactive
module is quiet rather than broken. Its data structures still exist, but none of its
features are exposed.

Activation itself comes down to entitlement. The plugin determines the set of licensed
modules either from a value set directly in the site’s configuration (an override intended
for controlled environments) or from a cached license record obtained from Kenii’s
licensing service. That cached record carries the list of licensed modules and an
expiration, and it is honoured for a grace period past its expiry rather than cutting off
the moment a renewal is late. The design intent there is to fail forward: a temporary
lapse in reaching the licensing service, or a renewal that is a few days behind, should not
take a college’s live catalog down. If no valid entitlement is present at all, no modules
are active, and the plugin is effectively inert beyond its account surface.

What a locked module looks like

Because a module can be present in the code but not licensed, the plugin has to do
something sensible when a visitor encounters a feature the college is not entitled to. Kenii
does not show an error or a broken widget. A locked module’s front-end output is replaced
with a neutral placeholder stating that the content is temporarily unavailable. A signed-in
administrator additionally sees a short note identifying which module is inactive and
pointing to the account area, so the person who can fix it gets a useful hint while a
student sees only a calm, unremarkable message. The choice to keep the public-facing message
generic is deliberate: a licensing state is an internal matter, and a visitor should not be
shown the plumbing.

Which modules exist today

It is easy, with an architecture built for many modules, to talk as though many modules are
available. Only three are actually built and shipped: Catalog, Pathways, and
Curriculum. Catalog is the required base and the data layer. Pathways adds career
mapping and related student-facing tools on top of the catalog. Curriculum adds proposal and
review workflows for changing what the catalog contains. Each of Pathways and Curriculum
depends on Catalog, and neither functions without it.

The module system is designed to accommodate further capabilities, and internal planning
refers to more of them, but a capability that is planned is not a capability that ships. This
document describes what exists. A college can license Catalog on its own, or Catalog together
with Pathways, Curriculum, or both, and those are the real combinations available. Presenting
anything beyond that as available would misrepresent the product, which is the opposite of what
a catalog platform built around accurate records should do.

Related reading

• The roles and capabilities reference describes who
  can administer the plugin and its account area, which is where licensing is managed.
• The Catalog post types and taxonomies reference
  documents the data foundation that the other modules depend on.
• The Pathways reference and
  Curriculum reference describe the
  two modules that build on Catalog today.