3.0 KiB
Purpose
Provide a build-time content source backed by a WordPress site via the wp-json REST APIs.
ADDED Requirements
Requirement: WordPress API configuration
The system MUST allow configuring a WordPress content source using environment/config values:
- WordPress base URL
- credentials (username + password or application password) when required by the WordPress instance
The WordPress base URL MUST be used to construct requests to the WordPress wp-json REST APIs.
Scenario: Config provided
- WHEN WordPress configuration values are provided
- THEN the system can attempt to fetch WordPress content via
wp-json
Requirement: Fetch posts
The system MUST fetch the latest WordPress posts via wp-json and map them into an internal representation with:
- stable ID
- slug
- title
- excerpt/summary
- content HTML
- featured image URL when available
- publish date/time and last modified date/time
- category assignments (IDs and slugs when available)
Scenario: Posts fetched successfully
- WHEN the WordPress posts endpoint returns a non-empty list
- THEN the system stores the mapped post items in the content cache for rendering
Requirement: Fetch pages
The system MUST fetch WordPress pages via wp-json and map them into an internal representation with:
- stable ID
- slug
- title
- excerpt/summary when available
- content HTML
- featured image URL when available
- publish date/time and last modified date/time
Scenario: Pages fetched successfully
- WHEN the WordPress pages endpoint returns a non-empty list
- THEN the system stores the mapped page items in the content cache for rendering
Requirement: Fetch categories
The system MUST fetch WordPress categories via wp-json and store them for rendering a category-based secondary navigation under the blog section.
Scenario: Categories fetched successfully
- WHEN the WordPress categories endpoint returns a list of categories
- THEN the system stores categories (ID, slug, name) in the content cache for blog navigation
Requirement: Build-time caching
WordPress posts, pages, and categories MUST be written into the repo-local content cache used by the site build.
If the WordPress fetch fails, the system MUST NOT crash the entire build pipeline; it MUST either:
- keep the last-known-good cached WordPress content (if present), or
- store an empty WordPress dataset and allow the rest of the site to build.
When the cache layer is configured and reachable, the WordPress ingestion MUST cache wp-json responses (or normalized outputs) using a TTL so repeated ingestion runs avoid unnecessary network requests and parsing work.
Scenario: WordPress fetch fails
- WHEN a WordPress API request fails
- THEN the site build can still complete and the blog surface renders a graceful empty state
Scenario: Cache hit avoids wp-json refetch
- WHEN WordPress ingestion is executed within the configured cache TTL
- THEN it uses cached data instead of refetching from
wp-json