Rafael

Your theme contains copies of WooCommerce template files which are neccessary for generating your WooCommerce-related pages. This message means that some of these copies are out-of-date and must be updated to work with the current version.

Here is a quick guide on updating those templates:
https://docs.woocommerce.com/document/fix-outdated-templates-woocommerce/

Note that any changes made to the old templates (e.g. tweaks for your theme) must be redone in the new templates.

Missing for me too with Plugin version 3.3.4 and WordPress 5.2.2.

Hello Hannah,

I have already updated to WooCommerce 3.6.2, which only increased the frequency in which the setup wizard appears.

I have mirrored the site to our staging area – and now I can’t even quit the setup wizard. Whenever I click on the “not now” button, expecting to be returned to the admin dashboard, I get force-redirected back to the setup wizard immediately.

When I tried to temporarily disable WooCommerce via FTP, I couldn’t access either the front- or backend of the site (blank pages, with Fatal errors regarding missing WC() functions in the debug logs), so that isn’t really an option either.

Regards, Rafael

The 3.5.4 update never finished database upgrading, but the recent 3.6.1 update was able to update the database to its own new structure.

For some reason, re-entering the exact same authentication token (I was just reaching for straws) fixed the issue.

I hope this helps someone with the same issue as me.

In today’s logs, I found these two lines:

[29-Jan-2019 06:54:54 UTC] PHP Warning:  array_merge(): Argument #1 is not an array in [...]/wp-content/plugins/intergeo-maps/vendor/codeinwp/themeisle-sdk/class-themeisle-sdk-widget-dashboard-blog.php on line 375
[29-Jan-2019 06:54:54 UTC] PHP Warning:  Invalid argument supplied for foreach() in [...]/wp-content/plugins/intergeo-maps/vendor/codeinwp/themeisle-sdk/class-themeisle-sdk-widget-dashboard-blog.php on line 376

Maybe this is related to the issue.

I managed to manually fix the table by adding an index to mail_id first:

ALTER TABLE 'wp_wpml_mails' ADD INDEX('mail_id');

Then I was able to add the Auto_Increment attribute:

ALTER TABLE 'wp_wpml_mails' CHANGE 'mail_id' 'mail_id' INT(11) NOT NULL AUTO_INCREMENT;

Now the table accepts the requests again and new mails are properly logged.

Thank you for pointing me in the right direction!

Regards,
Rafael

I am attempting to manually add the Auto_Increment attribute to the column, it looks good when I press SQL preview:

ALTER TABLE 'wp_wpml_mails' CHANGE 'mail_id' 'mail_id' INT(11) NOT NULL AUTO_INCREMENT;

But when I try to save the changes, I get the following error:

#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

No other column has the Auto_Increment attribute. So do I have to set the mail_id column as a key as well? And where do I do that?

Sorry to ask all these questions, I am a beginner at best when it comes to databases…

I took a look at the wp_wpml_mails table in phpMyAdmin. The mail_id column has the type int(11). Is that correct?

By the way, the last value for mail_id has been 4727 and was entered around two days ago.

While I did a database migration when I mirrored the site to our staging environment yesterday, I did so by hand (exporting an .sql file, deleting all existing tables in the staging database and importing the previously exported file). The error however occurs on both versions of the site (I generated the above mentioned error log on the live site).

We’ve been using WP Mail Logging alongside WordPress Multilingual since December 2017; there haven’t been any compatibility issues so far.

Hello @voltronik,

I have written a custom notification that successfully hooks into the WooCommerce User creation process. Here’s some anonymized code I used:

add_action( 'woocommerce_created_customer', 'custom_new_user_mail', 90)

function custom_new_user_mail( $user_id ) {
	$regular_data = get_userdata( $user_id );					// Get userdata for $user_id (as an object)
	$meta = get_user_meta( $user_id );							// Get user metadata for $user_id (as an array)
	$meta = array_filter( array_map( function( $a ) {			// Filter out empty metadata
				return $a[0];
			}, $meta ) );
	if ( $meta['some_custom_meta_value'] == "yes" ) { /* code to build and send a custom mail */ }
}

I hope this is helpful to you in some way.

Regards,
Rafael

• This reply was modified 6 years, 4 months ago by Rafael.
• This reply was modified 6 years, 4 months ago by Rafael.

I have deactivated it with the option to delete all of its database tables and did a clean reinstall of Wordfence. The issue persists… I have no idea where it gets that URL from.

Then again, it’s nothing plugin- or site-breaking. It’s a mere inconvenience.

Hello @wfsupport,

thank you for your answer.

However, upon checking my WordPress general settings, I saw that the site URL is configured correctly there.

I also took a look at the corresponding wp-config.php file; the site url is defined there correctly as well.

Regards,
Rafael

Hello @voltronik,

no pressure. I just wanted to provide you with more detailed information on our setup to help you debug the issue. Thank you for your hard work.

Regards,
Rafael

Hello @voltronik,

thank you for your update.

User registration on ur site is done via a custom WooCommerce login/register page that has additional fields (e.g. address, company name) which get saved to the User Metadata table. Those are added through our theme’s function.php which also handles validation and passes the additional values to the database via update_user_meta() functions.

Before the 1.7 update of BNFW some default user infos were already missing in the notifications (like the tags for username and first and last name, which are stored in the regular User table), but others (e.g. user email) were properly included in the notification mails (which also were triggered properly back then).

Regards,
Rafael

• This reply was modified 6 years, 5 months ago by Rafael.

Hello @vmarko,

I did some testing on an internal copy of the site.

As it turns out, W3C makes the site-breaking edit to the .htaccess file any time I hit the “Purge All Caches” button in the admin bar of a translated page (and thus access an URL with the parameter “&lang=en&w3tc_flush_all”) resulting in “500” errors for all pages until I manually restore the .htaccess file to its prior state.

Regards,
Rafael

• This reply was modified 6 years, 5 months ago by Rafael.