Open Source Java 21 Toolkit

PowerWP4j: live CMS actions, offline content intelligence.

A source-backed case study in separating WordPress REST automation from repeatable cache analysis: typed payloads, metadata-aware sync, and taxonomy signals for audits or data pipelines.

View on GitHub Source code

Role

Founder-led engineering

REST facade, cache model, analyzer API

Type

Open-source toolkit

WordPress REST automation and analysis

Status

Alpha / 0.1.0

Useful today, evolving toward 1.0

Stack

Java 21

Maven, Jackson 3, Tika, SLF4J

Evidence

54 tests

Builders, cache analysis, query params

License

Apache 2.0

Independent WordPress ecosystem tooling

Problem

WordPress is a good CMS. It should not also be every report's runtime dependency.

The architectural split is the important part: live REST operations stay explicit, while reporting and taxonomy analysis move into deterministic local snapshots.

ContentWorkflow.java live + offline 
WPRestClient.of(siteInfo).createPost(payload);

WPCacheManager cache = new WPCacheManager(siteInfo, cachePath);
// overwriteCache: rebuild the local JSON snapshot
// ignoreSSLHandshakeException: keep TLS checks enabled
cache.fetchCacheFromInstancePath(true, false);
cache.cacheSync();

WPCacheAnalyzer analyzer = cache.getCacheAnalyzer();
long tags = analyzer.getTagCount();

Workflow

The toolkit keeps live operations and offline analysis connected, not tangled.

Each step can be reasoned about independently: credentials, REST payloads, cache construction, local analysis, and taxonomy extraction.

  1. 01 WPSiteInfo

    Configure site

    WPSiteInfo loads the WordPress domain, user, and application password from config resources or environment variables.

  2. 02 WPBasicPayloadBuilder

    Build payload

    Payload builders produce WordPress-shaped JSON with explicit statuses, post types, taxonomy IDs, and media metadata.

  3. 03 WPRestClient

    Run REST operation

    The facade handles posts, status changes, taxonomy creation, media upload, and post retrieval through Application Password auth.

  4. 04 WPCacheManager

    Fetch and sync cache

    Cache metadata tracks WordPress pagination totals so later syncs can fetch only the needed pages.

  5. 05 WPCacheAnalyzer

    Analyze offline

    The analyzer reads JSON snapshots for counts, slugs, links, GUIDs, rendered fields, categories, and tags without HTTP calls.

  6. 06 WPClassMapping

    Extract taxonomy signals

    Taxonomy helpers map labels to IDs, group markers by post, and calculate term frequencies for reports or ML pipelines.

Source Evidence

What the implementation makes visible.

These details show the engineering choices behind the toolkit: payload shape, cache metadata, internal parallelism, and analysis primitives.

Payloads

Builders serialize Java-friendly calls into WordPress-friendly JSON.

Source

builders/WPBasicPayloadBuilder.java

WPBasicPayloadBuilder.builder()
    .title("Test")
    .commentStatus(WPCommentStatus.OPEN)
    .status(WPStatus.PUBLISH)
    .build();

// test expectation
"comment_status": "open"

Takeaway

This is the kind of boring correctness that matters in integrations: callers write Java, WordPress receives the field names it expects.

Cache Metadata

The cache has a small metadata contract instead of guessing freshness from the JSON file alone.

Source

engine/WPCacheMeta.java

long wpTotal = Long.parseLong(
    headers.get("x-wp-total").getFirst()
);
long wpTotalPages = Long.parseLong(
    headers.get("x-wp-totalpages").getFirst()
);

LocalDate fetchedAtUtc =
    LocalDate.ofInstant(Instant.now(), ZoneOffset.UTC);

WPCacheMeta metadata =
    new WPCacheMeta(wpTotalPages, wpTotal, fetchedAtUtc);

Takeaway

PowerWP4j records what WordPress says about the dataset, which makes incremental cache decisions explainable.

Cache Fetching

Paginated cache work is parallelized without making the public API asynchronous.

Source

services/HttpRequestService.java

ExecutorService executor =
    Executors.newVirtualThreadPerTaskExecutor();

HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .executor(executor)
    .build();

Takeaway

The implementation uses Java 21 where it helps internally while keeping the user-facing workflow simple.

Taxonomy Analysis

The analyzer turns WordPress CSS-like class markers into structured reporting signals.

Source

engine/WPCacheAnalyzer.java

analyzer.mapWPClassId(
    tag -> tag.replaceFirst("^tag-", "")
        .replaceAll("[^a-zA-Z0-9]", " ")
        .trim(),
    TaxonomyMarker.TAG,
    TaxonomyValues.TAGS);

analyzer.groupPostIdsByClassMarker(
    TaxonomyMarker.TAG,
    TaxonomyValues.TAGS);

analyzer.calculateTermFrequencyByClassValue(
    TaxonomyValues.TAGS,
    new WPClassMapping<>("tag-veniam", 36L));

Takeaway

The deeper value is not only publishing automation; it is making messy content metadata usable for audits and downstream models.

Use Cases

Where PowerWP4j is useful after the first REST request works.

These scenarios connect the library mechanics to concrete workflows: publishing, cache-backed reporting, taxonomy analysis, and multi-site standardization.

Use case

Editorial automation

Problem

Draft creation, taxonomy assignment, status changes, and media updates become repetitive dashboard work.

How it helps

PowerWP4j expresses those actions as Java payloads and facade calls using Application Password auth.

Why it matters

Editorial operations can move into reviewable, repeatable automation without replacing WordPress.

Use case

Content audit and reporting

Problem

Audits should not hammer the live CMS or change depending on when the report runs.

How it helps

A fixed JSON cache gives WPCacheAnalyzer a local source for slugs, links, GUIDs, categories, tags, and rendered content snapshots.

Why it matters

Reports become reproducible and easy to version, share, or compare across time.

Use case

ML and data preparation

Problem

WordPress content and taxonomy fields need to become structured signals before they are useful to classifiers or recommenders.

How it helps

Taxonomy mapping, grouping, and frequency methods convert class markers and term IDs into explicit features.

Why it matters

The CMS becomes an inspectable data source instead of a live dependency in every experiment.

Use case

Multi-site operations

Problem

Multiple WordPress sites need consistent automation while each site may have custom post types or taxonomy conventions.

How it helps

Extension enums and config-driven site info let teams standardize workflows while preserving site-specific vocabulary.

Why it matters

Shared tooling can support several sites without hard-coding one site's structure into the library.

Boundaries

The project is intentionally scoped around automation and analysis.

PowerWP4j is most valuable when it respects WordPress as the CMS while giving Java teams repeatable primitives around content operations and local data.

Designed for

  • Java services that automate WordPress REST operations.
  • Offline content audits built from portable JSON snapshots.
  • Taxonomy and metadata analysis for reporting or ML preparation.
  • Projects that need extensible enum contracts for custom post and cache fields.

Not designed for

  • Replacing WordPress as the CMS or public rendering layer.
  • Covering every WordPress admin feature.
  • Automatic real-time synchronization.
  • Providing UI components, CLI tooling, or a general-purpose HTTP framework.

Status

Alpha 0.1.0: core ideas are usable, while method signatures and package boundaries may still change before 1.0.

Independence

PowerWP4j is an independent Apache 2.0 project by YGBStudio. It is not affiliated with or endorsed by WordPress.org.

If you like what you see

I'm always open to interesting work. Say hello.

Email me Browse GitHub

Independent software studio. Open source.