PFMaBiSmAd

The php .msi installer version is apparently being written by someone who does not have a clue how to correctly design and build an application. Just about every post made when something about it does not work shows what it is doing makes no sense, nor does it tell you any information about what it is going to do, what it did, or what went wrong when it does not work. You should only use the php .zip package if you want to know that your php installation will be doing what you want it to.

If 20,013 different people wrote code to build a captcha system, they could have all written the post you just made above and there could be something different wrong in each of their programs. There's something wrong either in your code (what have you done to troubleshoot it to pin down at what point it works and at what point it does not) or on your server (sessions don't work at all, have you confirmed that any usage of session variables work or is it only something in your code?)

Yes, a TRUE value returned by mysqli_query() just means that the query was execuited - You must use mysqli_affected_rows() to find out the number of rows affected by the last INSERT, UPDATE, REPLACE or DELETE query.

There should be two sets of SMTP commands for each email. One set where your web server/php makes a connection to your mail server for the purpose of giving it the email to send and a second set where your mail server makes a connection to the recipient mail server to actually send the email to the final destination.

The first posted code does in fact work (assuming sessions are configured correctly on the server at all and that your file has not been saved in a format where something is being output to the browser that would prevent the session from working.) Are you learning php, developing php code, and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini to get php to display all the errors it detects? If there is a problem with how sessions are configured on the server or a problem with something about your file format that prevents sessions from working, there would be php errors that would help pinpoint the problem.

You can only do greater-than/less-than date comparisons when the date format has the fields making up the date ordered left to right, year, month, day. This is one reason why the mysql DATE and DATETIME formats use YYYY-MM-DD. You first step will be to store the date/times using a DATETIME data type and then you must put the dates you trying to compare against in the a YYYY-MM-DD format. You will also need to use the mysql DATE() function on your DATETIME values so that the comparison will just use the date part.

$connetion ain't spelled right in the line where you are assigning a value to it. You need to be developing and debugging php code in a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini to get php to help you. There would have been an undefined error at the first occurrence of $connection (spelled correctly) that would have alerted you to the fact that you had not assigned a value to a variable by that name and you could have backtracked to the line that is supposed to be assigning that value to discover the spelling error.

And that would be every time you move to a different server or someone updates your server and does not change the setting from the recommend default (OFF) value. In the time you have lost working on this problem, you could have used a programming editor's global file search/replace and gone through all your files and fixed the problem.

With php, mysql, and 2-3 online tools I found, 116463600 gives the following - php - Sep 9, 1973 23:00:00 mysql - 1973-09-09 23:00:00 http://www.epochconverter.com/ - Sun, 09 Sep 1973 23:00:00 GMT http://www.onlineconversion.com/unix_time.htm - Sun, 09 Sep 1973 23:00:00 GMT http://www.4webhelp.net/us/timestamp.php - Sunday, September 9th 1973, 23:00:00 (GMT) I would say that the web site you are using that is giving Sep. 10th is trying to do math to come up with the GMT value and is not taking into account a DST offset.

Writing, testing, and debugging code does not consist of you writing it, trying it, then posting only one relevant part of it on a help forum with the expectation that it is enough information for someone else to be able to find what is wrong with it. You must investigate what your code is doing when it executes on your server and with the data values you are putting into it and with the data that is in your database. No one but you can do that because it requires access to your server and your code and your data. Based on the symptom, your form either does not submit to the code you posted, it does not submit the data you think it does, or it does submit something but the code you did post is causing a redirect back to the from page. There are literally a dozen different things that could cause the symptom you described. Pin down at what step your code is doing what you expect and at what step it is not. Have you even echoed any of the $_POST variables to see if they have the expected values in them?

It's not a matter of reading your code. It is a matter of investigating what your code is doing when it executes on your server and with the data values you are putting into it and what data is in your database. No one but you can do that because it requires access to your server and your code on your server. Does the $query variable have values in it that match what is in your database? Is the query being executed with no mysql errors? What value does $result have after the query is executed? A FALSE or a result resource? What does echoing mysql_error() show?

According to the symptoms, user_login() is taking a path that causes the following line of code to be executed, implying that $numrows is not equal to 1 - return false; You would need to troubleshoot why your code is causing $numrows to have a value different than what you expect.

Ummm. Posting the output is nice, but seeing the source code that produces that output would directly allow someone to tell you why it is not being seen as php code. Best guess, you got caught using the lazy-way short open tag <? and need to change you code to use full opening <?php tags.

Does it literally display the string $login_error, or does it display a zero (which is what the FALSE value you return and assign to $login_error should display as.) Best guess is that index.php contains a error in the code and we would need to see the code responsible for displaying the value that is in index.php.

The only time we have seen that symptom is when the actual full code was different than what was posted. Is the code you posted exactly, line for line, nothing added, nothing removed, nothing changed from the actual code? If that is the full actual code, then it is likely that you have a value being assigned in the last iteration through the loop that is either empty or does not display anything when echoed. You see all the lines upto the last line being echoed, then you don't see a double echo of the last line because it was empty/non-displayable both when it was echoed in the loop and outside of the loop. Perhaps use var_dump() instead of echo (both in and outside the loop) to see exactly what data is present.

You need an exit; statement following your header() redirect to prevent the remainder of the code on the page from being execuited while the browser performs the redirect. For the posted code, all a hacker would need to do is ignore the header() redirect and he can still access the content on your page. You also need to be debugging your code on a system with error_reporting set to E_ALL and display_errors set to ON (preferably set in your master php.ini, but alternatevely set immediately after your first opening <?php tag) so that all php detected errors will be displayed. You likely have a problem with your session or with a header being sent. Are you sure the code that is setting the session variable is working?

From the mysql manual - SELECT Syntax

Either inc/config.php is doing something to stop code execution or there are no rows with an id = '2'

If the document root portion is the same in all the entries, you can just do a simple string replace to remove it before you output it in the html.

A TRUE value from the mail() function just means that there was a mail server and it accepted the email without returning an error to php. It does not mean that the mail was sent or that the mail server has any intention of sending it. A lot of mail servers have been configured to 'silently' accept emails that they have no intention of sending and are not giving back error messages because those message give hackers information about the mail server and also tend to confirm which email addresses are valid on the mail server and which as not. You should look into the MTA queues and logs to find out what is happening to the emails, if they are being discarded for some reason or if they are actually being send and the problem is occurring at the receiving mail server.

date() use the current time zone setting and any DST offsets (which is also dependent on if your DST database that php uses is up to date.) You should be using gmdate()

That would indicate that you are not applying the sha/sha1 function to the entered value. How would you expect your code to match two values when one value is a sha/sha1 value and one is not?

String data in a query must be enclosed in single-quotes and because the php parser needs help dealing with array variables in a string you need to put {} around array variables - $userdata = mysql_query("SELECT * FROM ILContractors WHERE username='{$_SESSION['u_name']}'") or die(mysql_error());

What does a phpinfo() statement show for the actual file_uploads setting? If the php.ini that you are changing is not the one that php is using or you did not stop and start your web server to get any change made to the php.ini to take effect, it does not really matter what the settings in the php.ini are.

Thanks for posting actual code showing how you were using it. The single-quotes are needed because the whole things is inside of a double-quoted string and you are using the mysql sha/sha1 function. If you are using the same processing when you test the entered password and it does not match it is highly likely that your column length is not sufficient to hold a sha/sha1 value.