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]
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]
This commit updates some Robo commands that were using `:` instead of
`-` to separete words for commands with more than two words resulting in
command not found errors. Simply replacing the aforementioned character
fixes the commands.
For two release related commands, it was also necessary to add the
`release` prefix.
[MAILPOET-3444]
This commit updates the SECURITY.md file to point security researchers
to HackerOne. I copied the SECURITY.md file from WooCommerce and made
some minor changes to reflect MailPoet specificities.
[MAILPOET-3410]
This commit moves the definition of the supported PHP versions from
RoboFile.php file to the PHPCS configuration file, ruleset.xml. This
should make it easier to configure PHPCS in other places like the IDE.
I also removed the constraint of the highest supported PHP version
(previously, it was hard-coded to 8.0) as I believe we support new PHP
versions as soon as they are released. With this change, we don't need to
remember to update testVersion tag whenever there is a new PHP version.
[MAILPOET-3439]
This commit adds PHPCS checks, using `./do qa:code-sniffer`, to the
pre-commit hook. To be able to do this, I had to modify `./do
qa:code-sniffer` to call PHPCS only once and change its signature to
accept an optional parameters with the list of files to check. If this
parameter is not passed, all files are checked.
As discussed with the rest of the team, before we were calling PHPCS
multiple times to be able to check for compatibility with different
versions of PHP, but as far as we can tell this is not necessary, and we
can check for compatibility with PHP >= 7.1 for all files.
As far as I know, changing the signature of RoboFile::qaCodeSniffer() is
not a problem and I updated the only instance where this method is
called.
[MAILPOET-3439]
