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]
