phpMailer error after update

Hello,
I have the same problem. As far as I could check the error occurs only when I try to load the admin Status Report page.

Location: http://localhost/***/admin/reports/status
Referrer: http://localhost/***/admin/config/development/backup_migrate
Message
Error: Class 'PHPMailer\PHPMailer\PHPMailer' not found in Drupal\smtp\ConnectionTester\ConnectionTester->phpMailer() (line 125 of /Applications/MAMP/htdocs/***/modules/smtp/src/ConnectionTester/ConnectionTester.php)

Thanks in advance for your help.

How did you get the updated version of SMTP? Did you run composer update? It should have brought in the PHPMailer library.

That said, we may need to add some checks just in case people haven't done it that way.

This patch performs more sanity checking to validate you have the library installed.

I have exactly the same problem. After the update, the website is unavailable. I cannot update using Composer.

I always update the modules of my Drupal 8 sites with drush.

I can't apply the patch right now but maybe what I wrote could offer an hint.
Thanks for your help.

Hello,
same problem. I have updated using composer. I have applied the patch in #4 and in admin/reports/status page I get the error "SMTP: PHPMailer Library PHPMailer is Required for SMTP to function" yet the PHPMailer library is present in the Vendor directory, while the admin/config/system/smtp page says "SMTP module is INACTIVE" and it is not possible to turn it on. Hope this may help.

Valdes14:

yet the PHPMailer library is present in the Vendor directory, while the admin/config/system/smtp page says "SMTP module is
INACTIVE" and it is not possible to turn it on. Hope this may help.

Did you clear caches after doing this? You may also need to clear your APC cache because php caches the class locations.

For those not using composer, this is the best we can do. You'll need to manually download the library and put it in the vendor directory.

Can you provide the address from where to download the library and in which directory to put it? I have a problem with it and no combination attempt gives a positive solution.
I will be grateful for the hint.
Ps.
Easy to apply already in the new RC1 version after the upgrade? do i understand correctly ?

You'll want to use the phpmailer library 6.x+ as of today, the link below is what you want.
https://github.com/PHPMailer/PHPMailer/releases/tag/v6.1.5

As for where to put it, you need to put it in the vendor directory. That can vary depending on your hosting setup. Usually its in the docroot under vendor, but for some installations (like BLT) vendor will be outside the docroot. Its also sometimes within the core directory.

However, I will recommend figuring out how to make composer work for your setup. At some point it will become a requirement as drupal moves away from doing its own dependency checking.

@japerry: yes, cleared Drupal cache several times with no results. Not sure what you mean with clearing the APC cache. I'm running PHP as FastCGI and as far as I know there is no APC activated. I'm not a programmer so maybe I do not understand what to do.

Here are more details on the error:

Error: Class 'PHPMailer\PHPMailer\PHPMailer' not found in Drupal\smtp\ConnectionTester\ConnectionTester->phpMailer() (line 125 of /var/web/modules/smtp/src/ConnectionTester/ConnectionTester.php)

#0 /var/web/modules/smtp/src/ConnectionTester/ConnectionTester.php(49): Drupal\smtp\ConnectionTester\ConnectionTester->phpMailer()
#1 /var/web/modules/smtp/src/ConnectionTester/ConnectionTester.php(42): Drupal\smtp\ConnectionTester\ConnectionTester->testConnection()
#2 /var/web/modules/smtp/smtp.install(53): Drupal\smtp\ConnectionTester\ConnectionTester->__construct()
#3 [internal function]: smtp_requirements('runtime')
#4 /var/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(403): call_user_func_array('smtp_requiremen...', Array)
#5 /var/web/core/modules/system/src/SystemManager.php(111): Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array)
#6 /var/web/core/modules/system/src/Controller/SystemInfoController.php(49): Drupal\system\SystemManager->listRequirements()
#7 [internal function]: Drupal\system\Controller\SystemInfoController->status()
#8 /var/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#9 /var/web/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#10 /var/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#11 /var/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#12 /var/web/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#13 /var/web/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#14 /var/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /var/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/web/modules/httpbl/src/HttpblMiddleware.php(59): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\httpbl\HttpblMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/web/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#23 {main}

composer require drupal/smtp did the trick for me.

mmmhh... it seems that is tricky to install the phpmailer library manually.
(tried to install the module with all dependencies through composer but it needs too much memory and quits with errors)

when the phpmailer folder is in the vendor directory, do we need an entry to load phpmailer in the autoload.php file which is in the vendor directory?

tried everything, can't get it work...

@japerry: yes, cleared Drupal cache several times with no results. Not sure what you mean with clearing the APC cache. I'm running PHP as FastCGI and as far as I know there is no APC activated. I'm not a programmer so maybe I do not understand what to do.

You may have to try restarting PHP, that will clear APC if it exists. My guess is its trying to get at the old class location. But with composer it'll refresh the classes. W/o composer I'm not sure what will happen or where its being cached.

So is this now a dependency? (after update to 8.x-1.0-rc1)

If yes, it should be more clearly stated.

Also, please include an option to deactivate the below hook in in smtp.install in smtp config and have it deactivated be default.

/**
* Implements hook_requirements().
*/
function smtp_requirements(string $phase) {
$return = [];
// If the phase is not runtime, ConnectionTester might be unavailable.
if ($phase == 'runtime') {
$tester = new ConnectionTester();
$return = $tester->hookRequirements($phase);
}
return $return;
}

Because this is affecting live sites: the entire /admin/config section goes blank.

P.S. people forget that some Drupal installations are on complex server configurations that do not allow to use Composer.

Alternatively, please provide a Ludwig json file in the next update.

The solution

Modules provide a ludwig.json file which lists all of their required libraries:

EXAMPLE:

{
"require": {
"commerceguys/enum": {
"version" : "v1.0",
"url": "https://github.com/commerceguys/enum/archive/v1.0.zip"
},
"commerceguys/addressing": {
"version" : "v1.0.0-beta3",
"url": "https://github.com/commerceguys/addressing/archive/v1.0.0-beta3.zip"
}
}
}

THANK YOU FROM THE THOUSANDS OF DRUPAL 8 SMTP USERS WITH LIVE SITES RELYING ON THIS GREAT MODULE!

Please place ludwig.json in smtp/

{
"require": {
"PHPMailer/PHPMailer": {
"version": "v5.2.28",
"url": "https://github.com/PHPMailer/PHPMailer/archive/v5.2.28.zip"
}
}
}

will place the library in modules/smtp/lib/PHPMailer-PHPMailer/v5.2.28

and Ludwig should do the rest. (Verify at /admin/reports/packages)

@japerry: now it works. Originally I updated the SMTP module with composer locally with no errors, then uploaded on live server the updated SMTP module and the PHPMailer directory onto vendor directory which did not work. Now I have uploaded on live server the whole vendor directory from local and it works. So, apparently something else is being changed in the vendor directory. Hope this can help.

@rmcom:

Thank you for the Ludwig instructions. I cannot get it to work though. The Ludwig part works (the missing dependency is detected, and there is a warning in admin/reports/packages). However, when I manually place the downloaded library in the indicated spot, it is not detected.

Could you please confirm the location of the 'class.phpmailer.php' file? Mine currently is at

modules/smtp/lib/PHPMailer-PHPMailer/v5.2.28/class.phpmailer.php

I have tried other locations, but unfortunately no success yet.

Thank you in advance,
Mark.

@cpdp: You should be using PHPMailer version 6.x+, but that location doesn't seem right to me. Not sure if Ludwig puts things in the vendor directory, but that is where 3rd party libraries should be in Drupal 8.

@rmcom, personally I don't think Ludwig should be a thing people are using. Currently it is not d9 compatible, and if it goes away or has issues in the future, problems that it causes could become a problem people report in this queue because they didn't know better.. and causes an edge case that the maintainers are not testing for. However you are right that the requirements in the install file should NOT be doing what they currently do. That is in the patch above.

I've pushed up the fix to .install so at least you don't get a WSOD. It should give you better information regarding the missing class now, and if you're not using composer, you'll have to do some manual placement of the library in the vendor directory and refresh the autoloader. But to be clear, non composer installs are not supported.

@japerry Thank you for your prompt reply.

While I recognize that the prerequisites for this module are yours to define and decide, with almost 150k installs under your belt I also believe that some thought should be given to a somewhat continuous support of your userbase.

The introduction of a Composer-dependent component excludes, I believe, a great number of current users from upgrading to the next supported version, which is also not a major version switch, but a transition from a beta to an rc1. Those users very possibly have no option of using Composer b/c of their hosting provider, b/c of their technical skill, or because of lack of opportunity or time to learn another skill.

The result is unfortunately that thousands of site owners now suddenly have no option of using email, unless they switch hosting provider, invest a considerable amount of resources and time, or transfer their sites over to another email module, which is rather slim pickings at the moment.

You could say that none of these consequences are your responsibility. You could also say that everyone should use Composer and not Ludwig, or that this kind of thing should be expected of open source software. I would have no other choice than to admit that you are correct.

Respectfully,
Mark.

@cpdp: I have the same problem but am unable to find why Ludwig does not find the 'class.phpmailer.php' file which I have in the same location.

I will try alternatives and will get back to you here.

@japerry: Thank you so much for this fundamental and essential module. We would be unable to use Drupal without it and would have to choose an alternative. @cpdp very eloquently laid out the problem. There has been a push to force the Drupal community to use Composer, but after trying many different ways, Composer is not possible with our server setup and infrastructure. The risk for Drupal is to lose a large part of its user base. We love Drupal, want to keep using it, and beg you to consider this issue.

We are seeing the same problem. I was just about to try Ludwig, and will report my findings, but please add my thanks to @japerry, and my voice to those who are troubled at being given composer as an ONLY option.

Ludwig worked for me! Thank you again, @japerry!

@justkristin : it is great that Ludwig worked for you. Would you mind sharing the steps you went through?

I suggested the Ludwig solution a bit further up, but both, @cpdp and I were unable to get it to work. Your insights may help us.

FINAL UPDATE, I SWEAR: Looks like the module didn't like dealing with what the webform module had assigned as "default email address" for sender, so I put in an explicit one, and now all is fine! Woohoo!

-------------------------------

UPDATE: Sorry, all. While the form I am using seemed to come up without incident, I am now getting an "invalid reply-to" error. Damn. Back to the drawing board.
PHPMailer\PHPMailer\Exception: Invalid address: (Reply-To): in PHPMailer\PHPMailer\PHPMailer->addOrEnqueueAnAddress() (line 1079 of /code/modules/smtp/lib/PHPMailer-PHPMailer/v6.1.5/src/PHPMailer.php).

-------------------------------

Lovely people, I used the suggested ludwig.json method mentioned in Comment#20 but changed it to version 6.x, as the 5.x version in the code there still didn't work with the latest version of SMTP.

I added the ludwig.json file, edited, and then ran ludwig-download via drush. All seems well.

Shoot, I forgot! I also changed to the dev version of this module, as a fix was added there for the 6.x version of the library, I believe. https://www.drupal.org/project/smtp/releases/8.x-1.x-dev

I'm with #26, requiring composer makes what was previously super easy into something exponentially more difficult. I'm not having any luck with Ludwig either - I tried following the instructions from #31 but nothing is showing up at /admin/reports/packages.

UPDATE:
I managed to get things working using the Ludwig module and manual upload of PHPMailer library (I previously had capitalization incorrect on directory names to PHPMailer). In case it helps anyone, here's the specific steps I followed:

1. Install Ludwig module: https://www.drupal.org/project/ludwig and activate
2. Download latest dev version of SMTP module: https://www.drupal.org/project/smtp/releases/8.x-1.x-dev
3. Add ludwig.json file to root directory of dev version of SMTP module (file is attached here)
4. Download PHPMailer library from here: https://github.com/PHPMailer/PHPMailer/archive/v6.1.5.zip
5. Create "lib" directory in SMTP module and add PHPMailer library so ultimately PHPMailer.php is located here: /code/modules/smtp/lib/phpmailer-phpmailer/v6.1.5/src/PHPMailer.php - note that capitalization on the directories may cause problems on some servers - it should be exactly as above.
6. Run /update.php on your Drupal site
7. Clear site cache and you should be in business

Hope this helps.

A big thank you to all who made this work again

@japerry for pushing rc2 and incorporating the feedback received

@cpdp for the follow-up

@justkristin for encouragements regarding the Ludwig solution

@Beezer75 for fixing my mistake by referencing PHPMailer v5.2.28 instead of v6.* (v6.1.5) and the new ludwig.json file

As for the checklist - update:

2. Download latest dev version of SMTP module: works now with v8.x-1.0-rc2 thanks to @japerry

6. Run /update.php on your Drupal site was not necessary on my instances (no database updated)

7. Clear site cache and you should be in business very important: SMTP config page won't let you activate the module without this step

@japerry re #24 : The WSoD problem is removed (thank you!) and I understand completely that using Ludwig is not satisfactory on several levels, but it would still be great if you could incorporate a ludwig.json file with the PHPMailer version that you require to be used.

That would be a big help for us mere mortals who can't use Composer for a variety of (technical) reasons.

Thank you!

Hi to all! I'm working on D8.8.5, smtp module rc2.

@rmcom: i update from rc1 to rc2, cleared cache, but still error remains.
@Beezer75: follow your post #34, and solved the library missing message in status report.

Hope it helps
ciao

Many thanks to all, especially @Beezer75 and @mcom for the clear instructions. It worked for me, and I am also much relieved to know I am not the only mere mortal out there who is not currently using Composer.

WARNING! Updating smtp to 8.x-1.0-rc2 will prevent all content types using core content moderation from being edited!

Error: Class 'PHPMailer\PHPMailer\PHPMailer' not found in Drupal\smtp\Plugin\Mail\SMTPMailSystem->mail() (line 157 of /srv/bindings/8899fbbad0154c6c8a10ae8e9a728f2b/code/modules/smtp/src/Plugin/Mail/SMTPMailSystem.php)

Sadly, I had no choice but to rollback to version 8.x-1.0-beta7 which contains modules/smtp/src/PHPMailer/

-----

Drush directions to rollback to 8.x-1.0-beta7

Step 1
$ drush dl smtp --select

Step 2 - Choose one of the available releases for smtp:
[4] 8.x-1.0-beta7

Step 3 - Do you want to overwrite it? (y/n):
y

-----

@japerry We have 29 production sites that cannot use composer or ludwig. We have over 100 content editors using a very complex moderation process which depends on sending email. I ask you to reconsider making composer a requirement.

Changing to NW: specifically, 'smtp_on' doesn't actually turn off the SMTP plugin. So if you're missing the PHPMailer library, it will still break things. It'd be better to post a message in dblog saying "Mail could not be sent, PHPMailer library is missing."

Consideration of using ludwig is here #3137440: SMTP - Ludwig integration. What won't change is bringing the library back into the module. Per Drupal.org policy, 3rd party libraries are not supposed to be contained within modules. (https://www.drupal.org/node/422996)

Using composer is the supported and highly encouraged way to use this and many other modules that integrate 3rd party libraries. As we go through the Drupal 9 lifecycle, its quite possible composer will become required in core, so for those who aren't using it now, here is your notice to update/fix/change/re-evaluate your process so you can build sites this way.

@japerry I totally understand what you are saying and I hope that composer is required in D9 (this will help with consistency). Our sites were built using the Pantheon upstream and at that time, composer was only used in the frontend. Later, composer was required in core but Pantheon did not and does not offer an upgrade path. We are still under contract so we can't just move to another platform at the moment. I will be moving forward to use composer with D9.

While in time I will migrate our sites to Composer-based, for now we have decided to migrate to another mail module that still does support Composer-less use, and move to Composer-based in our own timeframe.

I have found the migration to https://www.drupal.org/project/phpmailer_smtp stupefyingly painless. As stated on this page, the module supports Ludwig installations through the -dev versions of the module, but also manual installations of the PHPMailer library.

For those of us wanting to switch, I have left migration instructions in the issue queue of that module; it did not seem appropriate to leave them here.

Regards,
Mark.

Just a note, I did add Ludwig support. We found a few more cases where this is how people are pushing updates.. and while everything above stands, we can address problems with Ludwig later. No point in causing unnecessary pain for folks when it doesn't cause issues for composer users.
See #3137440: SMTP - Ludwig integration

Also, it'd be great for people to test the patch here if you're still having issues with the RC: #3135595: SmtpConnect() error but email sends successfully Continuing work in that thread and closing this one.

composer require drupal/smtp worked for me. Thanks #14.

I've reverted to beta7 as this worked for me, yet another module gone down the composer route - no objections to composer itself (works fine on other PHP projects) but seems to be very poorly implemented for Drupal.

+1 Thanks #14
composer require drupal/smtp
also worked for me.

#14 did the trick.
Thanks¡

I am also having an issue with this with our site on Pantheon, built with composer. composer require drupal/smtp did not solve the issue, and even though the phpmailer library was successfully installed by composer, the module could not find the library and was powered off:

SMTP module is INACTIVE.
Warning messageDisabled fields are overridden in site-specific configuration file.

SMTP cannot be turned on because the PHPMailer library is missing.

This error appeared in the dblogs:

Path: /admin/config/system/smtp. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The 'administer smtp module' permission is required. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 117 of /srv/bindings/9c94ea1cf384429abac040da534480dd/code/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

I saw this patch, but it's 4 years old:
https://www.drupal.org/project/smtp/issues/2792495

Any suggestions?

hmm well the permission definitely looks correct in the code. We only use it in 2 spots -- turning debug on and access to the smtp settings page. You should be able to get to the settings page to see about turning on/off the module. But I'd submit your results in a different issue as this one is pretty much done now.

We found a different error after updating from 8.x-1.0-beta7 to 8.x-1.0-rc1 - see #3156075: Update hooks removed