www.wysiwygwebbuilder.com

I am having what appears to be a random problem when users are submitting a form which was created some time ago although it is not active in the winter months. Having contacted the host they thought it might be a problem with the database and reloaded it but it has not resolved the problem. I have made one change to my website which could have affected things but I cannot understand why some of my users are able to submit the Form and others are redirected to the Error Page.

Previously the user logged in and the Destination Page was one that contained the Form - this worked without any problem. I have now made the Destination Page one that directs the user to the Form if they have not previously completed it, but if they have completed the Form they are redirected to a different page. The mystery is that it works for some users but others are directed to the Error Page detailed in the Form Processing section of the Form.

Normally this Error Form would be generated if the Username or Password were entered incorrectly but are there any other circumstances that could cause this to happen. and why would it be with what appears to be random users?

The new intermediate page is a protected page and uses Sessions and a SQL Query to decide which page the user should be directed to.

As it appears to be random I am at a loss!

The software has thousands of options and millions of possible combinations, so it is difficult to say anything meaningful about this without seeing the PHP code of the page.
But I doubt that this is 'random'.

I agree Pablo, there must be a reason! Below is the PHP code of the page that the user is directed to once they have signed in. One user has told me that he was taken to the Error Page when he used his phone but managed to submit the Form on his iPad which makes it even more puzzling.

Can you see anything in the PHP code that might be affecting different users in different ways?

<?php
session_start();
if (!isset($_SESSION['username']))
{
$_SESSION['referrer'] = $_SERVER['REQUEST_URI'];
header('Location: ./access_denied.html');
exit;
}
if (isset($_SESSION['expires_by']))
{
$expires_by = intval($_SESSION['expires_by']);
if (time() < $expires_by)
{
$_SESSION['expires_by'] = time() + intval($_SESSION['expires_timeout']);
}
else
{
unset($_SESSION['username']);
unset($_SESSION['expires_by']);
unset($_SESSION['expires_timeout']);
$_SESSION['referrer'] = $_SERVER['REQUEST_URI'];
header('Location: ./access_denied.html');
exit;
}
}

$con=mysqli_connect("localhost","*************","************","l***********s");
// Check connection
if (mysqli_connect_errno($con))
{
echo "Failed to connect to MySQL: " . mysqli_connect_error();
}

$username = $_SESSION['fullname'];

$sql = "SELECT * FROM entries WHERE Name = '$username'";

if ($result=mysqli_query($con,$sql))
{
// Return the number of rows in result set
$rowcount=mysqli_num_rows($result); }
if ($rowcount >0)
{
header("Location: https://www.s*******s.org/entry_list.php");
}
else
{
header("Location: https://www.s*******s.org/entry_form.php");
}
?>

Based on the code, there can be two reasons why the user will be redirect to the error page:
- The username is not set, meaning the user has not logged in successfully.
- The session has expired

The PHP code is executed on the server so it should not matter which browser is used.
The only reason I can think of is if cookies are blocked, so the login state cannot be stored.

Thanks Pablo, that gives me something to work on as I was at a loss. If all else fails I will use a standard page with links to click as the intermediate stage!

Just to let you know that I have resolved this problem

To summarise, after a user logged into the website I used sessions to populate a form which was then submitted. Some users were successful whilst others were forwarded to the error page. This started happening about 4/5 weeks ago after having been successfully used in the past. There had been no changes in the form or the underlying database.

I looked for a common factor like type of device, operating system or browser but could not pin it down. The answer turned out to be that some of the email addresses in the user table of the database had acquired a space at the end - I think it may have been there sometime, when some details had been imported, but I cannot be sure. As you can appreciate, when looking at the table there was no visible indication of that extra space.

As the additional space did not affect the login, I had presumed that the email address was correct. I believe that a recent update of PHP Mailer has a more strict rule for email addresses that rejected the form, taking the affected users to the error page.

The breakthrough came when I realised that by adding ##error## in a text object on the error page I could narrow down the cause of the error. It was only when I read the help file that I realised this option was available - so thanks Pablo for documenting it.

Brian