Support

/**
 * Some folks who don't understand how PHP works try to load WordPress' PHPMailer by doing a require_once either on
 * the legacy shim (wp-includes/class-phpmailer.php), or on the modern class files
 * (wp-includes/PHPMailer/PHPMailer.php and wp-includes/PHPMailer/Exception.php) WITHOUT wrapping them in
 * class_exists() check.
 *
 * This is problematic for many reasons:
 * - If another plugin (or the core) has loaded the OTHER kind of files, the require_once check will try to load the
 *   same class twice, breaking the execution environment.
 * - If another plugin has registered an autoloader with a different copy of PHPMailer, like we do, and a second 3PD
 *   plugin tried to use PHPMailer using a class_exists() check without setting the second parameter to false, they
 *   will try to load WordPress' copy of PHPMailer under the same namespace, breaking the execution environment.
 *
 * The CORRECT solution is the standard class_exists() safety check which has been common knowledge since the early
 * 2000s:
 *
 * if (!class_exists(PHPMailer\PHPMailer\PHPMailer::class, false)) {
 *     require_once ABSPATH . WPINC . '/class-phpmailer.php';
 * }
 *
 * The require_once MUST NOT BE USED as a code safety feature against double definition attempt of a class or f
 * unction. Code safety requires using class_exists() and function_exists().
 *
 * Some folks, like ThemeCatcher (makers of QuForm), apparently are strangers to decades-old PHP code safety standards
 * and will publish support pages accusing us for their own shitty code without having the decency to contact us
 * first.
 *
 * We can't fix stupid, but we CAN and DO work around it. The simple way we chose to deal with this particular brand
 * of stupid is by including WordPress' PHPMailer class before including our own autoloader. This means that you now
 * have WordPress' files loading PHPMailer in the require_once/include_once cache, so even when morons like those
 * people rely on this mechanism for code safety they won't manage to shoot their feet. Since the PHPMailer class is
 * loaded, our Composer autoloader won't even try to load our copy of PHPMailer UNLESS we are running outside of
 * WordPress, i.e. our CLI backup script which is why we have a copy of PHPMailer to begin with.
 *
 * The code is backward- and forward-compatible:
 * - On WordPress <= 5.4 it loads wp-includes/class-phpmailer.php which registers the legacy, non-namespaced PHPMailer
 *   class. On these versions of WordPress, our Composer autoloader WILL load our newer, namespaced version of
 *   PHPMailer without breaking core WordPress or 3PD plugins.
 * - On WordPress >= 5.5 it loads wp-includes/class-phpmailer.php which registers the new, namespaced PHPMailer class.
 *   On those versions of WordPress, our Composer autoloader WILL NOT load our copy of PHPMailer. Plugins loading
 *   directly either this legacy shim, or the modern class files, will NOT break.
 * - On future WordPress versions removing the legacy shim, the modern class files are included. On those versions of
 *   WordPress, again, our Composer autoloader WILL NOT load our copy of PHPMailer. Plugins loading directly the
 *   legacy shim WILL fail because that (future) versions of WordPress does not include the shim. Plugins loading
 *   directly the modern class files WILL NOT break.
 */