WordPress automatically appends -css to the handle, so at the moment it's being output like this:
`<link rel='stylesheet' id='mailpoet_custom_fonts_css-css'`
The latest version has deprecated jQuery features removed.
It also has some breaking changes in HTML layout, so I had to fix styles to keep its design look.
This commit makes sure MailPoet tables are dropped when a site is
deleted in a multisite install. It uses the filter `wpmu_drop_tables`
to add the list of MailPoet tables to the list of tables that WP drops
whenever a site is deleted in a multisite install. $wpdb is used instead
of Doctrine entity manager as the latter is not affected by calls to
switch_to_blog() which is used in this case to switch from the main site
to the site being deleted.
This will only work if MailPoet is network active. If it is not,
MailPoet code is not executed inside the WP network admin panel,
and thus our filter is not added to wpmu_drop_tables, and MP tables
are not deleted.
[MAILPOET-3265]
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]
Some users were getting the PHP notice below when using the
user-switching (https://wordpress.org/plugins/user-switching/) plugin
to switch to a different user.
```
PHP Notice: get_cart was called incorrectly. Get cart should not be called before the wp_loaded action.
```
This notice is generated by WooCommerce when `WC_Cart::get_cart()` is
called before the `wp_loaded` action. user-switching calls a WooCommerce
method to empty the user session and the cart when switching users and
this happens before wp_loaded. MailPoet hooks into the
woocommerce_cart_emptied action
(c9ca134d30/lib/AutomaticEmails/WooCommerce/Events/AbandonedCart.php (L118))
to decide whether it should schedule or cancel an abandoned cart email.
When doing so, it calls WC_Cart::is_empty() which calls
WC_Cart::get_cart(). This is why the PHP notice is generated.
When the cart is emptied we don't need to check it again calling
WC_Cart::is_empty(). So, to get rid of the PHP notice, this commit adds an
extra condition to the if statement to only run WC_Cart::is_empty() if
the current action is not `woocommerce_cart_emptied`.
[MAILPOET-3374]
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]
