Choose the publishing outcome
Start with the WordPress reader surface you need
Source-only improvement
Improve existing WordPress content without adding translated reader surfaces. Choose this when the source language is the result readers need.
Multilingual publishing
Create localized posts and pages as native WordPress content. Choose this when readers need connected language versions with checked localized URLs, internal links, and hreflang relationships.
A complete route to publication
Take one WordPress publishing job to a checked public result
01
Choose the reader surface
Decide whether to improve the existing source or create a localized version. This choice sets the publishing result before content work starts.
02
Map the content that exists
Build a complete Source Inventory and record explicit obligations for current and future content. The inventory shows what exists and what each result must cover.
03
Set one clear job boundary
Use one bounded source or translation job at a time with an authenticated compatible client. The proposal stays specific enough to compare with the current source and its obligations.
04
Create the complete page or translation
Produce a complete proposed WordPress page or translation from the current source, its obligations, and the content readers need to act on.
05
Have the exact result checked independently
Have someone independent check the exact proposal against the same current source and its coverage requirements. The writer or client that produced it does not approve it.
06
Publish only the approved result
Publish only a complete proposal that passed independent review. A multilingual result also needs its localized URL, internal-link, and hreflang relationships checked.
07
Check the page readers receive
Open the exact public page after publication and verify the reader surface there. A successful publish operation alone does not prove what readers receive.
08
See what still needs work
Use current workflow status to distinguish verified pages from sources and translations that remain unfinished. It shows the next publishing action instead of leaving the backlog to guesswork.
What remains in WordPress
Keep content, language relationships, and evidence together
01
Native WordPress content
Localized posts, pages, menus, terms, and media remain ordinary WordPress reader content. Workflow records their source relationships, localized routes, review evidence, and publication status without replacing WordPress as the content system.
02
Know what must be covered
The complete Source Inventory shows what exists, and explicit obligations define what current and future sources must cover. Publishers can decide what to improve or translate next from a visible coverage basis.
03
Catch changed sources
When the source changes, Workflow can identify translations and earlier work that no longer matches it. Correct stale content before it becomes the page readers rely on.
04
Keep localized paths connected
Localized URLs, internal links, and hreflang relationships are checked as part of the multilingual reader surface. Language versions stay connected instead of becoming isolated pages.
05
Prove the published result
Incomplete or unapproved content does not qualify for publication. After an approved result is published, verify the exact public surface to confirm what readers see.
06
Fit existing tools around WordPress
Editor, theme, SEO, and presentation integrations can extend the workflow around WordPress. They add connections while WordPress remains the content system.
Boundaries
Keep evidence strict and content native
Devenia Workflow controls the path to an approved public result. WordPress remains the place where reader content lives.
01
Keep factual changes tied to current evidence
For factual source improvements, Workflow can require an immutable copy of the factual source supplied to WordPress. Replacing that copy makes earlier approval stale until current facts are covered and independently reviewed.
02
Leave reader content in WordPress
Translated posts, pages, menus, terms, and media remain ordinary WordPress content after the plugin is removed. Removing the plugin removes Workflow services and plugin-owned workflow data, not those reader assets.
03
Use the client that fits your operation
No specific AI model or provider is required. Any authenticated AI or automation client can participate when it follows the published WordPress interface contracts.
04
Know what the Abilities API changes
The plugin remains active without the WordPress Abilities API, but its workflow interfaces are registered only when an installed provider supplies wp_register_ability().
Dependencies
Dependencies
WordPress provides the content and publication platform, PHP runs the plugin, and the WordPress Abilities API exposes the workflow interfaces.
6.9 or later
WordPress 6.9 or laterProvides native content, metadata, routing, taxonomy, REST, and publication services.
8.0 or later
PHP 8.0 or laterRuns Devenia Workflow on the server.
Installed provider required for workflow interfaces
WordPress Abilities APIProvides the registered interfaces used by authenticated workflow clients.
Stable package
Add controlled publishing to WordPress
Download the Stable self-hosted ZIP for Devenia Workflow to start with the source-only or multilingual publishing path that fits your readers.