Troubleshooting

Symptoms: Non-members can see content that should be restricted.

Diagnosis steps:

Make sure the taxonomy protection rule has inheritance_mode set to all_posts. Without this, the taxonomy term is protected but individual posts in that term are not.

Also verify the post is actually assigned to the protected taxonomy term.

The plugin filters REST API responses via rest_prepare_{post_type} hooks. Make sure the post type has show_in_rest => true and public => true — the hooks are only registered for public REST-enabled post types.

Diagnosis steps:

1. Check the grant status in Memberships > Members — it should be active
2. Check if the grant has a starts_at date in the future
3. Check if the grant has an expires_at date in the past
4. Check if the content is drip-locked (check drip_available_at)
5. Check if the membership is paused (status = paused)
6. Use WP-CLI to debug: wp fchub-membership debug --member=<email>

Drip unlock notifications are processed by the fchub_memberships_drip_process hourly cron. If content is not unlocking:

1. Check WP-Cron — Go to Tools > Site Health and verify WP-Cron is running. If your site has low traffic, WP-Cron may not fire regularly. Consider setting up a real cron job:

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

2. Check the drip_available_at field — The drip_available_at column on the grant record should have the expected unlock date. If it's null, the drip rule might not have been applied correctly during grant creation.

3. Check the notification queue — Go to the drip admin page and look at the notification queue. Failed notifications can be retried individually.

4. Force processing — Run wp fchub-membership drip-process from the command line to process pending notifications immediately.

1. Check that email_drip_unlocked is set to "Yes" in settings
2. Check Action Scheduler for pending or failed fchub_memberships_send_email actions
3. Check the notification's retry_count — after 3 failures, notifications are permanently marked as failed
4. Verify basic WordPress email delivery works (use WP Mail SMTP or a test email plugin)

1. Check the email setting — Each email type can be individually disabled. Verify the specific email is enabled in Memberships > Settings
2. Check Action Scheduler — Go to Tools > Scheduled Actions and look for fchub_memberships_send_email entries. Pending actions are queued but not yet processed. Failed actions show error details
3. Check wp_mail — Test basic email delivery with another plugin. FCHub Memberships uses standard wp_mail() for delivery
4. Check From address — Emails are sent from your admin_email. Make sure your email provider doesn't reject these (SPF/DKIM configuration)

The emails are sent as HTML (Content-Type: text/html; charset=UTF-8). If they arrive as plain text:

1. Check if another plugin is forcing plain text emails
2. Check if your mail provider strips HTML
3. Verify the email headers include the Content-Type header

FluentCRM automation components boot at init priority 30. If triggers are not firing:

1. Verify FluentCRM is active — The FLUENTCRM constant must be defined
2. Check boot timing — The automation module loads at init priority 30. If the membership event fires before priority 30 (during early init), the trigger might not be registered yet. Normal purchase flows fire well after init, so this should only affect custom code that fires events very early
3. Check the automation — Make sure the FluentCRM automation is published and active
4. Check the contact — The trigger needs a FluentCRM contact with a matching WordPress user. If the contact doesn't exist, the trigger won't fire

Smart codes resolve data from the contact's latest active grant. If they return empty:

1. The contact may not have a user_id set in FluentCRM
2. The user may not have any active grants
3. For coupon-related smart codes, verify a CreateFluentCartCoupon action has run for this contact

The SubscriptionValidityWatcher checks subscription validity every 5 minutes via the fchub_memberships_validity_check cron.

1. Check the grant's source_type — It should be subscription, not order. The V3 migration fixes grants that were incorrectly created with source_type = 'order'. If you see grants with source_type = 'order' that should be subscription, re-run migrations by incrementing the DB version in settings
2. Check WP-Cron — The validity check runs every 5 minutes. Verify cron is executing
3. Check the feed settings — If "Cancellation Behavior" is set to "Keep access until validity expires", the grant won't be revoked immediately on cancellation — it waits for the expires_at date

The V3 migration automatically fixes grants that should have source_type = 'subscription' but were created with source_type = 'order'. It detects this by joining the grants table with FluentCart's subscriptions table.

If you suspect grants still have the wrong source_type:

wp fchub-membership debug --member=<email>

This shows the grant details including source_type and source_ids.

The AccessEvaluator uses two levels of caching:

1. Per-request cache — static array, zero overhead on repeated checks within the same request
2. Transient cache — WordPress transients with 5-minute TTL for batch access checks (used in archive filtering)

If pages with many protected items are slow:

• Check if archive filtering is scanning too many posts. The canAccessMultiple() method uses batch checking with transient caching
• Consider using an object cache plugin (Redis, Memcached) to speed up transient reads
• Check if a caching plugin can cache member-specific pages

The plugin creates indexes on all frequently-queried columns. If queries are still slow:

1. Check that indexes were created successfully during migration
2. For very large grant tables (100k+ rows), consider the purge-expired WP-CLI command to remove old expired/revoked grants
3. The audit log is cleaned up weekly (entries older than 90 days). If it's grown large, you can run manual cleanup