• I recently happened upon an issue with my HOA membership website. As part of our registration procedures, prospective registrants are subjected to a vetting process, and if successfully vetted they are assigned the role, “residents_list”. I use the following shortcode to display the number of users who have been vetted onto our website: [wpmem_show_count role=”residents_list” label=”Registrants to date: “]. The shortcode worked properly up through version 3.5.3. However, when I updated to version 3.5.4 the shortcode now shows ALL subscribers, not just those with the role, “residents_list” — it’s apparently not processing the role request properly. When I did a rollback to version 3.5.3, the shortcode returned the proper number of vetted registrants.

    I’m currently using version 3.5.3, but wish to update for the security releases. However, if I do so I need to hardcode the (vetted) user count each time someone successfully registers, because the shortcode incorrectly returns a count of ALL users. This is a bit of a pain.

    Last week I submitted a support request to Rocketgeek, but have heard nothing.

    Has anyone else observed this issue? If so, was it resolved for you?

    • This topic was modified 5 months, 2 weeks ago by reraymond.
    • This topic was modified 5 months, 2 weeks ago by reraymond.
Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Chad Butler

    (@cbutlerjr)

    Last week I submitted a support request to Rocketgeek, but have heard nothing.

    Unfortunately, I haven’t seen anything. I’m assuming that you used the contact form at https://rocketgeek.com/contact/ ?

    Regardless, there were some changes in 3.5.4 that updated functionality with counting users (and filtering those counts by value). In looking at the changes against your description of the issue, there are some things I have to look into. I’ll check it out and get it resolved and identify next steps for you.

    On a related note, if your use of roles does not involve any non-admin users that have post editing capabilities, the security updates don’t affect you. (Not that you shouldn’t update, but just pointing out that it only affects sites with non-admins who can edit a post.)

    Plugin Author Chad Butler

    (@cbutlerjr)

    OK, I think I have a fix for you to check out.

    The part of that shortcode that returns count by role was moved into a new API function wpmem_get_user_count_by_role( $role ) and then the shortcode was updated to use that function (along with some other updates/changes).

    It looks like that function’s logic is backwards, which results in it returning the total user count when a role is passed as an argument.

    Open the file includes/api/api-users.php in the plugin and go all the way to the end of that file. The last function is wpmem_get_user_count_by_role. In that function, you’ll see the following line:

    return ( 'all' == $role ) ? $users['avail_roles'][ $role ] : $users['total_users'];

    Change that line to this:

    return ( 'all' == $role ) ? $users['total_users'] : $users['avail_roles'][ $role ];

    If that resolves the issue (and it should), let me know and I’ll include that change in the next update as I’m sure you’re not the only person experiencing this problem.

    (Note: implementing this fix would presume you’re doing it in 3.5.4+)

    • This reply was modified 5 months, 2 weeks ago by Chad Butler.
    Thread Starter reraymond

    (@reraymond)

    Yep, that did it. As usual, thanks very much, Chad.

    Dick

    Thread Starter reraymond

    (@reraymond)

    Chad,

    Per my prior reply, I applied your temporary fix, and that took care of the problem. Specifically, as recommended by you, I hard coded a modification to the wpmem_get_user_count_by_role function contained in the api-users.php file to read:

    $users = count_users();
    return ( 'all' == $role ) ? $users['total_users'] : $users['avail_roles'][ $role ];

    Unfortunately, the current WP-Members update (version 3.5.4.3) apparently does not include the modifications you had described in your 7/25/2025 email to me. Did that get overlooked? I’ve therefore re-applied the hard coding revision originally recommended in order to restore the desired functionality on my website. Can you please keep your proposed fix on your “to-do” list?

    Thanks,

    Dick

    Plugin Author Chad Butler

    (@cbutlerjr)

    My apologies for that. This is worked into what should have been the next update – 3.5.5. The most recent update was a quick security patch of the previous 3.5.4 build. Usually, if those types of patches happen, they are:

    • Only the existing patch (to avoid doing any additional updates)
    • Are quickly released (they are to patch a reported vulnerability)
    • Are indicated by a four digit version number (rather than the typical 3 digit version number)

    This change should have also been included in that release because it was a minor bug fix. But it was definitely overlooked because it was put into the 3.5.5 code, which is what I expected the next release to be.

    Sorry about that. It will be in 3.5.5 for certain.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.