PFMaBiSmAd

This symptom is typical of redirecting around between url's that have and don't have the www. on them, which causes the session to no longer match the variation of the domain name you happen to be on. You are likely reaching the login form through a link that either does or does not have the www. in it. When the form is submitted it goes to your log in page with the same variation of the domain. When your log in code successfully authenticates the user, you redirect to - http://mydomain.com/download/index.php?un=$name (probably without the www. in the url.) The session check in your code at download/index.php doesn't work and it redirects back to the log in form. However, now the url you are using on the log in form will have the same variation of the url (probably without the www. in it) and the session will carry through to all pages. If this sounds like what is occuring, there are two ways of correcting this - 1) You can set the session.cookie_domain to be '.yourdomain.com' (with the leading dot) so that the session id cookie will match all variations of your domain. You must do this before every session_start statement (putting it into a file that you are including on every page before the session_start is generally the surest and most portable solution.) 2) You can set up a .htaccess redirect to send all non-www. requests to the corresponding www. variation of your domain.

2012-04-17 14:26:35 is greater than "2011-04-19 00:00:00"

The sites you have heard about where masses of passwords have been gotten and released, were the result of either storing the passwords as plain text, encrypting the password and someone gained sufficient access to the code to get the encryption key, or more simply they added code at the point where the raw passwords where being processed and they simply scraped/logged the actual passwords as they were being processed.

The session.gc_maxlifetime isn't for timing out sessions, it's for cleaning up old session data files. You shouldn't depend on the underlying operation of the session garbage collection to do anything your application depends on. Session garbage collection RANDOMLY runs, so old session data files can randomly exist long after they are older than the session.gc_maxlifetime value. Also, the last referenced time of the session data file is updated upon the session start, so if your session data file is older than the session.gc_maxlifetime value, but the file hasn't been delete yet when you access a page the has a session_start, your session will continue. If you want some action to occur after a specific period of inactivity, you need to store a timestamp or datetime value and test on each page request if that timestamp or datatime value is farther in the past than you want and perform the desired action in your code.

Your 'signOff' form submit button isn't even inside a form. Put it inside of the correct form and your page will probably work in all browsers.

To get help with your form page, you need to post all the code needed to reproduce your form page. You likely have some invalid html that some browsers ignore, but for which IE correctly fails. Have you validated the resulting html output page at http://validator.w3.org ?

Because you are using the image as the link to open each message, what do you want to use as the link when there is more than one message from that user? You must still have a separate link for each message. Sample code that would 'remember' the image name and only output one image each time the image name changes - <?php $query = "your query statement goes here..."; $result = mysql_query($query); $last_image = null; // remember the last image displayed. initialize to a value that will never exist in the data. while($row = mysql_fetch_assoc($result)){ // detect if the image changed (or is the first one) if($last_image != $row['your_image_field_name']){ // output the image echo "<img src='{$row['your_image_field_name']}' alt=''>"; $last_image = $row['your_image_field_name']; // remember the image name } // output the message link for each image here... } ?>

If you actually are trying to execute a query that references two different database servers, it won't work. The query runs on the database server who's connection you are using and it can only reference databases and tables that server can read. If you are not getting an error, it is likely that you have a database and tables with those names on the server where you are executing that query, but no matching data.

Because you are not specifying the link identifier in the mysql_query() statement, it is using the last connection that was created (remote.) You would need to use the following to use the local database server to run that query - mysql_query($sql,$link) or die(mysql_error());

You need to set php's error_reporting to E_ALL (or ever better a -1) and display_errors to ON in your master php.ini to get php to help you by reporting and displaying all the errors it detects. Stop and start your web server to get any change made to the master php.ini to take effect. Your $name, $email and $text variables inside the storeData() function/method are local to that function only. You would be getting undefined error messages for each of them. If your intent is to use the class variables by those same names, you would need to use $this->name, $this->email, and $this->text.

Define: 'but nothing happens in IE' What does it do? Stay on the form page or it goes to the saveMom.php and nothing is inserted?

In fact, it looks to me like your code is sorting by the username, categories, then the datetime values within each group of username/categories.

Edit: Basically the same as what jesirose states above ^^^ Php doesn't have anything to do with this. Php simply outputs what you tell it to do. It's up to the browser to render the html that it is sent. The <br /> tags are inside the table tags but outside of any <tr></tr> tags.

The display you have posted is the result of more code that you have shown. If this isn't due to a bug in mysql, then it's likely something your code on the page is doing. If you have a whole page that doesn't work as expected, you would need to post all the code needed to reproduce that page in order to get help with the problem. When you run the query directly in your favorite database management tool, do you get the expected results?

Its - __construct() with two under-scores and the word construct

Remove all the - echo "<br />"; statements that are within the <table></table>.

Since you didn't actually post your query and your code, its not real clear what the problem is, but I'll guess you need to use an alias name in your query for the decrypted value so that you can reference the alias name when you fetch the row of data from the result set.

In each row fetched - $row[0] is the `id` $row[1] is the `category` $row[2] is the `user` $row[3] is the `description` $row[4] is the `datetime` $row[5] is the `userinfo`

Where is the $itemCode value in the form's value='$ItemCode' attribute coming from?

You would typically use a database table as a queue to hold a list of email address that you want to send to and have a cron job/scheduled task periodically run and select the correct number of entries from the queue and send the emails.

In addition to having php's error_reporting set to E_ALL, you need to have display_errors set to on. ini_set("display_errors", "1"); The use of the non-existent $row['user_id'] would produce a php error.

You cannot set the upload size limits using ini_set statements in a script. Php uses those values before it ever invokes a script. You must set them in the master php.ini (when you have access to it), in a local php.ini (when php is running as a cgi application), or in a .htaccess file (when php is running as an Apache Module.) You would also NEED to set them to larger values if you are using php to process uploaded files, so it would be very advisable to change the php settings.

echo "<td><input type='text' name='editfirst' value='{$row['First Name']}'></td>";

Your code is figuratively and literally all over the place. You have about 50% blank lines, you are requiring the same files twice, you are making a database connection twice, you have unnecessary closing/opening php tags, you have a newline before the first <?php tag that is probably preventing the session variables from working, accessing variables that have not been set... You need to spend some time cleaning up your code first. If the purpose of the posted code is to edit profile information, the $_SESSION['user_id'] should be tested to make sure it isset and that it is the same value as the $_GET['user_id'] or $_POST['user_id'] (whichever one you are actually using to pass the user_id to that page.)

Your $_POST['ItemCode'] value probably has a new-line character at the start of it. Where is the value in the $_POST['ItemCode'] field being set from?