Open cdhassell opened 3 years ago
@cdhassell Thanks for the report. Could you provide a bit more info about your setup:
Also, would you be able to run some queries on your setup to help debug this?
Thanks Christian.
WP 5.7.2.
Not multisite.
Civicrm 5.39.0
Yes there are users that have None in the Role column in the list at /wp-admin/users.php. Not sure how to get a count.
No BuddyPress.
Yes I can run queries.
Yes there are users that have None in the Role column in the list at /wp-admin/users.php
This would explain the mismatch. The WordPress count_users()
function requires there to be an entry in the user_meta
table for {$blog_prefix}capabilities
. If there are none, the users are excluded from the count. It makes sense to the extent that a user without capabilities isn't really a user at all.
Perhaps it's better to think of those numbers as representing genuine users?
Ok I can see the 1307 entries in the user_meta table so that makes sense. I'm not clear on why WP creates users with no role when I have the default role set to Subscriber, but that is not an issue for you. The only other question I have is why "not in Civicrm" isn't equal to 1307 - 1053 = 254?
The only other question I have is why "not in Civicrm" isn't equal to 1307 - 1053 = 254?
@cdhassell Out of interest, do you see 254 users when you filter the users list by "not in CiviCRM"? Or 20? And what about the "in CiviCRM" count?
FYI, the "in CiviCRM" value is simply the count of a query for the "total number of entries in the UFMatch table". This is unaffected by the presence of a role for each WordPress user.
The "not in CiviCRM" value is calculated by querying for WordPress users that are not in CiviCRM's UFMatch
table. My guess, therefore, would be that there is an overlap between the "set of users with no role" and the "set of users not in CiviCRM".
I found these to be the most reliable totals - because, like you, I have also found the counts to be skewed by plugins that manipulate users to implement such features as "held for moderation". BuddyPress, in particular, can produce negative numbers for the "not in CiviCRM" value when there are large numbers of spam signups held in the moderation queue - a figure that seemed worse than the query that I ended up using.
I am open to suggestions for better calculation of these totals.
Thank you, I see that it is more complex than I realized. I would just point out that the links at the top of the Manage Users tab display a list of users, which have a total number of items next to the pagination links at the bottom of the page. So the "In Civicrm (1,039)" at the top agrees with the "1,039 items" shown at the bottom of the page. But neither the "All" summary nor the "Not in Civicrm" summary at the top agrees with the total items shown at the bottom of those pages. I would suggest that the query used to create the totals at the top of the page should be the same as the query that creates the item count at the bottom of the list. Alternatively, it may be less confusing to users if you just deleted the counts from the top links and let the item counts at the bottom of the page speak for themselves.
Alternatively, it may be less confusing to users if you just deleted the counts from the top links and let the item counts at the bottom of the page speak for themselves.
That's a good idea and defintely the simplest to implement!
I'll have a think about the whole matter and see what I can do given my time constraints.
The total user counts at the top of the Manage Users tab on my site say:
All (1,307) | In CiviCRM (1,053) | Not in CiviCRM (20)
Initially I noticed that the "in" and "not in" numbers do not sum to the "all" figure. In fact only the "in" figure is correct. The "not in" figure should be 1403 and the "all" figure should be 2456.