Skip to content

Gamification 0.9.94 / Integrations

WordPress activity adapter

Turn selected WordPress lifecycle events into canonical Gamification events.

WordPress adapter

WordPress member-facing embeds are listed separately under Display → WordPress. Use the Cointacted Rewards block when editors should choose the view in the block sidebar, or copy a focused shortcode for balances, history, achievements, ranks, catalogs, quests, streaks, or a leaderboard. These ordinary WordPress embeds do not enable or depend on the SnapWeb or FluentCommunity native destinations.

The Pro WordPress adapter is disabled by default and works without SnapWeb, FluentCommunity, or another content plugin. Its advanced capture contract can select every current and future registered non-revision WordPress content type, status, and taxonomy context. The everyday Reward rule editor deliberately offers a smaller member-facing catalog: ordinary posts, comments, registration, and uploads. A type being public is not treated as proof that members create it; pages, products, orders, templates, and plugin records therefore do not appear by accident. Internal WordPress application records and taxonomy administration do not appear in that normal workflow. Addons can declare a confirmed front-end submission type with the cointacted_gamification_member_content_types filter.

Addons register non-WordPress member actions through cointacted_gamification_member_activities. The rule editor receives a label and a stable canonical key while the addon remains solely responsible for its official provider hooks and schema. This keeps provider code out of the core plugin and avoids frontend polling or provider-table scans.

Advanced configurable lifecycle facts include:

  • user registration;
  • content creation, first publication, update, status transition, trash, and permanent deletion;
  • comment submission, approval, update, trash, and permanent deletion;
  • media upload;
  • term creation, update, and deletion.

Publishing a guided Reward rule automatically enables its required listener and content scope, so an administrator does not have to duplicate the same choice under System. System → Activity sources shows health first and keeps the complete event/type/status/taxonomy allow-lists under Advanced capture controls.

The established wordpress.post.published event and its deterministic post:{id}:first-published identity remain compatible. Every content fact also emits a type-specific alias, such as wordpress.content.post.published, wordpress.content.page.updated, or wordpress.content.product.status.publish. Comments and terms likewise expose post-type/taxonomy aliases. These exact keys let rules, achievements, quests, and streaks target one CPT even where a feature does not have condition groups.

Rules may reward payload.author_user_id (the content author) or the event actor/editor. Conditions can inspect post type, current/previous status, parent, comment policy/type, and selected taxonomy term-ID arrays. Use contains for a specific category/tag/term ID.

Payloads contain only required IDs, registered type/status keys, MIME/taxonomy values, and lifecycle states. Titles, excerpts, bodies, term names/descriptions, emails, IP addresses, passwords, cookies, and authentication data are not copied. Repeated update/status facts reserve serialized per-object sequence numbers from authoritative post, comment, or term metadata while holding a bounded advisory lock; metadata caches are invalidated after reservation so parallel WordPress processes cannot reuse a stale sequence. First-create, publish, trash, and delete facts keep permanent stable identities. Disabling Pro or the adapter removes its listeners.

Scheduled posts use WordPress Core's normal publish_future_post cron callback. When Core changes a selected post from future to publish, the adapter emits the same compatible first-publication, typed-content, and exact-status facts as an interactive publication, with the post author preserved as the publication actor when no interactive editor exists. Repeated delivery of stable Core callbacks remains idempotent; repeatable update and status deliveries continue to receive serialized, contiguous per-object sequences.

Was this documentation helpful?Your response helps us improve this page.