Troubleshooting

Troubleshooting

Plugin won't activate

The activator deactivates itself on three conditions:

• PHP < 8.1 (Plugin Activation Error)
• Orravo Core missing (admin notice on plugins screen)
• WordPress < 6.5 (header Requires at least)

The second case is the most common after a fresh install. Activate Orravo Core first, then OMembership.

Recurring workers never fire

All five sweeps depend on Action Scheduler (bundled with WooCommerce). When Woo is absent, scheduled jobs go unscheduled. To verify, check the Action Scheduler queue:

wp action-scheduler queue --status=pending --group=omembership

The re-scheduling pass runs on every init (priority 20), so installing Woo backfills the queue without touching the activator.

Members see the paywall when they shouldn't

1. Confirm the membership row is active (not pending, paused, cancelled).
2. Flush the per-request cache: OMembership_Access::flush_cache( $user_id ).
3. Check that the access rule's plan_id matches a plan the member actually has (OMembership_Memberships::active_plans_for_user()).
4. If drip_rule is set, verify the strategy returns true: OMembership_Drip::is_released_for_user( $user_id, $rule ).

Gate denials are logged via omem/access/denied events stored in wp_omem_events. Filter by type to see why decisions are flipping:

sqlSELECT * FROM wp_omem_events WHERE type = 'access.denied' ORDER BY id DESC LIMIT 50;

Members get duplicate lifecycle emails

Lifecycle markers live in wp_omem_events. The hourly sweep uses one-hour windows (time() - 1h to time() + 1h) so the same membership shouldn't be picked up twice. Duplicates usually mean Action Scheduler is running the worker more than once per hour (e.g. when WP cron is replaced by a system cron that double-fires). Confirm only one scheduler is wired.

Social login callback returns "state mismatch"

The state transient (oe_oauth_state_{state}) expires in 10 minutes. If the OAuth round-trip takes longer (user paused on the provider's screen), the transient is gone. Solutions:

• Increase the transient window in SocialAuth::get_auth_url() (only if you've measured the actual delay).
• Verify your callback URL matches exactly: https://yoursite.com/?oe_oauth_callback={provider}. Mixed http/https, missing query string, or trailing slashes break the lookup.

Magic link clicks redirect to the homepage

The magic link handler reads oe_settings.dashboard_page. If unset, it falls back to home_url(). Configure the dashboard page in Engagement -> Auth -> Pages.

2FA codes never arrive

Email 2FA delivery goes through EmailNotifier::send( $user_id, '2fa_code', ... ), which in turn uses wp_mail() (or OMailer, if active). The transient is 10 minutes. If users miss the window, they need to re-trigger 2FA from the login page.

Importer reports duplicates

Importers are idempotent: each one keys on the source system's primary ID (MemberPress transaction ID, PMPro order ID, RCP payment ID, BuddyBoss group ID) and skips rows that already mapped through. Re-running after a partial failure is safe.

Health score never updates

omembership/health/recompute processes up to 500 active members per daily run. On larger sites you may want to schedule additional runs:

phpas_schedule_recurring_action(
  time() + 3600, 6 * HOUR_IN_SECONDS,
  'omembership/health/recompute', [], 'omembership'
);

Force a single-member recompute via OMembership_Health::compute_for_user( $user_id ).

Where's the log file?

OMembership writes through OMembership_Logger which respects the WordPress log level. The log level is set in general.log_level (default warning). When WP_DEBUG is on, internal failures land in wp-content/debug.log.