Skip to content
Docs

Architecture

An overview of how BuddyPress Moderation Pro is put together, for developers extending or debugging it.

Bootstrap

Section titled “Bootstrap”

buddypress-moderation-pro.php defines the plugin constants (BMPRO_PLUGIN_VERSION, BMPRO_PLUGIN_PATH, BMPRO_PLUGIN_URL, BMPRO_TEMPLATES) and boots on bp_include, so it only loads when BuddyPress is present. If BuddyPress is missing the plugin deactivates itself and shows an admin notice. Licensing is handled by the bundled EDD license client.

The core class Buddypress_Moderation_Pro wires everything through a loader (Buddypress_Moderation_Pro_Loader) that registers the admin and public hooks. Activation and upgrades run through Buddypress_Moderation_Pro_Activator and Buddypress_Moderation_Pro_Upgrader.

Layers

Section titled “Layers”
  • admin/ - Settings screens, the reported-content and avatar list tables, meta boxes, and the settings tab partials in admin/inc/.
  • public/ - One class per moderated component (activity, comments, members, groups, messages, avatars, topics, replies) plus notification classes. These register the flag/unflag AJAX handlers and enforce content hiding on the front end.
  • includes/ - Shared functions (buddypress-moderation-pro-functions.php), the cache layer (class-bmpro-cache.php), and the WP-CLI command (class-bmpro-cli.php).
  • templates/ - Front-end templates for blocking and the moderation queue.

Data model

Section titled “Data model”

Reports are stored as posts, not in custom tables:

  • bmpro_spam posts hold each reported content item, tagged with the bmpro_content_type taxonomy to record which component it came from.
  • bmpro_avatar_spam posts hold pending avatar submissions.

Related state (a user’s flagged items, block lists, per-content moderation status) is kept in post meta and user meta.

Caching

Section titled “Caching”

class-bmpro-cache.php provides a singleton (bmpro_cache()) that batch-loads and caches moderation data to avoid per-row queries on activity streams and member directories. It exposes preload methods (for example batch_load_activity_moderation()) and invalidation methods that clear the relevant keys when a report is created, updated, or deleted, and when a member is blocked or unblocked.

Request flow

Section titled “Request flow”
  1. A member clicks flag; the public component class handles the AJAX request, creates a bmpro_spam post, and fires the matching bpmp_*_flagged action.
  2. Notifications go out to the configured admins and moderators.
  3. If auto-moderation thresholds are met, the content is hidden according to the visibility setting.
  4. Admins and moderators resolve the report from the Moderation queue, which runs the hide, clean-up, delete, or restriction handlers.
Section titled “Related”