dassels43

Hi,

Yes, we had checked those but the screen for enabling/disabling the debug log exists only in the network admin.

We did manage to stop the logging, unfortunately we’re not sure exactly what it was that really stopped it. We did discover what was stopping our efforts. In an earlier attempt to stop the debug logs, we defined these variables to see if they would have any effect:

define('LSCWP_LOG', false);
define('LSCWP_LOG_LEVEL', 0);

It didn’t and then we proceeded to clean up the entries in the database that had the option name “litespeed.conf.debug” set to “1”. We’re not sure why all the subsites had this value enabled but they were. This value remained set to “1” even after were uninstalled and reinstalled the plugin, which we weren’t expecting. However in multisite installs, the code reads and writes to the wp_sitemeta table as it should. So we still don’t know why in this instance toggling sitemeta on/off was having no effect either.

For reference we have an identical site and debug logging works as expected.

It’s possible there was a stuck value cached somewhere or, somehow we were reading subsite table entries but we don’t know. The actual fix was masked by our earlier attempt to disable the logging:

define('LSCWP_LOG', false);

Doesn’t actually do anything as the code in the debug function only checks for the existing of it, like this:

Line 503 in debug.2.cls.php

	public static function debug( $msg, $backtrace_limit = false ) {
		if ( ! defined( 'LSCWP_LOG' ) ) {
			return;
		}

If it sees ‘LSCWP_LOG’ it’s not going to exit. To save someone future troubleshooting headaches, might want to have it check both presence or value, so entering “define(‘LSCWP_LOG’, false);” will exit the function.

Hi Lucian,

Thanks for the follow-up! Your questions allowed us to do further testing which revealed the issue lies with a custom login form we have. The native wp-login does a check for roles before running 2FA code, so we added that in to the custom form to prevent running 2FA without a role present which seems to have fixed the issue.

Hi Yordan,

Thanks for the fix, works great, and good solution!

Hi,

Ok, I tried again with the latest version and this seems to be working correctly. Thanks for the quick update!

For anyone that wants a work around, you can do the following:

Update functions.php in your child theme:

/**
 * Add a new country to countries list
 */
add_filter( 'woocommerce_countries',  'add_eu_to_dropdown' );
function add_eu_to_dropdown( $countries ) {
    $new_countries = array('EU'  => __( 'European Union', 'woocommerce' ),
	                    );

	return array_merge( $countries, $new_countries );
}

Then edit this plugin with the following:

	/*
	* Save the product meta settings for simple product 
	*
	* @since 1.0.0
	* @para $post_id
	*/
	public function save_custom_product_fields( $post_id ) {
		$restriction = isset($_POST['_fz_country_restriction_type']) ? sanitize_text_field($_POST['_fz_country_restriction_type']) : '';
		if (! is_array($restriction)) {

			if ( !isset( $_POST['_restricted_countries'] ) || empty( $_POST['_restricted_countries'] ) ) {
				update_post_meta( $post_id, '_fz_country_restriction_type', 'all' );
			} else {
				if ( !empty( $restriction ) ) {
					update_post_meta( $post_id, '_fz_country_restriction_type', $restriction );
				}
			}
			
			$countries = array();
			
			if (isset($_POST['_restricted_countries'])) {
				$countries = isset($_POST['_restricted_countries']) ? wc_clean( $_POST['_restricted_countries'] ) : '';
			}

			$eu_countries = array( 'AT', 'BE', 'BG', 'CY', 'CZ', 'DE', 'DK', 'EE', 'ES', 'FI', 'FR', 'GR', 'HU', 'HR', 'IE', 'IT', 'LT', 'LU', 'LV', 'MT', 'NL', 'PL', 'PT', 'RO', 'SE', 'SI', 'SK' ); 
			
			if ( ! empty( $countries ) && is_array( $countries ) && in_array( 'EU', $countries )) {
					$countries = array_merge($countries, $eu_countries);
			} else {
					$countries;
			}
			
			update_post_meta( $post_id, '_restricted_countries', $countries );
		}
	}
	
	/*
	* Save the product meta settings for variation product 
	*
	* @since 1.0.0
	* @para $post_id
	*/
	public function save_custom_variation_fields( $post_id ) {
		$restriction = isset($_POST['_fz_country_restriction_type'][ $post_id ]) ? sanitize_text_field($_POST['_fz_country_restriction_type'][ $post_id ]) : '';
		
		if ( !isset( $_POST['_restricted_countries'] ) || empty( $_POST['_restricted_countries'] ) ) {
			update_post_meta( $post_id, '_fz_country_restriction_type', 'all' );
		} else {
			if ( !empty( $restriction ) ) {
				update_post_meta( $post_id, '_fz_country_restriction_type', $restriction );
			}
		}

		$countries = array();
		if (isset($_POST['_restricted_countries'])) {
			$countries = isset( $_POST['_restricted_countries'][ $post_id ] ) ? wc_clean( $_POST['_restricted_countries'][ $post_id ] ) : '';
		}

		$eu_countries = array( 'AT', 'BE', 'BG', 'CY', 'CZ', 'DE', 'DK', 'EE', 'ES', 'FI', 'FR', 'GR', 'HU', 'HR', 'IE', 'IT', 'LT', 'LU', 'LV', 'MT', 'NL', 'PL', 'PT', 'RO', 'SE', 'SI', 'SK' ); 
			
		if ( ! empty( $countries ) && is_array( $countries ) && in_array( 'EU', $countries )) {
				$countries = array_merge($countries, $eu_countries);
		} else {
				$countries;
		}

		update_post_meta( $post_id, '_restricted_countries', $countries );
	}

Basically, we want to change how the 2 functions “save_custom_product_fields” and “save_custom_variation_fields” save the data. Note that on next update this will need to be updated again until this or similar feature is implemented by Zorem.

Ok, we found the issue. The new checkout is looking for billing fields “phone” and “address2” to exist. We remove this from the checkout as this information is not required in order to process the transaction since it is only digital products that are sold. If we put the back the fields the JS error goes away. There should be a modification to the JS code to allow that to be optional. The legacy version doesn’t generate JS validation for those fields not existing.

Hi Megan,

There is no option anymore to “activate anyway” or “ignore”. They (Woocommerce) removed this option a few updates back.

Since, as you confirmed, only the code needed to confirm HPOS compatibility is missing, we can manually add this in the meantime until the update goes through. Do you have a recommendation as to where to put the code?