Common issues and FAQs

The issues we see most often in support, and the fixes. If you don’t see your issue here, send a debug log plus a screenshot of WB Plugins → Profile Views → Overview to support@wbcomdesigns.com.

“Notify on view” toggle is on but nobody’s getting notifications

The notification path requires the BuddyPress Notifications component. Without it, the plugin silently skips the notification step — the visit is still recorded, the chart still updates, but the bell stays empty.

Fix:

1. Settings → BuddyPress → Components.
2. Tick Notifications if it’s unchecked. Save.
3. Have a member visit another member’s profile. The owner should now see a 1 in the BuddyPress notification bell.

Other gotchas:

• The plugin dedupes notifications: only one per (viewer, profile) pair per 24 hours. To narrow / widen, see the bpv_notification_views_interval_day filter in Hooks and filters.
• Logged-out visits never trigger a notification — the visitor has no identity to attach one to.
• If the visitor’s visitor_setting user meta is 'no' (they opted out), no row is recorded so no notification fires.

Member views aren’t being counted

A handful of conditions cause this:

• Dedupe window still active. With save_count_by = session, the same viewer revisiting the same profile inside the same login session counts once. With save_count_by = referer, it’s once per 6 hours. Test in incognito or as a different user.
• The visitor opted out. If Allow user settings is on and the viewer set their toggle to “No”, their visits aren’t recorded going forward. Check wp user meta get {id} visitor_setting.
• The viewer is logged out and Exclude logged-out viewers is on. Anonymous visits are recorded but excluded from every count and the Views tab. Turn the toggle off if you want them visible.
• The page being viewed isn’t actually a profile. The capture pipeline only fires when the request resolves to a single user profile (bp_is_user()). It doesn’t fire on the directory or in shortcode-rendered fragments.

Recent visitors strip is in the wrong spot

The strip uses different hooks per theme:

Theme	Hook used
BuddyX Pro / REIGN	wbtm_after_cover_imager_container
Default BuddyPress / BP Nouveau / others	bp_after_member_header
Any theme + Render inside the BuddyPress profile header on	bp_profile_header_meta

If the strip lands in the wrong place, turn on Display → Render inside the BuddyPress profile header. That forces it onto bp_profile_header_meta, which most themes wire close to the avatar.

If you’re using a custom theme and the strip doesn’t appear at all, your theme is likely missing the relevant hook. Add this where you want the strip:

do_action( 'bp_after_member_header' );

Strip is hidden on BuddyBoss /edit and /settings

This is intentional — the strip is suppressed on those URIs to keep the profile-edit chrome clean. Browse to a regular profile section (Activity, Profile, Friends) and the strip reappears.

“Notify on view” notification text shows raw HTML

Older BuddyPress versions render component-format strings differently. The format callback returns a string for back-compat and an array for newer BP. If you see HTML markup leaking into the notification text, ensure BuddyPress is at least 8.0.

License says “Active” but updates aren’t showing

WordPress caches plugin update checks for ~12 hours. Force a refresh:

wp plugin update --dry-run --all
# multisite:
wp plugin update --dry-run --all --network

If your license is on a different site (you forgot to deactivate before migrating):

1. Go to the old site → WB Plugins → Profile Views → License → Deactivate License.
2. On the new site → paste the same key → Activate License.

If you’ve used your activation quota, log into your Wbcom Designs account, find the site under Licenses, and remove a stale entry.

“Sorry, you are not allowed to access this page” on the License tab

Older 1.4.x builds redirected through a wbcom-license-page slug that no longer exists. If you’re seeing this, you’re likely on an old install path. Update to 1.5.0 — the License tab now lives at ?page=bp-profile-views-settings&tab=license.

Chart on Views tab is blank

Common causes:

• Chart.js isn’t loading. Open the browser console — if you see “Chart is not defined”, another plugin is dequeueing scripts on profile pages. Disable that plugin or selectively re-enqueue: wp_enqueue_script( 'bpv-chart-js' ) from your theme.
• Chart style is set to a value Chart.js doesn’t recognise. Valid values: line, bar, polarArea. Check wp option get bp_profile_views_general_options and confirm. If empty, save the Display tab again to reset.
• No data yet. A brand-new install with zero visits renders an empty chart skeleton. Browse a few profiles as different users and reload.

Members directory badge (“N views”) doesn’t appear

Three things to check:

1. Display → Show view count on members directory cards must be on.
2. The viewing user must have at least one row in {prefix}bp_profile_views — members with zero views show no badge.
3. The badge renders inside bp_directory_members_item_action (BP Nouveau) or bp_member_options (BP Legacy). If your theme has heavily customised member cards, those hooks may not fire — check your theme’s members/members-loop.php.

“Failed to verify nonce” on the Members Views tab AJAX

The leaderboard fetches via wp_ajax_get_views, gated by bp-member-view-nonce. Causes:

• The page was open for >24 hours — nonces expire after one day. Reload.
• A page cache (e.g. WP Rocket, W3 Total Cache) is caching logged-in admin pages. Exclude /wp-admin/ from caching.
• A security plugin is stripping nonces. Disable it temporarily and retry.

Members Views table loads slowly on big sites

The leaderboard query scans the full table grouped by user_id. On installs with millions of rows it can take >2s. Mitigations:

• Add a covering index — (user_id, created) — for date-range queries. See Database schema.

• Run a periodic cleanup of old rows. The plugin doesn’t ship one — example with WP-CLI:

  wp db query "DELETE FROM \`$(wp db prefix)bp_profile_views\` WHERE created < DATE_SUB( NOW(), INTERVAL 1 YEAR );"

Bot traffic / automated crawlers inflating counts

1.5.0 ships a User-Agent filter that drops common bot UAs (Googlebot, Facebot, LinkedInBot, Pingdom, curl, etc.) before the row is inserted. If you’re still seeing bot inflation:

• Confirm exclude_logout_user_count = yes (the default). Most crawlers visit logged-out, so the toggle filters them out of the UI.
• Block bots earlier — at the CDN, server, or via a security plugin like Wordfence — so the visit never reaches PHP.

Stale visitor_setting user meta

On the first admin page load after activation, the plugin backfills visitor_setting = 'yes' for every existing user who doesn’t already have that meta. This runs on admin_init and is gated by the bp_profile_views_visitor_setting_seeded option, so it fires only once per install — never on frontend requests, never on subsequent admin loads.

If a user reports their toggle “doesn’t stick”:

1. wp user meta get {id} visitor_setting — confirm what’s actually stored.
2. If it’s empty (for example, the user was created before the plugin was installed and the site has never had an admin load since), seed it manually:

   wp user meta update {id} visitor_setting yes

I deleted the plugin and lost all data — can I recover it?

Not from within the plugin. uninstall.php drops the table. If you’d planned to keep data, you would have set BPV_KEEP_DATA_ON_UNINSTALL before deleting. Your only recovery path is a database backup taken before the uninstall.

To prevent this in the future, see Uninstall.