mac_gyver

you also have a reply in your previous thread pointing out an issue with using both bindParam() and supplying an array to the ->execute(...) call -

don't use variable-variables, ever. they are not needed, ever, and for the posted code, those bindParam() statements aren't doing anything. you are overriding them by supplying an array to the ->execute(...) call. using bindParam/bindValue and supplying an array of value to the ->execute(...) call are mutually exclusive methods of supplying values to the query. you should simply supply an array of values to the ->execute(...) call. i was hoping that getting working php/pdo errors would point to a problem i saw in the code. you are hard-coding the table name (Sites) in the $sql query you are building, rather than using the supplied name. since this table name doesn't match the list of columns you are supplying, you should have been getting a pdo/mysql error about unknown columns in the query at the execution of the ->prepare() call.

you have to find what's causing a problem in order to fix it, otherwise you are just putting Band-Aids on top of symptoms, and the real problem remains. there are significant problems in the posted code - no comments to let anyone know what the intent of any section is, variables created for nothing, inconstant/no error handling, putting external data directly into sql query statements, running queries inside of loops... you will only see a http 500 error page in a browser due to a 'primary' request to a page, not an ajax request. if you are seeing a http 500 error page, it's for the action of the form - userlistssiexport.php?id=$coursefilterid. what is the code for userlistssiexport.php? and it's not any of the posted code because there is no $_GET['id'] or $_POST variables, the data that the form will submit, anywhere in the code you have posted.

the code handling that from submission isn't even part of the posted code, though it should be - the form should submit to the same page it is on, so the most immediate problem is in some different code. you need to find the php.ini that php is using and set error_reporting to E_ALL and set display_errors to ON, so that php will report and display all the errors it detects. stop and start your web server to insure that any changes made to the php.ini will take effect and then use a phpinfo(); statement in a .php script file to check that those settings actually got set to those values.

that's not what I stated/asked about php's error related settings. you are setting the pdo error mode to exceptions (twice.) what this does is cause an error with a prepare(), query(), exec(), execute(), ... statement to throw an exception. if you don't catch the exception in your code, php will catch it. if php's error related settings are not set up to report and display (or log) all php errors, nothing will happen with this information. your script will just halt at the point of the error. as to the try/catch block you do have for the connection. a connection error is a fatal problem for a database dependent web page. your code should stop upon such an error so that you don't get follow-on errors by trying to use a connection that doesn't exist. if you just remove that try/catch logic and let php catch the exception, any connection error will get displayed or logged the same as php errors. the only time you should have a try/catch block for database statement errors is if the visitor to the site can correct an error that he/she caused, such as inserting/updating duplicate or out of range values. in all other cases, you might as well save the typing and just let php catch and handle the database exception.

you are most likely getting an error from the ->prepare() call. do you have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your system, so that php will help you by reporting and displaying all the errors it detects?

what symptom or error did you see that leads you to believe that?

regardless of what you do to pre-check the username, from the point in time when you pre-check if the username is available, to the point where the user actually submits the form, someone else could have submitted the same username and it is no longer available. your database table must enforce uniqueness, by defining the relevant column(s) to be unique indexes. you must then have error checking for the INSERT query to detect if a duplicate was attempted to be inserted, and report back to the user if the username already exists.

there's no reason for the php code to even be making a database connection, unless it was testing if the database server is running and the connection credentials are valid, which it isn't doing.

just about everything in this code is working against you finding out what the code is actually doing. put the php error related settings into the php.ini on your system. if for some reason you can only (temporarily) put them into your code, put them before all other php statements and put them into both of the relevant files. you are likely having an error at the session_start() statements... don't use output buffering unless you want to specifically buffer output. by always using output buffering, you don't know if the lack of php errors or other indications from your code, is due to the operation of the code or due to the operation of the output buffering. all output, except due to a fatal php error, will be discarded. the only redirect inside post method form processing code, should be to the exact same url of the current page upon successful (no errors) completion of the form processing code. this will cause a get request for that page. then provide navigation links to allow the visitor to go elsewhere on the site. don't loop to fetch the result from a query that will match at most one row of data. just fetch and test the result of the fetch statement. you are also testing the num_rows value inside the loop. if there are no rows, the loop will never be entered, and the num_rows test will never get executed. you should store the user's id (auto-increment integer) in the session variable to indicate who is logged in, not the (raw) username, which could be anything, including javascript/sql,... there's actually a bunch or other issues with this code, which i will leave for others to mention.

php is a server-side scripting language. if you are not making a http(s) request to a web server for the .php file, the php language engine isn't being invoked. when you directly enter the URL of the .php file in question in your browser's address bar, do you get the expected output?

are you using full <?php opening tags, per the problem in one of your previous threads? https://forums.phpfreaks.com/topic/311034-includes-not-being-displayed-on-page how about the other improvements made in that thread? you seem to have gone backwards.

what URL to the file through the web server are you using? it should be something like - http://localhost/your_file.php

method is misspelt in the form tag, so this is actually a get method form and none of the $_POST data exists.

you need to read @requinix's reply about the data type of the expires column. actually, you need to slow down, define what you want each part of the code to do, then test and observe the result you get at each step so that you are actually learning by doing. the php error message you most recently got was the same and for the same reason as at the start of this thread, a different number of prepared query place-holders vs the number of bound inputs in the php code. you also have a case later in the code that will produce the same error due to the use of an $email variable in an sql query vs correctly using a place-holder in a prepared query. next, you have have a serious functionality problem in that your code will allow empty password/password2 inputs to reset the user's password, due to not having exit; statements after every redirect. this is made worse by the form and the form processing code being on different pages, which requires the user to keep reentering these values every time there is a validation error. you should put the form and the form processing code on the same page, the only redirect you should have in your form processing code is to the exact same url as the current page upon successful completion of the form processing code, and you should always have an exit; statement after every redirect.

you can use the PDO classes (PDO, PDOStatement, and PDOException) at any time in any code.

if you are asking this because the mysqli prepared query programming interface is ridiculously overcomplicated and inconsistent, switch to the much simpler, more consistent, and better designed PDO extension. no. it only works for string data and then only if the character set that php is using is the same as your database table's. a prepared query works for all data types. also, aside from trimming data, mainly so that you can detect if all white-space characters were entered, don't alter user submitted data. just validate data and use it if it passes validation. by altering data, you are changing the meaning of it which can lead to security holes or unexpected operation in your application, having nothing to do with sql special characters in data values. yes. a true prepared query (PDO has an emulated prepared query that suffers from the same character set mismatch between php and your database table's) prevents any sql special characters in data from breaking the sql query syntax, by separating the parsing of the sql query syntax from the evaluation of the data values.

the simplest and most efficient way of doing this would be to query the database to get all the data matching the date range you are trying to display, fetch all the data into a php array variable, using the date value as the main array index. if there can be more than one piece of data per day, when you are fetching the data store it as an array of rows of data. then, as you are looping to produce the output for the calendar, for each day, form a date value in exactly the same format as was used for the array index values, test if an element isset() in the array of data, and if so, reference it when you are producing the output for that calendar's day.

if you do this - you will end up with code that looks like this - $out = ''; foreach($indexed_data as $type=>$arr) { // start a group $out .= "<optgroup label='$type'>"; foreach($arr as $row) { // add the output for each $row of data within the group $out .= "your makdup here for the <option ...>...</option> tag"; } // finish the group $out .= "</optgroup>"; }

that's an acceptable var_dump() output. the length matches the number of displayed characters. i suspect you are seeing the result of two (or more) requests to the page. for the first request, there is an input value and when you are using echo/var_dump to display it, this is preventing a header() redirect, that's causing additional request(s), which don't have the expected input. you are seeing the displayed result from the last request made. this 'works' when you hard-code the value, since all requests have the input value. so, two things - if it sounds like your code is capable of doing this, you will need to find and fix what's causing the additional request(s) and if you cannot determine what's causing the problem, you will need to post all of the code needed to reproduce the problem. you should always validate all inputs before using them (yes a session variable is an input to your code) and setup/display a message letting the visitor know that a 'required' input is not present. lastly, why is this value in a session variable at all. that's generally a sign that you are doing something in the hardest way possible.

the value probably contains some non-printing character(s). what does var_dump($_SESSION['bid']); show?

you got an sql syntax error message calling your attention to a specific point in a query. did you look at that sql query and attempt to determine what might be wrong with it at that point?

no. the parameters and values in code can come from any expression, such as a literal string, a variable, the return value from another function call, a math/logical operation, ... you would define a data structure (array or database table) that contains a list of the expected form field names (types, validation tests...) you would then loop over this defining structure to dynamically test/validate the inputs. the field name, which would be in a variable, would be used in place of any hard-coded associative field name in the code. except for unchecked check-boxes and radio-buttons, all other form field types will be set once the form has been submitted. after you have detected that a post method form has been submitted, you would only use isset() for check-boxes and radio-buttons. for all of the 'always set' field types, you should test if they are equal (or not) to an empty string.

as a side note - if you use the PDO::FETCH_COLUMN fetch mode with the fetchAll() method, you will directly get an array of the (column) values, rather than an array of rows of data.

for the $jokes variable to not exist, either the query failed due to an error or there are no (matching) rows in the database table. for the first case, most database statement errors are fatal problems, either due to programming mistakes or the database server not running, and there's no point in code on the page continuing to run at all. therefore, you would want your error handling to display the actual error information when you are learning, developing, and debugging query(ies) and to log the actual error information when on a live/public web server. to do this, simply let php catch the exception, where it will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any existing database statement error handing, so that you don't need to keep track of if you are actually displaying/logging the output from it. the exception to this rule are execution errors for inserting/updating user submitted data and a duplicate or out of range error can occur. in this case, you would want your error handling to catch the exception, test if the error number is for something your code can handle, then setup and output a message telling the user what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it, as described above. short-version: only use a try/catch block for database statement errors when a visitor on a site (not you as the programmer/developer) can do something about correcting the error. for the second case, your code producing the output should test if there is data to display, and either output a message stating there is not, or use the data to produce the output.