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 ??

I’ve been away and only just got back. Unfortunately the answer you gave me is more orientated towards the WordPress logins, not the Woocommerce customer account page.

This remains unresolved and I’ve given up trying to fix it.

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

1. There is no way I’m relying on Chat-GPT to output correct code, especially on a website that handles people’s private data.
2. I already did that, I searched everywhere and couldn’t find any hints or solutions, hence why I asked here
3. I’d rather not create yet another account to ask what I would have thought was a simple question about WooCommerce’s built-in hooks/filters. ??

WooCommerce has hooks for this reason, why can support staff not answer questions on WC’s own code?

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.

I note other people have had the same issue but I can’t find any resolution: https://www.ads-software.com/support/topic/migration-preview-in-progress-but-never-completes/page/2/#post-16438839

@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.

Ok, an update: I think the custom fields I was creating just needed the cache clearing. However, Woocommerce’s built in fields e.g. phone number and postcode don’t respect “number” validation and I’m still able to enter text characters (a-z and symbols). The postcode I was able to fix by adding an input mask. But the phone number one, despite having the “phone” and “number” validations still allow characters other than numbers.
Cache has definitely been cleared and I’ve tried across both Firefox and Chromium (Chrome) with both browsers exhibiting this behaviour.

EDIT: Spoke too soon. The custom fields number validation is working correctly in Chromium/Chrome (the existing number fields do not as above) but is not working correctly in Firefox. Firefox shows the little up/down arrow box at the end of the field as you would expect with a number field but still allows non-number characters to be entered.

• This reply was modified 2 years ago by Rose. Reason: update

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 2 years ago by Rose.
• This reply was modified 2 years ago by Rose.
• This reply was modified 2 years ago by Rose.

That works thank you! Annoyingly I realised there was a code snippet that I forgot about that altered the archive titles and that was what was causing the code to not work. Oops. Really appreciate your help all the same! ??

I have the same issue. The first I noticed of it was the Dashboard activity box was a loooong list of action scheduler issues.

Next I noticed that Woocommerce Order page would not load WSOD. At first I thought it may be a problem with the Woocommerce v4.0 update so rolled back Woocommerce. But it made no difference.

I looked through the error logs and got this:

[14-Mar-2020 00:15:37 UTC] PHP Fatal error:  Uncaught Error: Call to undefined method ActionScheduler_DBLogger::unhook_stored_action() in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php:99
Stack trace:
#0 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(215): Action_Scheduler\Migration\Runner->migrate_actions(Array)
#1 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(150): ActionScheduler_HybridStore->migrate(Array)
#2 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Store.php(318): ActionScheduler_HybridStore->query_actions(Array)
#3 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/ActionScheduler_AsyncRequest_QueueRunner.php(82): ActionScheduler_Store->has_pending_actions_ in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php on line 99

I then disabled WPForms and everything was fine again. My solution currently has been to roll back to the previous version of WPForms.

I am also having this issue:

[14-Mar-2020 00:15:37 UTC] PHP Fatal error:  Uncaught Error: Call to undefined method ActionScheduler_DBLogger::unhook_stored_action() in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php:99
Stack trace:
#0 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(215): Action_Scheduler\Migration\Runner->migrate_actions(Array)
#1 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(150): ActionScheduler_HybridStore->migrate(Array)
#2 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Store.php(318): ActionScheduler_HybridStore->query_actions(Array)
#3 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/ActionScheduler_AsyncRequest_QueueRunner.php(82): ActionScheduler_Store->has_pending_actions_ in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php on line 99

I don’t think coorecting sql tables is a very accessible fix however. Should there not be a more graceful error recovery than WSOD for the above error? I’m assuming this is actually an issue with Woocommerce’s action scheduler but it’s completely unhelpful for an issue with it to take down a site due to WPForms throwing a critical error over it ??

I am also having the same issue. I think if multiple people are having the same issue, it would be much easier to post the solution here than get us all individually sending our “concern” via email. I’ve already spent time here looking for a solution, I don’t have time to then also have to send an email about a problem others have already stated is a problem ??

I’ve got the same problem. It previously worked fine and still works with existing embedded documents. But when trying to embed today, it just sits on “Loading”.

• This reply was modified 4 years, 10 months ago by Rose.

In case anyone else wants this, here is what I have to force updates on Region/State select:

function update_woocommerce_shipping_region_change(){
  if ( function_exists('is_checkout') && is_checkout() ) {
    ?>
    <script>
      window.addEventListener('load', function(){
        var el = document.getElementById("billing_state_field");
        el.className += ' update_totals_on_change'; 
      });
    </script>
    <?php 
  }
}
add_action('wp_print_footer_scripts', 'update_woocommerce_shipping_region_change');