PFMaBiSmAd

Your <form tag does not have the necessary enctype for an upload to work - http://us.php.net/manual/en/features.file-upload.php

The $this pseudo-variable has been a reserved variable name for use in OOP for a very long time. When did this error first start occurring?

Good God. Don't use the time() function. You already have the data in the optimum format for storing, comparing, and retrieving dates. Just fix the logic in the query - $q = mysql_query("SELECT * FROM table_college WHERE '$date' BETWEEN date AND due_date");

You are joining the table to itself, rather than to the second table name.

It's almost always simpler and faster to let the database engine retrieve the rows you are interested in, in the order that you want them, and with each piece of data formatted the way you want it.

if (!$result) { That conditional test only checks of the query executed or not. It does not test if there were any matching rows. Start by finding out why the query failed (for all we know, the $db connection does not exist) - if(!$result){ // the query failed, for debugging purposes, echo the query and mysql_error() to find out why echo "The query failed: $sql<br />Because: " . mysql_error(); die(); }

The following query will select only the rows that have an expiry date greater-than or equal to the current date and it will order the rows with ascending expiry dates - $query_promotions = "SELECT * FROM promotions WHERE expiry >= CURDATE() ORDER BY expiry"; You then just need to retrieve and display the rows. You should not use a do-while loop as it requires more logic to accomplish the same results as just using a simpler while(){} loop.

You must examine the code and the table structure for both scripts until you fully understand what each is doing, then write the necessary code to mimic/bridge the functionality being performed by one of the scripts so that it works with the table of the other script. This is not just a simple matter of changing one line of code and the exact coding necessary is unique for each different application and even each different version of each application. Your posts in this thread have not even mentioned which two different applications you are dealing with, so no one can even begin to offer any specific help.

http://us3.php.net/manual/en/function.natcasesort.php

One of the great points of using a database is you only retrieve the data you are interested in. Your query should contain a WHERE clause that only retrieves rows that have expire dates that are greater than or equal to the current date. Let the database engine do the work for you instead of writing a lot of extra code (php is a slow parsed, tokenized, interpreted language compared to the compiled code that the database engine uses) to scan through the results of the query. However, given the date format string you are using 'F j Y', the dates are not stored in a format that permits direct greater-than/less-than comparisons or ordering. Your first step would be to start storing the dates in your table using a DATE data type, that what it exists for.

http://us3.php.net/manual/en/language.operators.comparison.php

You can only sort dates when the year, month, and day fields are left-to-right, most significant field (year) to least significant field (day) Use date('Y-m-d',strtotime($correctDate));

$PHP_SELF was depreciated long ago (8 years) in php4.2 when register_globals were turned off by default. Register_globals being on, finally throws a depreciated error in php5.3 and they have been completely removed in php6. See this recent thread for what you need to do to make your code operate without relying on register_globals - http://www.phpfreaks.com/forums/index.php/topic,291699.0.html

Mchl already addressed that. You write code that references the correct $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION, $_SERVER, and $_ENV variables where the actual data is coming from. If you are using session_register(), session_is_registered(), or session_unregister(), you will need to make additional changes in the code to use the $_SESSION array.

@DWilliams, register_globals has nothing at all to do with what you just posted. It concerns 'magically' populating program variables from the same name $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION, $_SERVER, and $_ENV variables, thereby allowing hackers to set any program variables and $_SESSION variables instead of just the intended variables.

Echo $query so that you can see exactly what it contains.

There's probably a dozen different possible reasons. If you echo mysql_error() it will tell you why the connection failed. No guessing is needed.

That's not my code. As soon as you altered it or even just copied it into your file and ran it on your server, it became your responsibility for what it does. A) Did you read the error message and set a default time zone like it states. B) The value in $datefor[0] is not what you think because that code gave a default date of 1970-01-01 that corresponds to a zero value from the strtotime() function, meaning that strtotime() could not operate on what you supplied it.

Kind of depends on what error, problem, or symptom you saw in front of you when you tried it. We only see the information you provide in your post and since we don't have access to your server or your database, you are the only one here who can actually run your code in your environment and tell someone not standing right next to you what happened.

$date = date('Y-m-d',strtotime("15 Mar 10"));

Your query failed to execute and returned a FALSE value instead of a result resource. Echo mysql_error() to find out why the query failed.

You need to fix your code so that there is no output being sent before the header() statement. The error message states where the output is occurring at. You likely have something in your opendb.php file after the closing ?> tag.

Then anyone can visit one of your 'protected' pages and access the content. You need to find out why the header() redirect is not working AND correct the logic so it tests if the session variable(s) are set (set by a successful log in) and put an exit; statement after the header redirect. For debugging purposes, add the following two lines of code immediately after the first opening <?php tag on one of your main pages that has the check.php code included on it - ini_set("display_errors", "1"); error_reporting(E_ALL); After you find and fix whatever problem is preventing the header from working (for all we know the include() statement is failing and the check.php code is not even involved) you would use code similar to the following to protect a page - <?php session_start(); if(!isset($_SESSION["user"])){ // the current visitor is not logged in header('Location: the_url_you_want_to_redirect_to'); exit; }

$HTTP_SESSION_VARS were depreciated long ago (8 years), turned off by default in php5, and completely removed in php6. Use $_SESSION Each of your header() redirect statements needs an exit; statement after it to prevent the remainder of the code on the page from being executed. All a hacker needs to do is ignore the header() redirect and he can access the content on the page anyway. The log in code is not escaping the data being put into the SELECT query, so it is possible for a hacker to easily cause the query to match any row in your table without knowing the actual password. The check.php code does not contain any logic to check what is in the session variables, so it is unlikely that is the actual code. If that is your actual code, you likely have a header() error that is preventing the header() redirect from having any affect, because all visitors (even logged in ones) would be redirected by that code.

You are having a little trouble with your variable names in the following two lines of code - $extensie = search_extenstion($name); if (!in_array($extenstion, $filetypes)){ If you were developing 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, php would help you by displaying all the errors it detects. You would save a TON of time. There would have been an undefined error message about the $extenstion variable (which is not spelled correctly anyway) since it is not the same variable name as what is being used in the line of code that is setting $extensie.