Skip to main content

WordPress integration

Publish posts, manage pages, media, comments, users and taxonomies, and react to new content on your clients' WordPress sites.

What it does

The WordPress integration runs editorial and site-management automations on any client site you look after. You can publish or schedule posts and pages from a content calendar, upload images and set them as featured images, moderate comments, onboard users, keep categories and tags in order, and start a workflow whenever a post, comment, file, user, category or tag appears. Every call goes to the site's own REST API with a WordPress Application Password, so each client connection is separate and can be revoked from the client's WordPress admin at any time.

Connect a WordPress site

Add the connection from a WordPress step in the workflow editor: open the step's Connection field and choose Create connection. You need three things from the client's site.

  1. In the site's WordPress admin, open Users → Profile and scroll to Application Passwords.
  2. Enter a name you will recognize (for example TaskJuice) and choose Add New Application Password. WordPress shows a 24-character password once. Copy it before you leave the page.
  3. In TaskJuice, fill in:
    • Site URL, the full address including https:// and no trailing slash, for example https://blog.example.com.
    • WordPress username, the user the Application Password belongs to.
    • Application Password, the 24-character secret. The spaces WordPress shows are optional.

The connection can do what that WordPress user's role allows. Use an Administrator for user management and the New User trigger, or an Editor for content-only workflows. Application Passwords need WordPress 5.6 or later and a site served over HTTPS.

Triggers

Every WordPress trigger checks the site on a schedule, every 5 minutes by default. The first check records what already exists, so only records that appear after you turn the workflow on start it. Each run receives the new records as items; add a Loop step to handle them one by one.

Each trigger asks for the Site Host: the site's hostname with no https:// and no path, for example blog.example.com. It must be the same site as the connection.

  • New Post: a post is published, or first reaches the status you pick. Editing a post does not start it again.
  • New or Updated Post: a post is published or edited. An edit starts it again.
  • New Comment: a comment is posted. Pick Approved (the default) to only see comments readers can see, or Held for moderation to build a moderation queue.
  • New Media: a file is uploaded to the media library.
  • New User: a user account is created. Needs an Administrator connection.
  • New Category: a post category is created.
  • New Tag: a post tag is created.

Actions

Posts: List Posts (also finds a post by title or content), Get Post, Create Post, Update Post, Delete Post. Categories, tags and the author are picked from lists the site provides.

Pages: List Pages, Get Page, Create Page, Update Page, Delete Page.

Media: List Media, Get Media, Upload Media, Update Media (title, alt text, caption, description, attached post), Delete Media. Pass the id returned by Upload Media to a post's Featured image to set it.

Comments: List Comments, Get Comment, Create Comment (including replies), Update Comment (edit, approve, hold, mark as spam or trash), Delete Comment.

Users: List Users (also finds a user by name or email), Get User, Get Current User, Create User, Update User, Delete User.

Categories and tags: List, Get, Create, Update and Delete for each.

Site: List Taxonomies, Search Content (searches posts, pages and terms at once).

Delete Post, Delete Page and Delete Comment move the record to the WordPress trash unless you turn on Delete permanently. Media, users, categories and tags have no trash in WordPress, so deleting them is permanent. Delete User asks who should take over the user's posts.

Known limitations

  • WordPress core has no webhooks, so triggers check the site on a schedule instead of receiving instant notifications. Plugins that add webhooks are not used, because they cannot be relied on across client sites.
  • A trigger can only watch a site served from its own hostname over standard HTTPS. Sites installed in a subdirectory (example.com/blog) or on a non-standard port can use every action but cannot use triggers yet.
  • A trigger picks up at most 100 records per check (50 by default). If more than that arrive between two checks, the oldest are skipped. Shorten the check interval for very busy sites.
  • List actions return at most 100 records per page. Use Page to read further.
  • Users have no last-modified date in WordPress, so there is no Updated User trigger.
  • Some managed hosts strip the Authorization header before it reaches WordPress. If every step fails with 401 Unauthorized while the password is correct, ask the host to pass the header through to the REST API.
  • Revisions, autosaves, site settings, themes, plugins, menus, widgets, block templates and Application Password management are not included.
Was this helpful?