JOOservices WordPress Content Templates

This package provides DTO-backed content templates for generating WordPress post and page payloads with SDK-compatible Gutenberg markup.

It does not manage WordPress theme templates, block templates, template parts, the WordPress template hierarchy, authentication, HTTP transport, endpoints, or SDK internals.

Package name: jooservices/wordpress-content-templates

Namespace: JOOservices\WordPress\ContentTemplates

Install

composer require jooservices/wordpress-content-templates

jooservices/wordpress-sdk is a normal Composer dependency of this package. Do not install the SDK through a local path repository or local checkout override.

Why this package is separate from the SDK:

• jooservices/dto owns DTO hydration and normalization behavior.
• jooservices/wordpress-sdk owns WordPress REST API transport, auth, endpoint services, and Gutenberg block primitives.
• jooservices/wordpress-content-templates owns reusable content composition for post and page payloads.

Quick Start

use JOOservices\WordPress\ContentTemplates\Data\HowToContentTemplateData;
use JOOservices\WordPress\ContentTemplates\Templates\HowToContentTemplate;

$template = new HowToContentTemplate(
    HowToContentTemplateData::fromArray([
        'title' => 'How to Launch a Template Library',
        'introduction' => 'Use a short sequence to keep the rollout predictable.',
        'steps' => [
            [
                'number' => 1,
                'title' => 'Audit the current package',
                'instruction' => 'Start from the real repository state, not assumptions.',
                'tip' => 'Verify the source branch before you branch from it.',
            ],
        ],
        'materials' => ['Composer', 'Repository access'],
    ])
);

$payload = $template->toPostData();
$wordpress->posts()->create($payload);

DTO-backed template data objects inherit fromArray() and toArray() from jooservices/dto, while this package keeps content-template-specific validation rules close to each data class.

Optional publisher:

use JOOservices\WordPress\ContentTemplates\Publishing\ContentTemplatePublisher;

$publisher = new ContentTemplatePublisher($wordpress);
$post = $publisher->publish($template);

For page-style payloads such as landing pages, generate the payload with the template and publish through the SDK pages service or ContentTemplatePublisher::publishPage().

Templates

• ArticleContentTemplate for structured articles and explainers.
• ComparisonContentTemplate for side-by-side comparisons with trade-offs and recommendations.
• FaqContentTemplate for question-and-answer content.
• HowToContentTemplate for step-by-step tutorials.
• LandingPageContentTemplate for page-style hero and section layouts.
• ListicleContentTemplate for ranked or numbered articles.
• NewsArticleContentTemplate for newsroom-style summaries, key points, and sections.
• ProductReviewContentTemplate for review copy, ratings, pros, cons, verdicts, and metadata.
• StoryContentTemplate for serialized fiction, chapters, attribution, categories, tags, and optional media.
• ContentTemplateRegistry for application-owned template registration or loading all built-ins in one call.

GutenbergContentBuilder and PostPayloadBuilder are thin convenience wrappers over SDK-compatible payload and block generation. They do not reimplement SDK HTTP, auth, or service behavior.

Development

composer validate --strict
composer lint
composer lint:all
composer test
composer test:coverage
composer test:wordpress
composer security
composer check
composer quality
composer ci

Docker WordPress E2E

Run the full A-Z local workflow with Docker, WP-CLI, a temporary consumer install, SDK-backed publishing, WP-CLI verification, REST verification, and report generation:

composer test:wordpress

Requirements:

• Docker and Docker Compose
• PHP and Composer
• network access for Composer dependency resolution and composer audit

What the workflow does:

• runs the repository Composer validation commands
• starts WordPress and MariaDB with Docker Compose
• installs and configures WordPress with WP-CLI
• creates a temporary consumer project outside this package
• installs this package into that consumer through an isolated path repository for unreleased local code only
• publishes every supported template plus the builder surfaces against the live WordPress instance
• verifies created content with WP-CLI and authenticated REST reads
• writes reports to build/wordpress-test-report.md and build/wordpress-test-report.json

The script keeps Docker running so you can inspect created content manually. Use the printed cleanup command when you are finished.

Documentation starts in docs/README.md. Agent and contributor rules live in AGENTS.md, CONTRIBUTING.md, and ai/skills/README.md.