Rose

My turn for a slow reply after being away.

1. No. It’s the WooCommerce built in phone field. The only difference with the Custom Checkout Fields is that the phone field is set to required.
I did some further investigation and found that if integration with Custom Checkout Fields is enabled, the phone field sits separated as in my OP. But if I have integration unticked/deselected it looks correct and still shows the custom fields from the TH CCFs plugin.

Here’s screenshots:

This is with the integration turned off.

And integration turned on – the phone number has ‘fallen’ out of the billings address box and sits below it with a gap.

2. Apologies, I was getting confused as we have the free version installed on our live website (just using the admin preview function so far) but was trying out the premium on a web agency dev testing server and got which has what features mixed up. I’ll contact sales with that question instead 🙂

In case anyone else comes across this issue. Here’s what I’ve muddled together. It’s likely very unoptimised and may be the totally wrong way to go about this but since I have Cognitive Impairment I have a hard time making sense of things and without any further help from here, this is the best I could do.

This goes in functions.php or, what is more recommended to do, use a code snippets plugin.

// First set the email address as the username for all new customer accounts created
add_filter( 'woocommerce_new_customer_data', function( $data ) {
	$data['user_login'] = $data['user_email'];

	return $data;
} );

// Next remove "Username" from "Username or email address" on the WooCommerce My Account page login so it reads "Email address"
function filter_woocommerce_my_account_login_text( $translated_text, $text, $domain ) {
	switch ( $translated_text ) {
		case 'Username or email address' :
			$translated_text = __( 'Email address', 'woocommerce' );
			break;
	}
	return $translated_text;
}
add_filter( 'gettext', 'filter_woocommerce_my_account_login_text', 20, 3 );

// Finally we want to remove any references to a username from error validation
// define the woocommerce_process_login_errors callback 
function filter_woocommerce_process_login_errors($validation_error, $post_username, $post_password)
{
    //if (strpos($post_username, '@') == FALSE)
    if (!filter_var($post_username, FILTER_VALIDATE_EMAIL)) //<--recommend option
    {
        throw new Exception( '<strong>' . __( 'Error', 'woocommerce' ) . ':</strong> ' . __( 'Please enter a valid email address.', 'woocommerce' ) );
    }
    return $validation_error;
}
add_filter('woocommerce_process_login_errors', 'filter_woocommerce_process_login_errors', 10, 3);

References:

https://www.checkoutwc.com/documentation/how-to-force-woocommerce-to-use-email-address-as-username-when-registering-a-new-account/

https://gist.github.com/BFTrick/7040403

https://stackoverflow.com/questions/43630347/how-to-login-with-only-email-and-password-in-woocommerce

Apologies for the slow reply, I got locked out of my WordPress account for several days :/ Thanks for getting back to me so quickly.

I went through the database and found some VERY old entries for events, like 6 year old entries that did not show in The Events Calendar events. They came from when we were first using TEC many years ago, then for a while we stopped doing events and I uninstalled the plugin. It’s only now that we’re doing regular events again and needed to reinstall it.

I suspect that somehow those original events became corrupted or the way that TEC stored events in the database changed in that time so those original events became sort of orphaned and sort of not, and that might be what was causing the migration to stall.

In the end, I decided to take the nuclear option and manually searched the database to delete every single instance I could (searched for “tribe” and “tec” and removed all relevant rows). I noted that there were some (I assume?) new tables prepended with “tec” in the database and I that they were created by the migration? At any rate, I dropped those tables too.

After deleting absolutely everything, I reinstalled and happy to say that it’s now working flawlessly 🎉

For those perhaps considering the full deletion option where manually migrating your events, I opened every single event I had (in admin, not front end) and left them open until I had done all the database deletion and reinstall. That way I was able to at least copy-paste all the details into the fresh install. (You could alternately save the pages as html if you wanted an offline backup that doesn’t rely on leaving browser tabs open).

So yeah, thanks again for your help even if I ended up resolving it in a very time consuming and destructive way.

@jescandoit Yes, that file is accessible. I also ran it through multiple servers around the world and they all reported that it’s accessible. 🙂 I’ll dismiss the warning.

I’m also unable to migrate but I’ll start a new thread for that.

Is it also possible to restrict the past date range to a set date e.g. not allow any date before April 2021?

EDIT: I’ve been able to partially resolve this by using the guide here: https://acowebs.com/guideline/plugin-docs-faqs/wcpa/datetime-customizations/

{
"formatDate":"d/m/Y",
"mask":"39/19/2099",
"minDate":"01/04/2021"
}

However, the date picker calendar still sets the date format as the WordPress default (November 2, 2022 instead of 02/11/2022) and manually entering a date seems to confuse the date picker calendar for some dates e.g. it can’t make sense of 31/02/2022 because it’s reading it as the 2nd of the 31st month 2022.

EDIT 2: Setting the WordPress date format as d/m/Y fixes the inconsistent dates and the date picker calendar doesn’t mix up the day and month. However this can’t be a permanent solution as blog articles and the like need to have the F j, Y format.

• This reply was modified 3 years, 7 months ago by Rose.
• This reply was modified 3 years, 7 months ago by Rose.
• This reply was modified 3 years, 7 months ago by Rose.