WordPress publishing

Overview

WordPress publishing* describes how you use a connected WordPress site as a publishing target in Ottili LD3*. LD3 bundles approved drafts into content packages and delivers them across multiple channels – WordPress is the primary long-form channel* (posts and pages). From a verified, approved draft, LD3 generates the WordPress-specific rendition and transfers it through the WordPress REST API to the connected site.

The base publishing* (one-way LD3 → WordPress) is part of the Beta (BETA)* of Ottili LD3 and is usable. The extended WordPress integration* (media-library sync, taxonomy, user sync, bidirectional sync, AI-callable tools with approval routing) is rolling out in phases* and is currently available as a staged rollout (Private Beta / Early Access)* behind feature flags. Everything runs company-context-scoped: every connection and every delivery belongs to exactly one company (company_id) and is recorded through Ottili Core Audit*.

What WordPress publishing in LD3 does

• Channel, not hosting* — LD3 publishes *to* a WordPress site you connect; LD3 does not host the site itself (see distinction below).
• Platform-specific rendition* — the Platform Adapter Writer produces a WordPress rendition (title, body, excerpt, image, taxonomy) from the canonical package.
• Per-asset delivery status* — LD3 tracks the publish-target status per asset (queued → in_progress → published / failed).
• Attribution preserved* — source link and provenance stay visible on the published post.
• Auditable* — every external effect is validated and logged through Ottili Core Audit.

Connect WordPress as a channel

Connecting WordPress is a configuration* step:

1. Authorise the site* — set up the WordPress site as a channel in Ottili ONE (via LD3's connected channels).

2. Map content types* — assign the content types you want to send there.

3. Publish through the package flow* — LD3 routes the asset, tracks delivery, and records the result.

You can check whether a connection is active before routing packages; LD3 does not publish until the target channel is connected and authorised. This keeps external posting intentional.

Publish a package to WordPress

1. Select the content package* that carries the *approved* status.

2. Assign the channel* — route the package to the connected WordPress connection (routing to multiple channels is supported).

3. Confirm approval* — LD3 is draft- and approval-first: publication waits for human confirmation before going public.

4. Start the publishing job* — LD3 generates the WordPress rendition and transfers it through the REST API; delivery status is tracked per asset.

5. Track delivery status* — in the package you see per asset *queued*, *in progress*, *published* or *failed* including the failure cause where applicable.

The approval gates are held by Ottili Core*; the decision is noted on the package and recorded through Ottili Core Audit*.

Extended WordPress integration (staged rollout)

The extended WordPress integration extends basic publishing into a comprehensive, multi-tenant-aware WordPress platform. It covers:

• Media-library synchronization* — reconcile images and assets between LD3 and WordPress.
• Taxonomy management* — assign categories and tags at publish time.
• User synchronization* — reconcile authors and roles.
• Bidirectional sync* — reflect changes made on the WordPress site back.
• AI-callable tools with approval routing* — LD3 can trigger WordPress operations via AI, bound to approval gates.

The rollout happens in phases* and is guarded by feature flags*; a kill switch prevents unintended external effects while a flag is inactive. The rollout is currently classified as a staged rollout (Private Beta / Early Access)*; the base functionality (connection + one-way publishing) is part of the general LD3 Beta*.

Maturity status and availability

The base publishing carries the product status Beta (BETA)*; the extension follows a staged rollout. Individual capabilities are listed with their respective maturity status.

How Ottili ONE publicly labels maturity status is described in [Understand feature status labels](/docs/understand-feature-status-labels). Product lifecycle and availability stages are explained in [Product lifecycle and feature status](/docs/product-lifecycle-and-feature-status).

Distinction: WordPress Hosting vs. WordPress publishing

WordPress Hosting* is a standalone managed hosting module (product slug wordpress-hosting) of Ottili ONE. LD3 WordPress publishing*, by contrast, *publishes content* to a WordPress site you connect – it is not the same as the hosting product. Both can be combined sensibly (hosting provides the site, LD3 publishes to it), but they are independent product surfaces.

Company context and audit

WordPress publishing in LD3 is natively part of Ottili ONE:

• One login* (One Login)
• One company context* — every connection and every delivery belongs to exactly one company, company_id
• One audit trail* (Ottili Core Audit)
• One shared platform*

This means: a connection and a publishing job always run inside your company; every action is resolved to exactly one company and logged. The unified, company-scoped audit model is described in [Audit and accountability](/docs/audit-and-accountability).

Related articles

• [LD3 Content Automation](/docs/ld3-content) — the full content pipeline.
• [LD3 publishing channels](/docs/ld3-channels) — all supported destinations.
• [LD3 publishing levels](/docs/ld3-publishing-levels) — how auto-publish is governed.
• [LD3 content packages](/docs/ld3-content-packages) — what gets routed to channels.
• [LD3 approval gates](/docs/ld3-approvals) — the sign-off before publishing.
• [LD3 troubleshooting](/docs/ld3-troubleshooting) — common issues and fixes.