PFMaBiSmAd

What does a phpinfo() statement show for the actual error_reporting, log_errors, error_log, and display_errors settings? Basically what you are saying (error_reporting/log_errors are set but the file() function is returning false and not reporting an error) is not possible unless the function has been disabled or the error related settings are not actually what you think they are.

Without an actual example of what you are doing and the code doing it, best guess is that include/require works because the file can be found because it on the include_path statement. file_exists() returns false because the path being used is not correct for the current file where the code is being executed at and file() is not producing any php error either because it is either inside of a conditional statement so it is not actually being executed or your script is altering the error_reporting/display_errors/log_errors settings so that no error is reported.

All references to $ptag must be changed to use $_SESSION['ptag'] and any use of session_is_registered() or session_register() must be corrected (depends on how they are being used.) In general session_is_registered('ptag') would become isset($_SESSION['ptag']) and session_register('ptag') would become $_SESSION['ptag'] = $ptag; However, for the code you posted, the first if(){} statement is not needed ($_SESSION variables ARE already part of the session and don't specifically need to be 'registered') and the code would become - <?php session_start(); //if ptag value has been set via form method post if (isset($_POST['ptag'])) { $_SESSION['ptag'] = implode(',', $_POST['ptag']); } //if reset value has been set via form method post set ptag to blank if (isset($_POST['reset'])) { $_SESSION['ptag'] = ""; } ?>

The problem is that the actual HTTP request that the server receives is for materials/yourfile.ext and that is not allowed so it never gets to the url rewriting. There may be a option/switch to allow this to work, but I would recommend that you put the actual files into a folder that is not named the same as what is used in the path in the URL and then build the actual path in master.php using the actual differently named path.

Yes, people do this all the time. Therefore, the problem is something specific you are doing and we need to know all the relevant details about what you are doing. What exactly is in your .htaccess ?

Yes, you can. Even if just temporarily, long enough, to troubleshoot the problem, using an ini_set() statement, in your script.

You can disable specific functions using the disable_functions php.ini directive. The phpinfo() output will list if or which functions might have been disabled.

So, what exactly is $_REQUEST['REQ_URL']? It it an actual URL to the file (http://yourdomain.com/your_path/your_file.ext) or just a file name (your_file.ext)? I don't know what passthru() would do for how you are calling it (it normally executes a command that has meaning relative to the operating system.) You would normally use readfile() to do what you are trying. You should also not directly put anything that comes from user supplied input into a statement that reads and outputs the content of a file, unless you fully validate what was supplied. By suppling the correct path (using enough ../../..) to say your database connection details file, someone could easily get the code you posted to output any of the files on your server, not just the files in your "materials" folder.

Only if your code is actually preventing submission of data to the page. As already posted above, a lot of people's login code does NOT actually prevent access to a page when a search engine or a hacker requests the page. Then you are doomed to receive blank data. What happens when a logged in user hits the submit button without filling in all expected data or when his browser submits the page twice as has already been posted above as one of the possible reasons you are getting blank records? No. That does nothing to insure that you don't insert blank data. That only insures that the person (or a bot script) was good enough to correctly enter the captcha phrase. You must always validate user supplied data that you place into a database query.

The "deny from all" prevents HTTP/HTTPS requests for the files. If your .php script cannot read the files, that would imply that you are using a URL to read the files instead of a file system path.

Simplified version - A file system is like a database. As files are added or removed, the file information gets added or removed in available spaces in the directory table. If you remove a couple of files, then add more, the empty spaces in the directory table will be used first, then more entires will be added to the end. Some disk optimization utilities actually reorder the entries in the directory table so that they are alphabetical. The order that readdir() returns names in is the order of the file names in the directory table. The only way to guarantee that your code operates on a list that is in the order that you want it to be is if you read the list into an array and sort the array the way you want. Edit: Or use one of the functions like glob() that can return the list in alphabetical order.

The posted error is occurring in insertsection1.php, in the following line of code - mysql_connect(localhost,$database,$password); The second parameter is NOT the database name, it is the user name. I'm going to guess that the 'user' portion of the error message is actually your database name. When an error occurs, read it, it contains important clues and also read the actual code that is producing the error.

Ummm. What errors does php report as to why the function calls are failing when full php error_reporting/display_errors setting are turned on? I'm going to guess you are using URL's in the function calls that are failing and you are using file paths in the function calls that work.

Yeah, it is more likely that the code you are using to generate the values has a limitation that is only producing that specific number of unique values.

You haven't exactly provided any proof that the logic is operating on values that would cause it to be redirecting. Are you sure that $value is ever an empty string? Are you 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 so that php would display all the errors it finds, like a header error that would prevent the redirect from working?

It's likely because you are using some short open tags <? and the portion of the php code after the <? is not being seen as php code. Only use full open <?php tags to keep from wasting your time due to problems with the short open tag. Edit: Correcting line 292 to a <?php tag eliminated the error when I tried it. OMG, how much time gets wasted by trying to save the time it takes to type three characters - php.

It depends on what your data is and what you are doing with it. If you are doing typical things, such as finding specific values and ordering them a specific way, using a database engine, which uses compiled code to do the finding and ordering will be at least 100 times faster than using some slow parsed/tokenized/interpreted php code to do the finding and ordering of the data that is in a file.

A SELECT query that executes without any errors returns a result resource - You must then fetch a row from the result set (there will be only a single row for your query with the count(*) statement) using either a mysql_fetch_xxxxx instruction or a mysql_result() instruction.

The only valid tutorials that you should have found concerning uploading a file should have contained the following attribute in the <form > tag - enctype="multipart/form-data"

It is likely that your page is being requested multiple times by the browser, once with the form data and a second time without the form data. Because different browsers will request a page twice for different reasons, you cannot control what the browser does and you must detect and prevent this in your form processing code. Your form processing code should already be validating all the user supplied data and it should only be executing the INSERT query when all the expected data has values. This would prevent the insertion of blank records. You might also have a logic error in your code that allows the INSERT query to be executed anytime the page is requested. You would need to post your actual code so that someone could see what it might be doing that could cause the symptom. A lot of log in code omits an exit statement after a header() redirect that allows search engine scripts and hackers to access the 'protected' code on a page.

You need to remove the single-quotes from around the alias name where it is used in the ORDER BY term.

Different browsers provide different ["type"] for the same file. Until you display the value that is failing the test of the ["type"] element, no one can help you solve the problem.

When you are validating user supplied information and you expect it to have a specific value in a test, it is usually a good idea to display the actual value that fails a test so that you know exactly what was received. Also, your posted code is NOT checking for any of the possible upload errors before attempting to test the ["type"] or ["size"] elements. It is likely that the upload actually failed and the ["type"] is empty - http://us.php.net/manual/en/features.file-upload.errors.php

See Example #3 in the documentation - http://us3.php.net/manual/en/features.file-upload.post-method.php

Simple, just do it in the query when you select the column - $q = "SELECT DATE_FORMAT(date,'%e %b %Y') as date FROM template";