Jo?o Faria

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.

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

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.

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

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!

@romulokriya veja os posts anteriores neste tópico.

@macolez veja os comentários anteriores para um quick fix

@jorgehen @fabriciobw essa solu??o aqui em cima só resolve pro checkout com redirecionamento. checkout transparente o buraco é mais embaixo…

@ricardomorganti @jorgehen @fabriciobw @alanabilio btw so o jeito mais fácil de fazer funcionar (mas n?o solu??o completa pra integrar o PIX de fato) é trocar o case ali de cima por isso aqui:

 case 4:
     // Check if order is not paid already
     if ( method_exists( $order, 'get_status' ) && 'processing' !== $order->get_status() && 'completed' !== $order->get_status() ) {
         if ( method_exists( $order, 'get_status' ) && 'cancelled' === $order->get_status() ) {
             $order->update_status( 'processing', __( 'PagSeguro: Payment approved.', 'woocommerce-pagseguro' ) );
             wc_reduce_stock_levels( $order_id );
         } else {
             $order->add_order_note( __( 'PagSeguro: Payment approved.', 'woocommerce-pagseguro' ) );
             $order->payment_complete( sanitize_text_field( (string) $posted->code ) );
         }
      }
      $order->add_order_note( __( 'PagSeguro: Payment completed and credited to your account.', 'woocommerce-pagseguro' ) );

      break;

linha 595 do arquivo includes/class-wc-pagseguro-gateway.php

Amigos, o que acontece é que o PagSeguro retorna direto o status 4. E é isso que o código faz quando recebe esse status:

case 4:
     $order->add_order_note( __( 'PagSeguro: Payment completed and credited to your account.', 'woocommerce-pagseguro' ) );

Normalmente esse status é utilizado para quando o valor é liberado na nossa conta PagBank, ou seja, no caso do cart?o de crédito ali 15 ou 30 dias depois… ent?o o plugin só adiciona essa nota mas n?o faz mais nada, pois a essa altura do campeonato tudo já foi feito. Esse é o problema. Para resolver é preciso verificar se o pedido ainda está com pagamento pendente e, se for o caso, atualizar o que tem pra atualizar.

@claudiosanches se você achar ok posso fazer um PR.

• This reply was modified 3 years, 11 months ago by Jo?o Faria.

@alanabilio qual a resolu??o para o problema vocês conseguiram? Tenho o mesmo problema com o PIX aqui.

I had this issue a while ago. The fix was adding this to the child theme’s functions.php:

function custom_remove_embed_url_dnt($provider, $url, $args){
return add_query_arg( array(‘dnt’ => false), $provider );
}
add_filter(‘oembed_fetch_url’, ‘custom_remove_embed_url_dnt’, 10, 3);`

I think that’s cleaner than jQuery or anything else I could think of.

Hi @matiasmarchetti @adriangzz if you want to chat about this: https://t.me/joinchat/GbQ39BY1gaFyoTE-QvZyAw

@matiasmarchetti yes, the webhook is only to notify WooCommerce of things that happened, but it doesn’t affect credit card payments because they are synchronous anyway. The issue would be for async payments or, for example, if you get a chargeback on a card payment, WooCommerce only knows of the chargeback because of the webhook (and is supposed to add a note to the order, and set the order to pending or something like that).

@matiasmarchetti yes, they do that to avoid expending resources on that busy load that doesn’t accomplish anything.