Data Ingestion

Collections

Retrieving content from REST API

Use collections when data should be available as Astro content entries at build/render time.

Source of truth is abcnorio-astro/site-dev/src/content.config.ts.

Creation checklist:

• Add a key in export const collections = { ... }.
• Pick loader by data class:
  • wpLoader for post/page-like entities that need block enrichment (blocks, sidebar_blocks).
  • wpSimpleLoader for taxonomy/list-only entities.
  • custom loader only when relation/query behavior is required. In this repo the query-specific loaders share the same internal block-sync path, but keep separate query semantics:
    • wpChildPagesLoader(parentSlug): generic child-page loader used by about_pages and programming_pages.
    • wpCollectiveSubpagesLoader(): taxonomy-driven page loader for pages tagged with collective-association terms.
• Keep ID contract explicit: entry id is derived from slug/id and is what route/path builders use.

Minimal retrieval example:

import { getCollection } from 'astro:content';

const tags = await getCollection('tags');
const featured = tags.filter((entry: any) => entry.data?.count > 0);

Retrieving content from BLOCK API

Collections and block data are related but not the same concern:

• Collections define which entities exist and how they are loaded.
• Block API enrichment adds blocks and sidebar_blocks for block-rendered routes.

Block flow in this repo:

• wpLoader calls block helpers (fetchPostBlocks, fetchSidebarBlocks) during collection load.
• Routes render those arrays through WpBlockRouter + block registry.

Requirements for block-rendered routes:

• Collection uses a loader path that writes blocks and sidebar_blocks.
• Route reads those arrays and passes block payloads to WpBlockRouter.

Do not use block loaders for taxonomy/list-only collections (tags, event_types, collective_associations).

Dev vs Production

Two runtime paths are normal and expected:

• Production/static path: use collection-backed data and in-memory filtering/pagination, this is very snappy.
• Dev/runtime path: use direct WP fetchers for live filtering/pagination requests, so we get up to data reflecting the latest cms changes.

Concrete pattern in this codebase:

• Events and articles listing partials resolve URL params, normalize IDs, then fetch runtime data.
• Static routes use collection data where practical for prerendered output.

Taxonomy archive wiring

Use events archive routes as the model.

Required pieces:

• Term route: e.g. /section/taxonomy/[term]
• Paged route: e.g. /section/taxonomy/[term]/[page]
• Path builder helper that:
  • loads term collection
  • fetches page 1 and remaining pages per term
  • returns termPaths and pagedPaths
• Detail/sidebar links that point to existing archive routes

In this repo:

• Events model:
  • src/pages/events/event-type/[term].astro
  • src/pages/events/event-type/[term]/[page].astro
  • src/lib/events/event-type-paths.js
• Articles tag archive (same pattern):
  • src/pages/articles/post-tag/[term].astro
  • src/pages/articles/post-tag/[term]/[page].astro
  • src/lib/articles/post-tag-paths.js

Minimal route wiring example:

import { getPostTagTermPaths } from '@lib/articles/post-tag-paths.js';

export async function getStaticPaths() {
  return getPostTagTermPaths();
}