MailPoet syncs users from wp_users to wp_mailpoet_subscribers. The
problem is that WP stores first and last names in a longtext field and
MP uses a varchar(255) field. This was causing a fatal error when
synchronizing names over 255 characters. This commit fixes this problem
by using SUBSTRING() to make sure that the 255 characters limit is
enforced when adding values to the columns first_name and last_name of
the wp_mailpoet_subscribers table. This should get rid of the fatal
error and it shouldn't be a problem to most users as it is unlikely that
a real user has a first or last name that is longer than 255 characters.
[MAILPOET-3246]
This commit simply improves an integration test that I modified while
working on [MAILPOET-3421] to use an empty WC_Emails stub instead of
using stdClass.
This commit changes the WC action that MailPoet uses to hook into WC and
customize the footer and the header of WC e-mails. Before, MailPoet was
using the woommerce_init action. The problem with using this action to customize
the e-mails is that it runs on every request. Furthermore, since we were calling
WC->mailer() inside the callback, we were instantiating WC_Emails on
every single request (WooCommerce instantiate this class only when
needed).
Replacing woocommerce_init with woocommerce_email means that our code
will run only when needed (right after WooCommerce adds callbacks to the
actions woocommerce_email_header and woocommerce_email_footer) and that
we won't be unnecessarily instantiating WC_Emails ourselves. We get the
singleton instance of this class as a parameter.
[MAILPOET-3421]
The "Purchased In This Category" email was not working for variable
products. This was happening because MailPoet calls
WC_Product::get_category_ids() to get the list of WooCommerce
categories associated with a given product, but this method doesn't work
for product variations (see
https://github.com/woocommerce/woocommerce/issues/12942).
In this commit, I'm implementing a workaround. I changed the code to
check if the product is a product variation and, if so, get the
categories from the parent product instead of the product itself. But I
also plan to raise this issue with the WooCommerce team as, in my opinion,
it is odd that WC_Product::get_category_ids() doesn't work with product
variations and fails silently.
[MAILPOET-3416]
