Plugins Reference

Plugins and integrations matter on addrbookview.uk because they shape how the shell behaves, how content is rendered, and how reusable site features are attached without rewriting the whole theme.

This page is a practical reference for how to think about extension points in this site, not a full upstream API mirror.

Quick Extension Reference

At a high level, a site extension usually affects one of these layers:

interface AddrbookviewSiteExtension {
  name: string;
  touches: {
    shell?: boolean;
    content?: boolean;
    navigation?: boolean;
    build?: boolean;
    verification?: boolean;
  };
  notes?: string[];
}

Use this mental model when deciding whether a change belongs in content, configuration, or an actual code-side integration.

name

type: string

Every extension should have a clear name that tells you what layer it affects. Prefer names that describe responsibility, not implementation vanity.

scope

type: site behavior boundary

A good extension should answer one question first: what does it change?

Typical scopes on addrbookview.uk are:

• shell presentation,
• content rendering,
• route-level behavior,
• build-time processing,
• or verification/readability support.

If a change only rewrites page copy, it is usually not a plugin problem.

content-facing helpers

type: rendering or authoring support

Some extensions exist only to make page authoring or display better, for example:

• richer embeds,
• reusable cards or tabs,
• search helpers,
• or content-aware rendering improvements.

These should support the reading experience without taking over the site’s meaning.

shell-facing helpers

type: navigation or UI support

Shell helpers are useful when they improve wayfinding, theme behavior, or reusable navigation patterns. They should reinforce the page-role model rather than distract from it.

build-facing helpers

type: compile-time support

Build-facing integrations should keep the static output stable and predictable. On addrbookview.uk, the priority is not plugin novelty; it is clean builds, readable output, and public verification.

verification-facing helpers

type: deployment confidence support

A useful site extension may also help verification indirectly, for example by making route behavior, search surfaces, or metadata more consistent. If an extension makes it harder to tell what changed after deploy, it is usually a bad fit.

Good plugin questions

Before adopting or keeping an extension, ask:

• Does it improve reading clarity?
• Does it preserve the template structure we are intentionally keeping?
• Does it reduce repeated manual work?
• Does it keep build and public output understandable?
• Would the site be harder to verify if this layer broke?

Common categories for addrbookview.uk

UI and content helpers

Examples include cards, grids, tabs, embeds, and search-facing enhancements that improve structured reading.

Navigation helpers

These help header, sidebar, breadcrumbs, or page scanning remain coherent as content grows.

Build integrations

These support static generation, indexing, syntax rendering, or performance-sensitive assets.

Optional external integrations

These should be judged carefully. If a tool adds operational complexity without helping the site read or verify better, it is probably unnecessary.

What not to treat as a plugin task

Not every change belongs in an extension layer. Usually these are not plugin problems:

• replacing template brand wording,
• rewriting page copy,
• changing rankings or briefs content,
• updating sidebar meaning,
• or fixing a route that should already exist in content.

Those belong in content or configuration first.

Practical evaluation checklist

When reviewing an extension idea for addrbookview.uk:

1. identify the layer it affects,
2. decide whether content/config alone already solves it,
3. check whether it keeps the template shell stable,
4. verify it will not confuse public-output checking,
5. keep it only if it makes the site easier to read or operate.

Minimal extension philosophy

addrbookview.uk should stay understandable. The more layers we add, the easier it becomes to lose track of whether a visible change came from content, config, or code.

That is why the preferred order is:

• content change first,
• config change second,
• plugin/integration change only when the first two are not enough.

Related pages

Use these pages together when evaluating site behavior:

• Configuration Reference
• Global Configuration
• Overview
• Homepage