Skip to main content
WordPress is your own site rather than somebody’s network, so connecting it works differently from every other channel: there’s no Ocoya app to approve on a central service. You connect with an application password, which WordPress issues for exactly this and you can revoke at any time without changing your own password.

​
Before you start

Three things have to be true of the site:
  • It’s reachable over https. An application password can’t be sent safely over http, so Ocoya refuses http sites.
  • Its REST API is reachable. Some security plugins disable or block it.
  • The user you connect has the Author, Editor or Administrator role. Lower roles can’t publish.

​
Connect WordPress

There are two ways in. Both end in the same connection.
1

Open Channels and choose WordPress

Select Channels, then Connect channel, and pick WordPress — it’s listed under Blogging.
2

Enter your site address

Type the site’s address, such as https://example.com. Ocoya uses it to find the site’s REST API.
3

Approve on your own site, or paste a password

Ocoya can send you to your site’s Authorize application screen, where WordPress creates the password and hands it back. If you’d rather not be redirected, generate one yourself under Users → Profile → Application Passwords and paste it along with your username.
Revoking is done on your site: delete the application password under Users → Profile and Ocoya can no longer reach it. The connection is named Ocoya on that screen, so it’s clear which one to remove.

​
What you can post

Posts publish live, not as drafts on the site. No video. A WordPress site can host one, but at sizes and encodings that belong to your site’s own upload limit rather than to a scheduled post — so Ocoya refuses it rather than failing halfway through an upload.

​
The title

Every WordPress post carries a title, but you don’t have to type one. Leave the field empty and Ocoya takes the first line of your caption at publish time. That’s the difference from DEV.to, where the field is required in the composer: here nothing is ever rejected for the want of a title.

​
Images go into your media library

Images are uploaded into the site’s own media library rather than linked from Ocoya. Two consequences worth knowing:
  • The post keeps its images after you replace or delete the creative in Ocoya.
  • They appear in your library, where you’d expect to find them.
Images sit at the end of the body, not in the featured-image slot. That slot holds a single cover that your theme crops on its own terms — only one image would survive it, placed somewhere you didn’t choose. In the body, every image survives at its own proportions.

​
WordPress’s limits

WordPress stores the body in a text column and imposes no length of its own, so the body limit is Ocoya’s guard rail. The image count is ours too — your site’s real limit is its upload size, which only it knows.

​
Common problems

“WordPress sites must be connected over https.” The site address is http. An application password can’t be sent safely over it. “Your WordPress site did not return a REST API response. The REST API may be disabled or blocked by a security plugin.” Something on the site is blocking /wp-json. Security and firewall plugins are the usual cause. “This WordPress user is not allowed to publish posts. Connect a user with the Author, Editor or Administrator role.” The connected user’s role is too low. “WordPress posts require text.” The post has images but no body. “WordPress did not store the uploaded image.” The media upload was refused — usually the site’s own upload size limit, or a file type it doesn’t accept. “Connection to your profile has expired. Please reconnect.” The application password was revoked or changed. Generate a new one and reconnect. See Reconnect a channel.

Character and media limits

Every network’s limits side by side.

The post editor

Writing a different version per channel.