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'`
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 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]
This commit fixes a problem in the logic used to decide whether or not
the HelpScout chat should be available on the MailPoet admin pages. Before,
we were displaying the chat for plans that include premium support and access
to MSS. But we also have plans, like the Blogger plan, that include
premium support, and should see the chat, but don't include access to
MSS. Those plans were not seeing the chat.
This was happening because the code was checking just for
`mailpoet_api_key_state.data.support_tier == 'premium'`. The
mailpoet_api_key_state setting is added to the database based on the
response from the bridge.mailpoet.com/me endpoint. This endpoint returns
a 403 error for plans that don't include the sending service.
In this commit, to fix this problem, the code now checks for both
`mailpoet_api_key_state.data.support_tier == 'premium'` and
`premium_key_state.data.support_tier == 'premium'`. The former setting
is added to the database based on the response of the
bridge.mailpoet.com/premium endpoint. This endpoint works for plans that
have access to MailPoet Premium, but don't have access to MSS. We need to
check for both settings as we also have some plans that include the
sending service, but don't include MailPoet Premium.
[MAILPOET-3438]
