mac_gyver

a. any substitution or processing of output, should occur when you output the data, not when you store the data. b. if you have a need to store data containing sql special characters, quotes in this case, you would apply any escape_string() function or even better yet, simply use a prepared query, right before executing the query, not prior to content being added to the data that contains quotes.

the sql query you are showing and the output you are (trying) to produce from that query make no sense. if this was working, you are querying for the row of data WHERE the id column matches the $_GET['id'] value and looping to produce a (one) link with ?id=$row['id'] in it, i.e. a link containing the same id that was in $_GET['id']. you need to step back and come up with a stateable definition of what your code needs to do. you are doing two things, 1) producing navigation links, and 2) when a link has been clicked, you are displaying the content that corresponds to the id in the clicked link. to do item #1, you would query to get ALL the page ids, and page names/titles, which i assume are in the menuheader column (if you list out the columns you are selecting in a query, rather than using *, it helps make your code/query self-documenting.) you would then test and loop over the result from this query to produce navigation links. Note: almost every if() conditional test needs an else so that code does something when the main condition fails. for navigation link data, if there is no data, rather than outputting nothing, you should output a 'sorry, nothing to display' or similar message. to do item #2, you would test for a $_GET['id'] value and use it to query to get the matching row of data, fetch that single row of data (no loop needed), and if there was a matching row of data, output the content for the page. if there was no matching row of data, you would instead output a 'nothing to display' or similar message.

that's not the FromData object, as was mentioned, and the jquery .serialize() method doesn't include the file data.

in order to upload a file using ajax, you need to use the FormData() object (current, best method) - https://developer.mozilla.org/en-US/docs/Web/API/FormData

since a button of type = 'button' doesn't do anything by itself and you are outputting json encoded data back to the browser, what is the javascript/ajax code that's trying to upload the file?

see the usort() function - https://www.php.net/manual/en/function.usort.php

all you have done is replace the single $row = $query->fetch_assoc(); statement with one inside of a while(){} loop. how is that going to make this work? rather than starting new threads for the same problem, read the reply, on how to correct this, that you have already gotten in the first thread.

just fetch all the rows of data into an appropriately named php array variable, then use the contents of that variable in your html document. if the variable is empty, no rows of data were matched. to display the number of rows of data, use php's count() function. to get a copy of the common values for displaying the one-time heading, just reference the zero'th row. to loop over the data, use a foreach(){} loop.

database connections are resources. all resources on a web page are destroyed by php when the php script ends, i.e. you cannot pass a database connection in a session variable. you must make a new database connection on any page that needs one. as to the http 500 error, you have a php syntax error in the code on that page. find the php.ini that php is using and set error_reporting to E_ALL and display_errors to ON, so that php will help you by reporting and displaying ALL the errors it detects.

your posted code has one technical issue, in that it only stores the last validation error in the $error variable, so, if there are multiple validation errors, you would only see the last error message. using an array to hold the error messages will solve this, and using the field name as the array index will let you test for and display the messages adjacent to the fields they belong with. i recommend displaying any error above or next to the field, rather than below it, in case the field is at the bottom of the screen and anything below it might not get seen. does your posted code operate as i have described above or does it appear to insert empty values when you don't enter anything in the form fields? if so, i suspect that your html markup has some white-space as the field value attributes, which won't be considered as empty(). correcting the html mark would correct this, but trimming the data as suggested would handle the case where a visitor accidentally enters space character(s) in a required field. do you have a specific question, problem, or error concerning the suggestions?

external data can be anything and can come from anywhere. you must validate data on the server before using it. your form processing code should - detect that a post method form was submitted. trim, than validate all inputs, storing validation errors in an array, using the field name as the array index. if there are no errors (the errors array is empty), use the submitted data.

a phone number, despite being called a number, isn't an integer. it is a formatted string consisting of 3 or 4 fields, depending on which country you live in and if you are including the country code with international numbers. the signed integer you are using (int(12) isn't even valid) can only hold a value up to 2147483647 (214 748 3647) which can only store some US phone numbers up to area-code 214. use a string data type and format the value into a common format before using it. once you define the column with a usable data type and as a unique index, just attempt to insert the data and detect if a duplicate index error number occurred to determine if the phone number already exists.

when you exceed the post_max_size setting, both the $_POST and $_FILES arrays are empty, so, logic trying to use those values won't have anything to test. your post method form processing code should first test if a post method form was submitted. you can then compare the content-length (see $_SERVER['CONTENT_LENGTH']) value (which is in bytes) with the post_max_size (see ini_get('post_max_size') ) setting (which used to be in whatever units the setting is in - bytes or K, M, G short-notation, which may now be (unconfirmed) always in bytes due to the addition of the new Warning message for this condition) to produce your own error message. when on a live/public server you should set php's display_errors setting to OFF and set log_errors to ON to cause php error messages, which would include that new Warning message, to be logged instead of displayed.

: is the unix include path separator. it's ; on windows. is the capitalization of the path and filename in the code the same as the actual path and filename in the operating system?

the update form isn't propagating the p_id GET value. if you leave the action='...' attribute completely out of the form tag, the browser will automatically include any existing get parameters when the form is submitted. next, the p_id value is a required input for that page to work. when it isn't present, any dependent code shouldn't be executed and you should instead set up an error message for the user telling them that a required input has not been supplied. either the user reached the page without using an edit link or there's a programming mistake somewhere, i.e. the current problem. there's actually a lot of unnecessary code/typing in this, making it harder to see the forest for the trees. some suggestions - don't copy variables to other variables for nothing. just use the original variables. there are 17 current lines of code doing this that don't add any value to what you are doing. don't change the name of things. the p_id is actually the user_id value. you should use user_id throughout the code. as has already been mentioned, use a prepared query when supplying external, unknown, dynamic values to a query and switch to the much simpler PDO extension. a prepared query, while adding only one php statement per query, actually simplifies the sql query syntax, making it easier to produce error free sql queries. don't use a loop to fetch data from a query that will match at most one row. just directly fetch the row. you should also test if a row was fetched or not and set up a message for the user if there was no matching data. don't build a string (the sql query) using a bunch of concatenation statements. just directly build the query as a single string. you can put white-space in an sql query to format it. don't include the user_id column in the SET part of the update query. the user_id is the defining column that identifies each row of data. by including it in the SET part of the query, any intentional or accidental change can produce duplicate values and will break the association with any related data in other tables. post method form processing code should detect if a post method form has been submitted, trim all input data (this can be done with one single php statement operating on the data as a set), then validate all inputs before using them, storing validation errors in an array, using the field name as the array index. if there are no validation errors (the array is empty), use the input data. if there are validation errors (the array is not empty), display them at the appropriate location in the html document when you re-display the form.

does that mean that the 'protected' content is displayed or does it mean that the expected response of redirecting to the login form doesn't occur and the browser stays on the display_items.php page while displaying a blank page?

password_hash() generates a random salt per call, if you follow the recommend usage. so, every time the same password gets hashed, the stored hash is different and anyone getting a copy of any such hashed data won't be able to directly find all the entries with the same password once they find an input/hash match for one. they will need to go through the process for each stored hash. the hash algorithm, random salt, and cost are stored with each hash, so it is still possible to generate lookup tables for each combination of these values to shorten the process. the point of hashing passwords is to protect the user's data. it has nothing to do with preventing any type of external attack.

you cannot concatenate general php logic together with a string. you can only concatenate php code that evaluates to a string. the reason it's displaying the id is because you are concatenating the result of the $id = $_GET['id']; assignment statement onto the end of the string in $accom. that's the end of the concatenation in the existing code. the rest of the strings being built in the php code are being discarded, because they are not 'attached' to anything. you would need to use $accom .= to add the string that's being built inside of the while(){} loop and again for the string that's being built after the end of the conditional logic. edit: you would also need to terminate the string assignment statement, right before the (needless) $id = $_GET['id']; assignment statement, with a ; rather than with a concatenation dot. you should also use a prepared query when supplying external, unknown, dynamic values to a query when it gets executed, instead of putting values directly into the sql query statement.

based on the error message and the displayed spacing in the posted code, there are probably some non-printing/non-ascii character(s) between the AND and the 's (incorrect quote usage around a column name) or just the s (correct quote usage around a column name), that's breaking the sql query syntax. when you copy/pasted the echoed sql query syntax to run it directly against the database server, you are only getting the printing characters, which eliminates the cause of the sql syntax error. when you alter your code to use @Barand's suggestions, i recommend that you delete and retype everything between the end of the AND and the s. as to the query 'working' with the quotes around 'start_date', making it string, rather than a column name, a string starting with s is greater than a string starting with a numerical digit, so that (version of the) query may be returning data, but it's not because the date comparison is working.

don't actually move any data between tables. in fact, once 'live' data is inserted into a table, it is almost never actually deleted. all you need to do is record and use a 'status' value. you should have a user table that holds the unique, one-time, user information. the auto-increment integer id column in this table establishes a user_id that you would use to relate any other user data, such as the user's status, back to the user it belongs to. you would have a status table that defines the different status values (id and name columns.) the auto-increment integer id column in this table establishes a status_id that you would use to relate any status data back to the status name. you would then have a user_status table (id, user_id, status_id, datetime, ... columns) that is used to hold the user status records. you would insert a new row in this table for each transaction that affects a user's status. when the user registers, after you insert the row in the user table, you would get the last insert id from that query, then insert a row in the user_status table with a status_id value that corresponds to a 'new' non-approved user. you would query to get a list of the 'new' users to select which one(s) you want to approve. when you submit this information, you would insert new row(s) in the user_status table with the selected user_id and the status_id value that corresponds to the 'approved' state (or any other state you specifically select via a form input.) to query to get the 'current' status for any user(s), you would get the group-wise latest/highest row per user_id value.

check is a reserved work and should not be used as a column name. either use a different name for that column or you must enclose the column name in back-ticks to cause it to be treated as an identifier.

$this (programming pun intended) is the correct syntax, but produced a different error than the one you posted about the undefined variable. what was the error message in $this case? i'm going to guess that the database connection probably failed and there's no useful error handling in the code. while not the cause of the most immediate problem, your main code should be responsible for creating the database connection, then use dependency injection to supply that to any class that needs it. by making each class responsible for getting a specific database connection, your code is not general purpose. if the data source changes, to use an additional/different database type or using a remote api, you would need to go through and edit all the current code.

odd syntax errors are often caused by copy/pasting code from web pages where it has been 'published' and 'beautified'. it contains non-ascii characters that when treated in a php code context breaks the php code. the solution is to delete and re-type the line of code. there should be no quotes in the print_r() output around the associative array index names (just tested.) there's something going in your form field name attributes. what is the code/markup for your form fields?

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.