Background user index building in progress: 1% complete.

Hello Todd. The plugin uses the WP_Cron subsystem to do the indexing-building in the background. Each individual cronjob indexes a batch of 1000 users.

In most sites, cronjobs can run after pageviews of either the front or dashboard. And, if cronjobs are running, that alert should update every few seconds, delivering a larger % number.

Does the alert disappear if you hit refresh or view another dashboard page? If so, the indexing completed.

Have you disabled WP_Cron on your site in favor of an external cron setup? (See this for some background.) If so, you’ll need to wait for the external cron to run.

Todd, thanks for your patience. I’ve worked around the WP_DISABLE_CRON option in version 1.0.2, and the background user indexing should now work correctly.

Hello @olliejones !

I have been using the plugin for a few of weeks or so, and the index rebuilding seems to be a bit erratic, running outside of the scheduled time and for the past few days or so the message has been stuck in admin: “Background user index building in progress: 11% complete. You may use your site normally during index building.”

This is a production site with traffic both in frontend and dashboard, and I have WP-Cron disabled, running a cronjob on the linux box every 10 minutes calling via CP-CLI (wp cron event run –due-now). I see in the logs that task index_wp_users_for_speed_task was run last by the WP-CLI cron runner on Friday, Sep 23rd 08:25AM. Before that I see those tasks being run through the day, taking anything from a fraction of a second to even 2-3 minutes to execute. The website has ~15k registered users, out of which some 50 or so have editing roles.

Do you have any ideas on how I can investigate this issue? Should I try to deactivate and activate again the plugin and see if it gets unstuck?

Thanks!

A followup:

I tried to deactivate/activate, but the plugin failed to deactivate, and remained active. WP-CLI printed out this error:

$ wp plugin deactivate index-wp-users-for-speed
(... omitted a few deprecation notices from other plugins ...)
Fatal error: Uncaught Error: Class 'IndexWpUsersForSpeed\DepopulateMetaIndexes' not found in /xxx/xxx/xxx/wp-content/plugins/index-wp-users-for-speed/includes/deactivator.php:56
Stack trace:
#0 /xxx/xxx/xxx/wp-content/plugins/index-wp-users-for-speed/includes/deactivator.php(38): IndexWpUsersForSpeed\Deactivator::depopulateIndexMetadata()
#1 /xxx/xxx/xxx/wp-content/plugins/index-wp-users-for-speed/index-wp-users-for-speed.php(69): IndexWpUsersForSpeed\Deactivator::deactivate()
#2 /xxx/xxx/xxx/wp-includes/class-wp-hook.php(307): deactivate_index_wp_users_for_speed()
#3 /xxx/xxx/xxx/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#4 /xxx/xxx/xxx/wp-includes/plugin.php(476): WP_Hook->do_action()
#5 /xxx/xxx/xxx/wp-admin/includes/plugin.php(814): do_action()
#6 phar:///usr/local/bin/wp/vendor/wp-cli/extension-command/src/Plugin_Command.php(395): deactivate_plugins()
#7 [internal function]: Plugin_Command->deactivate()
#8 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/W in /xxx/xxx/xxx/wp-content/plugins/index-wp-users-for-speed/includes/deactivator.php on line 56

Another followup: I was able to deactivate via admin. I see in the source code that the depopulate task class is only loaded in certain cases:

/* stuff required for all back-end. cron, REST api operations. */
    if ( wp_doing_cron() || wp_doing_ajax() || is_admin() || wp_is_json_request() || wp_is_xml_request() ) { (... requiring files ...) }

I guess adding a || ( defined( 'WP_CLI' ) && WP_CLI ) to that if clause will solve the WP-CLI issue.

Thanks for the bug report. Before the latest version, the plugin did not take into account sites with disabled WP_Cron. So the index rebuilding was, as you say, erratic.

I will investigate the deactivation via wp-cli and make a fix.

Thank you for your patience!

Hi @olliejones! Thanks for the reply. I sent you a PR on GitHub with the WP-CLI fix.

An update: not sure if the issue is gone, but last night the index was rebuilt to 100% complete and did not get stuck. I did the WP-CLI patch I mentioned above, and also removed the plugin cron kick by commenting out the include for instacron.php:

/* Disabled-cron only. We use WP_Cron's wp_schedule_single_event to do the batched-up index, so
     * we need to activate it when it's disabled.  */
    if ( ! wp_doing_cron() ) {
      $cronDisabled = defined( 'DISABLE_WP_CRON' ) && true === DISABLE_WP_CRON;
      if ( $cronDisabled ) {
      #  require_once plugin_dir_path( dirname( __FILE__ ) ) . 'includes/instacron.php';
      }
    }

I will see if the index rebuilds tonight again, or if it gets stuck again, but I think the WP-CLI check might have been what did the trick, considering I invoke cron via WP-CLI as I mentioned before.

Version 1.1.1 handles both the wp-cli deactivation and the disabled wp-cron correctly, I believe. Thanks for your patience.