Possible conflict with WooCommerce v5.4.1

  • Resolved dabrolga

    (@dabrolga)


    3 years, 5 months ago

    Hi Gregory
    Just letting you know that since we upgraded WooCommerce from v5.3.0 to v5.4.1 when users log in and WooCommerce schedules the wc-admin_import_customers hook we get the following set of errors logged:

    [21-Jun-2021 23:04:05 UTC] WordPress database error Table ‘dbnamexxx.a’ doesn’t exist for query SELECT a.action_id FROM a LEFT JOIN g ON g.group_id=a.group_id WHERE 1=1 AND g.slug=’wc-admin-data’ AND a.hook=’wc-admin_import_customers’ AND a.status=’pending’ AND a.claim_id = 0 AND (a.hook LIKE ‘%[790]%’ OR (a.extended_args IS NULL AND a.args LIKE ‘%[790]%’) OR a.extended_args LIKE ‘%[790]%’) ORDER BY a.scheduled_date_gmt ASC LIMIT 0, 1 made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters, {closure}, cerber_wp_login_page, require(‘wp-login.php’), wp_signon, do_action(‘wp_login’), WP_Hook->do_action, WP_Hook->apply_filters, wc_user_logged_in, wc_update_user_last_active, update_user_meta, update_metadata, do_action(‘updated_user_meta’), WP_Hook->do_action, WP_Hook->apply_filters, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import_via_last_active, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import, Automattic\WooCommerce\Admin\Schedulers\ImportScheduler::schedule_action, Automattic\WooCommerce\Admin\Schedulers\ImportScheduler::has_existing_jobs, WC_Action_Queue->search, as_get_scheduled_actions, ActionScheduler_DBStore->query_actions
    [21-Jun-2021 23:04:05 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘WHERE slug=’wc-admin-data” at line 1 for query SELECT group_id FROM WHERE slug=’wc-admin-data’ made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters, {closure}, cerber_wp_login_page, require(‘wp-login.php’), wp_signon, do_action(‘wp_login’), WP_Hook->do_action, WP_Hook->apply_filters, wc_user_logged_in, wc_update_user_last_active, update_user_meta, update_metadata, do_action(‘updated_user_meta’), WP_Hook->do_action, WP_Hook->apply_filters, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import_via_last_active, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import, Automattic\WooCommerce\Admin\Schedulers\ImportScheduler::schedule_action, WC_Action_Queue->schedule_single, as_schedule_single_action, ActionScheduler_ActionFactory->single, ActionScheduler_ActionFactory->store, ActionScheduler_DBStore->save_action, ActionScheduler_DBStore->get_group_id
    [21-Jun-2021 23:04:05 UTC] WordPress database error Incorrect table name ” for query SHOW FULL COLUMNS FROM made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters, {closure}, cerber_wp_login_page, require(‘wp-login.php’), wp_signon, do_action(‘wp_login’), WP_Hook->do_action, WP_Hook->apply_filters, wc_user_logged_in, wc_update_user_last_active, update_user_meta, update_metadata, do_action(‘updated_user_meta’), WP_Hook->do_action, WP_Hook->apply_filters, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import_via_last_active, Automattic\WooCommerce\Admin\Schedulers\CustomersScheduler::schedule_import, Automattic\WooCommerce\Admin\Schedulers\ImportScheduler::schedule_action, WC_Action_Queue->schedule_single, as_schedule_single_action, ActionScheduler_ActionFactory->single, ActionScheduler_ActionFactory->store, ActionScheduler_DBStore->save_action, ActionScheduler_DBStore->get_group_id, ActionScheduler_DBStore->create_group

    When I deactivate Cerber the problem goes away. I suspect it is something to do with cerber_wp_login_page. We are using Cerber 8.8.5 on WordPress 5.7.2 . This happens on two servers of slightly different configurations.

    Thanks for the great work.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author gioni

    (@gioni)

    Hi!

    I’ll look into it soon. Please make sure that no other WooCommerce-related plugin is involved here.

    Thread Starter dabrolga

    (@dabrolga)

    Hi Gregory
    Thanks, no hurry as far as I am concerned, as it only affects the wc-admin part of WooCommerce. Our WooCommerce setup is very simple with no other WooCommerce-related plugins.

    imrelaszlo

    (@imrelaszlo)

    Hello! The same problem appeared here. Any resolution / bugfix?

    • This reply was modified 3 years ago by imrelaszlo. Reason: mistypeing
    Dave Lozier

    (@dave-lozier)

    Sorry – got ahead of myself. Even though our error is similar we do not have your security plugin in use. I’ll continue my google search.

    Thread Starter dabrolga

    (@dabrolga)

    Hi imrelaszlo
    Are you running WordPress from a subdirectory? The site I have the problem with has WordPress in a subdirectory but the SITE-URL is the root of the domain. I have also found that the Cerber REST API restrictions do not appear to work correctly on my sites with WordPress in a subdirectory, but are fine on sites with WordPress installed in the root directory.

    Thread Starter dabrolga

    (@dabrolga)

    The fix for me was to remove the Cerber “Custom login URL” setting and use another solution to redirect my login page. I have had no problems since. The bug appears to be coming from the function cerber_wp_login_page and this does nothing if “Custom login URL” is empty.

    Plugin Author gioni

    (@gioni)

    Please test out this feature: https://wpcerber.com/user-switching-with-wp-cerber/

    The only purpose of the function cerber_wp_login_page() is to load the default WordPress login script. There is no place for bugs in the function.

    We run WooCommerce in a subdirectory too, but we have WordPress Address (URL) = Site Address (URL). No issues for years.

    Thread Starter dabrolga

    (@dabrolga)

    I am sure there are no problems if WordPress Address (URL) = Site Address (URL). I am fairly sure the problem only occurs if WordPress Address (URL) != Site Address (URL) which is why only a few people have the issue, although a lot of people wouldn’t even be aware that there is a problem, because it doesn’t show unless logging is enabled. In our case WordPress Address (URL) is like https://example.com/subfolder and Site Address (URL) is like https://example.com.

    Whilst function cerber_wp_login_page is a straightforward load of the default WordPress login script it is affected by the filter site_url which calls function cerber_login_logout. The interesting thing is that our setting for “Custom login URL” is like https://example.com/loginpage but our login page is and posts to https://example.com/subfolder/loginpage as set by the filter, I would have thought it should post to https://example.com/loginpage. It still works OK in most situations but I think it causes some problem here, also it would be nice if the login page was what was asked for in the “Custom login URL” setting.

    Switching on “Deferred rendering” did solve the problem so this should be the accepted fix, thank you. I did read your article on that when I was first testing this problem but I didn’t consider it relevant because I was testing with no other plugins other than WooCommerce.

    Thanks for your help to get to a solution for those affected.

    I have the same problem on my website, BUT in my case the WordPress Address (URL) is the SAME as the Site Address (URL).

    I tried the suggested solution of deferring the rendering of the login page and that stopped the problem.

    It seems odd to me that the rendering of the login page should have any effect whatsoever on the auto scheduled tasks in Woocoommerce.

    It would be good if Cerber could look into this a bit more closely

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Possible conflict with WooCommerce v5.4.1’ is closed to new replies.