PHPMailer error handling

I’m using PHPMailer to send emails from a program, and when it works ok it is fine, but I need to be able to notify user that email was sent, or failed. Currently if it fails it just displays general PHP error message, and if ok just returns to page called by header statement.

The main program uses Bootstrap 4, and the email handler is pure PHP.

What the users want is an alert box to tell them the status,

The PHP code:

<?php

use PHPMailer\PHPMailer\PHPMailer;
//use PHPMailer\PHPMailer\Exception;

require 'inc/PHPMailer/Exception.php';
require 'inc/PHPMailer/PHPMailer.php';
require 'inc/PHPMailer/SMTP.php';

include 'inc/accsessconn.php';  // standard connection

$type = $_GET['etype'];

if ($type === "inv") {
    $htmlmess = $_POST['summernote1'];
    $class = $_POST['classname'];
    $from = $_POST['from'];
    $Email = $_POST['to_email'];
    $subject = $_POST['subject'];
    $wl_id = $_POST['id'];
    $BCC = $_POST['bcc'];
} elseif ($type === "del") {
    $htmlmess = $_POST['summernote2'];
    $class = "";
    $from = $_POST['from2'];
    $Email = $_POST['to_email2'];
    $subject = $_POST['subject2'];
    $wl_id = $_POST['id2'];
    $BCC = $_POST['bcc2'];
} elseif ($type === "adhoc") {
    $htmlmess = $_POST['summernote3'];
    $class = "";
    $from = $_POST['from3'];
    $Email = $_POST['to_email3'];
    $subject = $_POST['subject3'];
    $wl_id = $_POST['id3'];
    $BCC = $_POST['bcc3'];
}

$mail = new PHPMailer(TRUE);

try {
    $mail->From = $from;
    $mail->FromName = "Club Admin";
    $mail->addAddress($Email);
    $mail->addBCC($BCC);

    $mail->isHTML(true);
    $mail->Subject = $subject;
    $mail->Body = $htmlmess;
    $mail->Send();

    $errtext = "Email sent";

    if ($type == "inv") {
       // $comment = "Invitation to " . $class . " emailed on " . date("d/m/Y");
        $invite = $class . " offered " . date("d/m/Y");
        
        $sql = "UPDATE `waitlist` SET wl_class_offered=? where  wl_ID = ?";
        $stmt = $conn->prepare($sql);
        $stmt->bind_param('si', $invite, $wl_id);
        $stmt->execute();
        $stmt->close();
    }
} catch (phpmailerException $e) {
    $errtext = "Email NOT sent - please try again";
}
//echo '<script type="text/javascript">';
//echo ' alert($errtext)';
//echo '</script>';

header("location: wl_fulllist.php");

I was hoping the currently commented out section at end would display a javascript alert, but was just ignored.
Can anyone help?

Php’s output_buffering is probably on the php.ini. This will cause any output you tried to send to the browser to be discarded at the header() statement. Using php’s output_buffering should only be done when you want to buffer output and in general should be turned off, so that things like debugging output and output you want to occur isn’t discarded when you do a redirect.

The redirect you have upon successful completion of the post method form processing code should be to the exact same URL of the current page to cause a get request for that page. This will prevent the browser from trying to re-submit the form data if that page is reloaded or navigated away from and back to. To display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document. To allow navigation to any other page, provide navigation link(s.)

Your code should -

  1. Have the post method form processing code on the same page as the form. The code for any page should be laid out in this general order - initialization, post method form processing, get method business logic (get/produce data needed to display the page), html document.
  2. The post method form processing should detect if a post method form has been submitted before referencing any of the form data.
  3. You should keep the form data as a set in a php array variable, then operate on elements in this array variable throughout the rest of the code, i.e. don’t copy variables to other variables for nothing. This is just a waste of typing time.
  4. You should pass/accept a minimum of data through/from the form. Data submitted to your site can come from anywhere, not just your form, can be set to anything and cannot be trusted. By passing/accepting all the from, to, subject, and message data from the form, a spammer can send his emails through your email server and eventually get it banned by other email systems.
  5. You should trim the form data before validating it, mainly so that you can detect if all white-space characters where entered. After you do item #3 on this list, you can accomplish this with one single line of code.
  6. You should validate all input data before using it, storing user/validation errors in an array using the field name as the main array index.
  7. After all the validation logic, if the array holding the errors is empty, use the submitted form data.
  8. After using the form data, which can produce user/validation errors of its own (the email wasn’t sent or the invite was a duplicate), if there are no errors, you would perform the redirect to the exact same URL of the current page.
  9. If there are errors, the code will continue on to display the html document, display any error messages, re-display the form, populating the field values with any existing data so that the user doesn’t need to keep reentering/selecting data over and over.
  10. Any value you use/output in a html context (email, web page) should have htmlentities() applied to it to help prevent cross site scripting.

Changing settings in php.ini hasn’t helped!

The application is an internal use only one, and for the 3 forms that feed the above PHP all the data is extracted from databases which have had the data “cleansed” before being saved.

The header statement sends the user back to a page that list everyone on the waiting list to allow picking of a new, or same, person. - part of the specifications.

The include ‘inc/accsessconn.php’; line includes, as well as the standard database connection string, checking that the page was entered correctly, and that a session variable has been set that indicates who is using the system, and if set checks they are a vlid user. If not the program is exited. This call is included on all pages in the program.

I’ve managed a workround.

Changed a bit of the PHP code:

$mail = new PHPMailer();


    $mail->From = $from;
    $mail->FromName = ""Club Admin";
    $mail->addAddress($Email);
    $mail->addBCC($BCC);

    $mail->isHTML(true);
    $mail->Subject = $subject;
    $mail->Body = $htmlmess;
    if ($mail->Send()){

    $errtext = "wl_fulllist.php?prevemail=Email sent";

    if ($type == "inv") {
        //$comment = "Invitation to " . $class . " emailed on " . date("d/m/Y");
        $invite = $class . " offered " . date("d/m/Y");
        
        $sql = "UPDATE `waitlist` SET wl_class_offered=? where  wl_ID = ?";
        $stmt = $conn->prepare($sql);
        $stmt->bind_param('si', $invite, $wl_id);
        $stmt->execute();
        $stmt->close();
   }
} 
  else {
    $errtext = "wl_fulllist.php?prevemail=Email NOT sent - please try again";
}

header("location:$errtext");

and in the wl_fulllist.php have added code to check for the prevemail parameter, and if there to display the alert.

Not the most elegent solution, but it works.

Doesn’t matter. Due to browser based viruses, cross site scripting is still a possibility and the data that gets submitted to your internal use only web page can still be set to anything, even when visited by your logged in, trusted users.

A common way that forum software gets exploited is javascript gets included as part of posts or user profiles. When this javascript gets executed on web pages visited by logged in administrators, any action that an administrator on the site can perform can be executed. This is typically used to promote the user to become an administrator, where they simply login and grab a backup copy of the user database.

So, if your internal use only application isn’t coded to be secure, in all contexts, it still must deal with the possibility of executing code that isn’t part of the code you wrote, and must safely use any data submitted to it.

Sponsor our Newsletter | Privacy Policy | Terms of Service