This document describes Action Scheduler’s store abstraction (ActionScheduler_Store) and how to select or extend stores.

Purpose of the Store Abstraction

Action Scheduler uses a data store layer to persist actions and provide a consistent query/claim interface. The abstraction lives in classes/abstracts/ActionScheduler_Store.php and is implemented by concrete stores:

• ActionScheduler_DBStore (custom tables, default in current versions)
• ActionScheduler_wpPostStore (legacy WP posts)
• ActionScheduler_HybridStore (migration bridge between two stores)

The store exposes a unified API for:

• saving actions
• fetching and querying actions
• managing claims
• updating statuses and timestamps
• cancellation and deletion

Store Selection

The store is chosen via the ActionScheduler_Store::instance() factory:

• Default class: ActionScheduler_wpPostStore
• Filter: action_scheduler_store_class

$class = apply_filters( 'action_scheduler_store_class', ActionScheduler_Store::DEFAULT_CLASS );

This is the primary integration point for custom store implementations.

Abstract Store API (Public Methods)

All concrete stores must implement (or inherit) the following public methods:

• save_action( ActionScheduler_Action $action, ?DateTime $scheduled_date = null )
• fetch_action( $action_id )
• find_action( $hook, $params = array() )
• query_actions( $query = array(), $query_type = 'select' )
• query_action( $query )
• action_counts()
• extra_action_counts()
• cancel_action( $action_id )
• delete_action( $action_id )
• get_date( $action_id )
• stake_claim( $max_actions = 10, ?DateTime $before_date = null, $hooks = array(), $group = '' )
• get_claim_count()
• release_claim( ActionScheduler_ActionClaim $claim )
• unclaim_action( $action_id )
• mark_failure( $action_id )
• log_execution( $action_id )
• mark_complete( $action_id )
• get_status( $action_id )
• get_claim_id( $action_id )
• find_actions_by_claim_id( $claim_id )
• cancel_actions_by_hook( $hook )
• cancel_actions_by_group( $group )
• get_status_labels()
• has_pending_actions_due()
• init()
• mark_migrated( $action_id )

Notes:

• find_action() and query_action() are convenience wrappers that call query_actions().
• extra_action_counts() adds a “past-due” count and is filterable.

Filters and Actions Used by Stores

Store Selection

• action_scheduler_store_class
  • Controls which class ActionScheduler_Store::instance() instantiates.

Counts

• action_scheduler_extra_action_counts
  • Filter to add extra counts to extra_action_counts().

Bulk Cancel

• action_scheduler_bulk_cancel_actions (action)
  • Fired after bulk cancellation in store logic.

Store Implementations at a Glance

ActionScheduler_DBStore

Custom tables implementation. See db-store.md.

ActionScheduler_wpPostStore

Legacy store that persists actions as a custom post type plus meta and taxonomy. See post-store.md.

ActionScheduler_HybridStore

Read-through migration store that moves actions from the legacy store to the custom-table store on demand. See hybrid-store.md.

Data Persistence Responsibilities

Stores are responsible for translating an ActionScheduler_Action to and from the underlying storage:

• Action identity: stored as a post ID (post store) or action_id (DB store)
• Hook: stored as post_title (post store) or hook column (DB store)
• Args: JSON stored in post_content (post store) or args / extended_args columns (DB store)
• Schedule: post meta _action_manager_schedule (post store) or serialized in schedule column (DB store)
• Group: taxonomy terms (post store) or actionscheduler_groups (DB store)
• Status: post_status mapping (post store) or status column (DB store)
• Claims: post_password (post store) or claim_id column + actionscheduler_claims table (DB store)

Related Logger Abstraction

Action logging uses a separate abstraction, ActionScheduler_Logger, with its own factory and filter. See logger.md.