Allow Live Updating of User & Site number in Multisite network dashboard 'Right Now' meta box

[vmaia]

Wordpress installation don’t show the correct number of users and sites correctly registered in the site.

Please see images for reference:

• ​https://dl.dropbox.com/u/7531173/mu/Only1Site1User.png
• ​https://dl.dropbox.com/u/7531173/mu/UsersNumber.png
• ​https://dl.dropbox.com/u/7531173/mu/UsersSites%20.png

I am 99.999% sure I saw this on 3.4.2 as well as 3.5 with a guy at DreamHost, but the 3.5 upgrade fixed him.

See ​http://wordpress.org/support/topic/missing-user-site-number-in-wp-adminnetworkindexphp?replies=8 for previous work done.

Have in mind, that these numbers are cached.

From get_user_count(): The count is cached and updated twice daily. This is not a live count.

#16367, #15567

This count depends on cron. If cron is not working correctly or the site has no page views then the counts will not be updated. Only one cron action is executed with each page view.

I tested in different servers, including dedicated and shared (Hostgator), and have the same result. No count.

Replying to vmaia:

I tested in different servers, including dedicated and shared (Hostgator), and have the same result. No count.

You can use ​http://wordpress.org/extend/plugins/cron-debug-log/ to test and see if your cron is working. It's very rudimentary but it will show if you are having errors on cron.

If this is a bug, I highly doubt it is a regression, as these counts have been counting the same way since around 3.1.

i tried testing this bug, i added a few sites to a network site setup and the user/site count was correct once i ran the wp_update_network_counts() function from core control.

on my setups it looks like this gets updated the next time the cron ran, maybe hostgator isn't firing the cron correctly?

any reason not to update those values right after changing the number of users or sites when these are added/removed? too intensive on a large network?

seems a little confusing for network admin that after they add/remove site/user (s), the count is out of sync. this would also remove the reliance on the cron firing. also, since a user can be added independently of a blog, it would make sense to have a separate function for each count. anyway this doesn't seem like a bug unless there is a new issue with how cron gets fired.

patch summary:

in ms-function.php:

• split wp_update_network_counts into separate functions for users, blogs. that way both potentially heavy queries don't have to be run when only the count of users or blogs has changed. both queries are still run by the original function, called by cron, and when a site is added along with a user (the normal case)

• added recount calls when a user or blog is added

in ms.php

• added recount calls when a user or blog is deleted

notes:

i'm not really sure i placed the calls in the right place, feel free to correct me. i think i mentioned, i'm new here.

I did some testing on my local multisite install and the updates are now correct immediately after adding or removing a user (or users) from the network admin or from a site dashboard. also adding a site or removing site(s) updates the count immediately.

i did not test my patch against a non-multisite config, but assume it works.

right-now-liv.diff would render the caching on this mostly worthless for large networks with frequent user/site creation. Someone who has a small network that wants to have live stats can easily accomplish this with a small plugin

add_action( 'wpmu_new_blog', 'wp_update_network_counts' );
add_action( 'wpmu_new_user', 'wp_update_network_counts' );
// etc.

recommend wontfix.

Replying to wpmuguru:

right-now-liv.diff would render the caching on this mostly worthless for large networks with frequent user/site creation. Someone who has a small network that wants to have live stats can easily accomplish this with a small plugin

add_action( 'wpmu_new_blog', 'wp_update_network_counts' );
add_action( 'wpmu_new_user', 'wp_update_network_counts' );
// etc.

recommend wontfix.

we could add a check for large sites before running the update, but i agree my patch renders caching useless. still the current behavior is confusing to novice users, and for small networks without frequent user/site creation i think the caching is superfluous.

would you accept a patch that, instead of recalculating the entire count, simply pulled and updated the current count - incremented/decremented based on the current action? no query would be required, just the option updated. same locations as my existing changes i believe.

caching is great, but in this case its confusing the end user. it almost sounds like you are saying the ticket itself should be thrown out, that the current behavior is fine as is.

do you agree with the ticket idea that the widget should show the live count, or do you think the caching is more important and things should stay as they are? could we use wp_is_large_network() to split up the cases?

new patch adds filter to turn on live update

new patch adds hooks to turn on live updating - off by default; also added unit test.

22917-2.diff looks fine to me and is a good compromise.

Replying to wpmuguru:

22917-2.diff looks fine to me and is a good compromise.

glad you like it, this also gives us an easy way to turn on live updating automatically for small networks if we decide thats a good idea.

also we could add a message next to the site/user count in the 'right now' meta box to indicate the count isn't live (unless it is), which is point of the initial confusion.

updated/cleaned up unit test for 22917

Same as 22917-2.diff, with minor formatting fixes

Replying to adamsilverstein:

could we use wp_is_large_network() to split up the cases?

I guess we could use it to set the default value for the filter. It needs to be moved to ms-functions.php in that case though, see #23683.

refresh

refresh named properly

uses wp_is_large_network to set live count update defaults

Replying to SergeyBiryukov:

Replying to adamsilverstein:

could we use wp_is_large_network() to split up the cases?

I guess we could use it to set the default value for the filter. It needs to be moved to ms-functions.php in that case though, see #23683.

22917.4.diff​​ adds wp_is_large_network calls to set defaults for live updating; haven't tested yet :)