Jump to content

Test Email not working


djaychela

Recommended Posts

I've got an existing site which I've taken the maintenance on for a client.  It's running 6.2.2, and I've changed the email address (from) in the mail settings (I'm using PHP mail, which has worked fine in the past).  However, when I click 'test', I get the following:

 

Quote

 

Testing

Invalid address: (addAnAddress to):

 

I can't see where to set a 'to' address - there's no option on the page I'm on - I've attached a screenshot.

Any pointers in the right direction will be appreciated.

email-options.PNG

test-email-not-working.PNG

Link to comment
Share on other sites

Welcome djaychela! Glad to see you made it to the forums.

Please know that the Test function only reliably tests the SMTP method of sending emails. Using PHP mail() will be attempted but may not return any valid results. Even so, the Sender's Email Address will be used.

It is strange, however, that the Test button says (After Save). CC62+ no longer requires the form data be saved to make the test. A javascript function reads the text entry field's values and makes an ajax request.

Did this installation get upgraded recently? If so, please look in CubeCart's main folder and count how many folders start with admin.

There may be a mismatch between what the admin code sent to the core classes.

 

Link to comment
Share on other sites

Hi

Thanks for the quick reply.  Yes, it was upgraded recently - it was stuck on 6.1.1 for a long time and needed to be manually updated (as the upgrade feature wouldn't work in 6.1.1).  I've just logged in via FTP, and have two admin folders - one is plain admin, the other has admin_(random characters).

Does one need to go?

Link to comment
Share on other sites

Same issue?

Look at these files:

/classes/ajax.class.php and in the admin folder, /skins/default/templates/settings.index.php.

In ajax.class.php, near line 316, will look like:

$test_mailer->AddAddress($_GET['email_address']);

or near line 246, will look like:

$test_mailer->AddAddress($GLOBALS['config']->get('config', 'email_address'));


Then, in the template file, near line 413, will look like:

<button type="button" class="button tiny" id="smtp_test" onclick="previewEmailSettings()">{$LANG.common.test}</button></span></div>

or near line 370, will look like:

<button type="button" class="button tiny" id="smtp_test" onclick="$.colorbox({ href:'{$STORE_URL}/{$SKIN_VARS.admin_file}?_g=xml&amp;function=SMTPTest' })">{$LANG.common.test} ({$LANG.common.after_save})</button>

The first statements of each pair are for CC621 (CC622 will not be any different, but line numbers may be off a bit).

The second statements of each pair are for CC6114.

If the admin skin template is of the version NOT being CC622, then check the other admin folder.

If there are no errors preparing the mailer, a test email will be sent even when using PHP mail() function. It is the diagnostic results that may be lacking.

Link to comment
Share on other sites

Thanks - the plain admin folder is the 622 one..which isn't the one pointed to in the config file.

But every time I change includes/global.inc.php to point to the right one, and upload it, it's changed back to the original setting - I've tried this a number of times, editing it via filezilla, or by downloading it, editing it and re-uploading it.  Any clues why this is happening

Link to comment
Share on other sites

Check to see if that file's permissions have it set to read-only. The editing and FTP programs may not realize this and fail to overwrite the file -- although I find that absurd.

Then, have a conversation with the hosting provider to determine if there is some sort of anti-tampering, auto-restore utility preventing changed files.

Link to comment
Share on other sites

OK, sorted the file issue - the permissions get changed when you log in (to 444 from 644), and I'd coincided with the shop's owner logging in, hence changing the permissions between me opening the file in FZ and making a change.

HOWEVER.... when I change to the 'right' admin folder in includes/global.inc.php ...  I get warnings on the admin login page of a CSRF error... and it won't let me in.  I've tried clearing cookies, refresh, all the things I've seen so far for a CSRF error (which was apparently more common previously with CC), but nothing has worked - I've put it back to pointing to the old admin section for the time being... but CC's not winning any friends for upgrade smoothness here, that's for sure.

Link to comment
Share on other sites

Please be sure to fully logout of any admin session.

Then try to manually empty (FTP or hosting account control panel) the /cache/ folder (except the .htaccess file found there, while the /skin/ folder will get rebuilt).

And also delete the cookies pointing to this site after emptying the /cache/ folder.

Link to comment
Share on other sites

Using your browser's diagnostic features, view the Network panel when clicking the Log In button.

The Network listing will show a POST request, where you can view what was POSTed.

Be sure that the browser is POSTing a form element named "token" with a 32-character value.

If so, consult with your hostiing provider to determine if they have implemented a "mod_security"-type application on the web server. It may be the case that the 32-character hash is triggering a security rule and stripping off that key/value.

Link to comment
Share on other sites

Can't see that in the response that I'm looking at in Firefox.

 

TBH I've spent way too long on this - hours today, and thanks very much for your help.  But I can't believe what a mess this seems to be - the upgrade was a shambles to get sorted (because of the bug in 6.1.1, and now this - that the files don't even have a version number in them seems bizarre.  It's next to impossible to see what files are from what version, and as a result I'm just going to swap back to using the wrong (but functional) admin section - I've spent hours working on this (none of which I'll get anything for as it's massively disproportionate to the improvement in the site), and I still have to try to work out why the PayPal module no longer works properly - takes payment but returns an unknown error, leaving the order in limbo.

 

Once again, thanks hugely for your advice and help - it's been much appreciated.

Link to comment
Share on other sites

11 hours ago, djaychela said:

when I change to the 'right' admin folder in includes/global.inc.php ...  I get warnings on the admin login page of a CSRF error... and it won't let me in.  I've tried clearing cookies, refresh, all the things I've seen so far for a CSRF error (which was apparently more common previously with CC), but nothing has worked - I've put it back to pointing to the old admin section for the time being... but CC's not winning any friends for upgrade smoothness here, that's for sure.

CubeCart has had issues in the past with using the built in upgrade utility and as as you were trying to upgrade from an old version, these issues will definitely have been in your version so an auto upgrade will 100% have failed.  These are supposed to be fixed in the current version although I never use that facility and always do a manual upgrade which is what you are going to need to do.  The problems you are getting are due a mismatch of the admin.php file and admin directory.  To fix

1) Find out what these are supposed to be called in the includes/global.inc.php file

2) In your local version of 6.2.2, rename the admin.php file and the /admin directory to the values from point 1

3) Delete any admin.php and admin_xxxxxx.php files and any /admin or /admin_yyyyyy directories that exist on the site

4) Upload the /setup and your renamed /admin_yyyyyy directory and admin_xxxxxx.php file

5) In a browser, go to https://your-domain.com/setup and ensure the database upgrade is completed

That will fix the version mismatch and therefore the CSRF - 6.2.2 is very much worth the effort over 6.1.1

Ian

On 9/5/2018 at 8:59 AM, djaychela said:

I'm using PHP mail, which has worked fine in the past.  However, when I click 'test', I get the following:

In addition, as Brian mentioned, you cannot do the test when using PHP Mail and this doesnt reliably report sending / issues.  However, you should always be using Authenticated SMTP anyway to send store emails - much more reliable and far better chance of the emails being delivered without being put into spam 

Link to comment
Share on other sites

Hi

Thanks for the post - I will have a go later - I'll back up the entire site and follow your instructions.  To get to the current version (reported as 6.22 in the admin section) I did do a manual upgrade, but without the extra steps.

I'll look into the mail setup as well - as it was working fine with the current setup I didn't want to change what was there...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...