## 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`