WordPress Publishing for RailCall

Website · Download v1.0.0 · Report an issue

Governed publishing for WordPress. An agency prepares a change, a human sees the exact diff on the exact post, approves it, and the site applies it — then the public page is checked for reachability and a content sample.

This repository ships the pair:

Who it is for

Content agencies and site teams whose writers or clients must approve a change before it is public — and who then need evidence of what went live. RailCall prepares; a human approves; the site refuses anything else.

Install

1. Download wordpress-publishing-for-railcall-1.0.0.zip from the release. In WordPress, open Plugins → Add New Plugin → Upload Plugin, upload the ZIP and activate WordPress Publishing for RailCall. Requires WordPress 6.5+ and PHP 7.4+.
2. Create an Application Password for the account RailCall should use (Users → Profile → Application Passwords). That account needs edit and publish rights; an Editor account is enough.
3. Open RailCall publishing → Overview. It says whether the site can publish right now; entries in the activity log are listed separately as history, because a failure from earlier does not stop the next approval.
4. Download railcall-wordpress-publishing-1.0.0.zip from the same release and extract its wordpress-publishing folder into ~/.railcall/station/modules/. The bundle is signed; preserve its files together. Start railcall studio, open Modules → Reload all, and confirm all ten commands load. If Station rejects the publisher, follow its trust policy rather than disabling signature checks.
5. In Studio → Integrations, configure the wordpress connection:

The release includes the plugin ZIP, the signed module ZIP and SHA256SUMS.txt. The GitHub source archive contains the code and tests. This project is published on GitHub; it is not a RailCall marketplace listing.

The module reads credentials from RailCall's vault instead of environment variables or bundled configuration. It does not include them in receipts.

On Station 1.5.34, numeric inputs use its number field type and boolean options use the strings "true" and "false". The handler validates post IDs and converts those options before calling WordPress. Station requires approval for credential-backed read commands too unless the operator allows those reads.

One working example

Review a draft title, then publish it:

wordpress.list_posts        → status: draft                → post_id 41
wordpress.preview_change    → post_id 41, title "Autumn launch (v2)"
                            → changes: 1 field (Title), review token rc_…
   …operator approves in RailCall…
wordpress.update_draft      → post_id 41, review_token rc_… , title as approved
                            → changed: true, state_after 9c1f… (was 4ab2…)
wordpress.preview_change    → post_id 41, action publish
wordpress.publish_post      → changed: true
                            → evidence.public_page: http 200, content found true
wordpress.verify_publication→ verdict: reachable_content_sample_found,
                              https://example.com/autumn-launch/

Edit that draft in WordPress between the preview and the approval and wordpress.update_draft is refused with rcpub_review_stale and a re-review instruction. Nothing is written.

What each write command does — and does not do

update_draft refuses a published or scheduled post, because its confirmation reads "nothing public changed until it is published" and that would be untrue. Changing what a live page shows is publish_post, where the diff the operator approved is the diff the site applies. Publishing a draft twice is safe: the same approval replays the first result, while a new approval for the same post is a new operation with its own idempotency key.

What the publication verdict means

The verdicts are evidence, not a guarantee. Report the URL and these findings, and open the page when the exact rendered version matters.

Known limitations

• The plugin must be active on the site; the module deliberately does not write through core WordPress endpoints, so the review state lives on the site.
• Application Passwords require HTTPS (or a local environment).
• Station 1.5.34's Reject button returned 404 during integration testing. Backend denial was verified through Station's POST endpoint. A successful click on that UI button has not been demonstrated; see REVIEW.md.
• WordPress publishes a scheduled post on the next request after its time (WP-Cron), so a quiet site can be a few minutes late.
• HTML is filtered with wp_kses_post unless the account may post unfiltered HTML; the preview says which filter will run.
• An empty string clears content or an excerpt, and an empty tag list removes every tag. An empty category list is refused: WordPress never leaves a post without a category, so it would silently reassign the site's default instead.
• Categories and tags are resolved before the post is written, so a term this site does not have stops the request with the post unchanged. Creating new terms also needs the site-level setting to allow it.
• Multisite: activate per site. Uninstalling removes the plugin's own tables and options and never touches posts.
• The RailCall module declares no egress sandbox block, because the site host is per-install. It only ever calls the single host in its vault credentials, and it says so in railcall-module/handlers/handler.py.

See TESTING.md for the reproducible test run (including tests/demo-sequence.py, which rehearses the plugin's review-token path and prints a transcript you can film — it is not a substitute for the Station run, which is where approval, denial and the signed receipt live), CHANGELOG.md for history, and readme.txt for the WordPress-style readme.

See REVIEW.md for the September 21 review, verified Station receipts, and integration limitations. Those receipts describe the development build tested on that date, not a marketplace certification of v1.0.0.

License

GPL-2.0-or-later.