70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
## 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`
|