Run Native WordPress Actions

Learn how to choose and safely configure built-in WordPress workflow actions for content, users, comments, media, taxonomies, and plugins.

Dragwyb AI Agent Workflows includes built-in actions that let a workflow read or change common WordPress records. You can use these actions to look up a post, create content, update a user’s details, manage comments, organize media, assign categories, or check a plugin’s status—without writing a custom PHP function for each task.

These are predefined WordPress API operations; they do not execute arbitrary PHP. Each action has a specific job and its own input fields. Choose the action that matches the result you need, provide the correct record ID or other required values, and check the result before allowing the workflow to continue.

Screenshot to add: [Workflow editor WordPress action picker and action configuration]

Add a WordPress action to a workflow

  1. Open the workflow in the visual editor and open the node picker.
  2. Choose an action from the WordPress group. Read its description before selecting it; actions with similar names may return different information or change different records.
  3. Fill in required fields, such as a post ID, user ID, email address, post type, or status. Where supported, map values from the trigger or an earlier workflow step instead of typing a fixed value.
  4. Save the workflow and test it with a read-only action first. Then test create, update, delete, role, or plugin actions on a staging site or a non-critical record.
  5. Review the action result before using it in later steps. If an action fails, check its error message, required fields, target record, and the permissions of the WordPress user running the operation.

Choose the right action group

Use the focused guides for a point-by-point explanation of the available actions and their important inputs.

Other available WordPress actions

Tags, media, taxonomies, and terms

  • Create, Update, Delete, or Get Post Tag — create a tag, change its details, remove it, or look up existing tags.
  • Add Tags to Post / Remove Tags From Post — assign tags to a post or remove selected tags. The add action can keep existing tags when its Append option is enabled.
  • Add New Image To Media Library — import an image from a direct image URL. Use a real image URL and provide a clear title or alt text where appropriate.
  • Get Media (All / By Title / By Id) — find media items in the library. The all-items lookup is capped, so use a specific title or ID when you know which item you need.
  • Rename Media / Delete Media From Media Library — change an item’s title or remove it from the library. Confirm the media ID before deletion.
  • Get Taxonomy (All / Single), Register Taxonomy, Unregister Taxonomy — inspect registered taxonomies or register/remove a custom taxonomy. Registering a taxonomy requires a slug, name, and the post types it applies to.
  • Add Taxonomy to Post / Remove Taxonomy From Post — assign or remove terms from a post for a selected taxonomy. Confirm the post ID, taxonomy slug, and term names or IDs.
  • Get Term (All / Single / by Field / by Taxonomy), Create New Term, Update Term, Delete Term — find and manage terms such as categories, tags, or terms in a custom taxonomy. Specify the taxonomy when the action asks for it.
  • Create Category, Update Category, Delete Category, Add Category To Post, Get Category (All / Single) — manage standard WordPress post categories and assign category IDs to posts.

Plugin management

  • Check Plugin Activation Status — check whether an installed plugin is active. The Plugin File field expects a plugin file path such as akismet/akismet.php, not just the display name.
  • Activate Plugin — activate an installed, inactive plugin. Test this on a staging site first because plugin activation can change site behavior or cause compatibility problems.

Understand inputs and results

  • IDs identify exact records. A post ID, user ID, comment ID, or media ID tells the action which item to work with. Map the ID from a previous step when the workflow is handling a specific record.
  • Optional fields usually leave existing values alone. For update actions, only provide fields you intend to change. Check each action’s description and form because behavior can differ by action.
  • List actions may return a limited number of records. For example, post and user list actions are capped. Use a specific ID, email, title, or filter when you need one particular record.
  • Metadata is additional information stored with a record. Use the correct metadata key and avoid writing private or system-managed keys unless the action explicitly supports them. Post metadata reads require the relevant capability on the target post.
  • Check success before continuing. An action can fail because a field is missing, a record cannot be found, or the current WordPress user lacks permission. Inspect the result and handle failures deliberately.

Permissions and safe testing

Some actions check the current WordPress user’s capabilities, and the required permission can depend on the target post type, taxonomy, or record. Do not assume every action uses identical permission checks. Use the least access needed for the task and verify the selected record before making changes.

Deleting posts, comments, or media; changing user roles or capabilities; unregistering post types or taxonomies; and activating plugins can affect a live site. Start with read-only actions, test destructive steps on staging, and keep a human review step for high-impact operations.