mac_gyver

just because something works, does not mean it is correct. this code easily contains twice as much logic as is necessary and as already stated, by passing the price though the form, it is insecure. the line of code with the error exists 5 times in the posted code. it should exist only once - Don't Repeat Yourself (DRY), near the top of the code, in an initialization section and it should initialize the session cart if it doesn't exist - $_SESSION['cart'] = $_SESSION['cart'] ?? []; all the rest of the code should directly just, simply use $_SESSION['cart']

does the browser goto appr.php with a valid id=xxx on the end of the url? btw - you should be using a post method form when performing an action on the server. also, when learning, developing, and debugging code/query(ies), you should display all php errors. error_reporting should always be set to E_ALL and display_errors should be set to ON, preferably in the php.ini on your system. by setting error_reporting to zero in your code, php won't help you find problems that it detects. you should always have error handling for statements that can fail. for database statement that can fail - connection, query, prepare, and execute, the simplest way of adding error handling, without adding code at each statement, is to use exceptions for errors and in most cases let php catch the exception, where php will use its error related settings (see the above paragraph) to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) to enable exceptions for errors for the mysqli extension, add the following line of code before the point where you make the database connection - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); next, you should always trim, then validate inputs before using them. if a required input doesn't exist, that's an error and you should setup a message for the user and not attempt to run any code that must have the input. you should not put external, unknown, dynamic values directly into an sql query statement. use a prepared query instead. you would also want to switch to the much simpler PDO database extension. ids in the html document must be unique. if you are not using any particular id at all, simply leave it out of the markup. you should validate your html markup at validator.w3.org

i don't see a redirect in this code to index.php? could you clarify exactly what does occur? btw - you should only store the user id in a session variable to identify who the logged in user is, then query on each page request to get any other user information, role, or permissions. this will let you edit that information and it will take effect on the very next page request, e.g. if you promote, demote, or ban a user, you want it to take effect immediately, without requiring them to log out and back in. you should also - use php's password_hash() and password_verify() don't use a loop to fetch at most one row of data, just directly fetch it. to allow a user to goto another page after they login, provide navigation links, or better yet, integrate the login on any page that needs it.

if you take the advice given and simplify the cart definition, so that it only holds the item id, as the cart array index, and the quantity ,as the stored value, the add to cart function code will look like this - // insert a new item into the cart or update the existing quantity function AddToCart($item_id, $quantity) { // if the item is not in the cart, insert it with a zero quantity $_SESSION['cart'][$item_id] = $_SESSION['cart'][$item_id] ?? 0; // add the submitted quantity to the cart $_SESSION['cart'][$item_id] += $quantity; // remove zero quantity items $_SESSION['cart'] = array_filter($_SESSION['cart']); } note: the input data to a function should be supplied as call-time parameters, and it is not the responsibility of this function to preform a redirect. by using the item id as the array index, you can directly test/access the item data in the cart. there's no need for any looping.

the error is because the content contains a single-quote/apostrophe. this is breaking the sql query syntax. in the distant past, php provided some protection for this, but this has been removed since it didn't address every character set situation. the best way of handling this is to use a prepared query, which provides fool-proof protection for ALL data types. you can use a prepared query with the mysqli extension, but as already stated this is overly complex, requiring you to learn the same amount of new statements as learning a whole new database extension. if you are going to do that much work, you might as well just learn the much simpler PDO extension. converting any query to be a prepared query, using the PDO extension, is extremely simple - // 1. remove the php variables, any single-quotes around them, any {} around them, and any concatenation dots that are being used to get the php variables into the sql query statement. // 2. replace each value in the sql query statement with a simple ? place-holder. // your sql query would look like this - $ekle = "insert into icerik (baslik,icerik,yazar) values (?,?,?)"; // 3. prepare the query - $stmt = $pdo->prepare($ekle); // 4. take the variables you removed in step #1 and supply them as an array to the execute call - $stmt->execute([ $baslik,$icerik,$yazar ]); the above conversion applies to select, insert, update, and delete queries. for select queries, to fetch data from the query, you would need to use either the fetch() method (for single row of data), fetchAll() method (for all the rows of data), or sometimes the fetchColumn() method (for single column, such as a COUNT() value from a query.) the following is typical PDO connection code - $DB_HOST = ''; // database host name or ip address $DB_USER = ''; // database username $DB_PASS = ''; // database password $DB_NAME = ''; // database name $DB_ENCODING = 'utf8mb4'; // db character encoding. set to match your database table's character set $options = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // set the error mode to exceptions PDO::ATTR_EMULATE_PREPARES => false, // run real prepared queries PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, // set default fetch mode to assoc ]; $pdo = new pdo("mysql:host=$DB_HOST;dbname=$DB_NAME;charset=$DB_ENCODING",$DB_USER,$DB_PASS,$options);

when the insert query no longer works, does the header redirect to yonetim.php work or not, i.e. does it redirect or do you stay on the form processing page? if the query is failing, you need some actual error handling for the database statements so that you can find out why they are failing. add the following line of code before the point where you make the database connection - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

i also noticed this on the all activity tab. i just switched to the expanded content, given how ridiculous this forum software is. this change occurred some time ago. it appears like it only shows the last post in any thread in the condensed mode, rather than displaying each post as condensed, which is how it worked previously. edit: if posts are made to the forum while you are busy writing a reply, not in the thread you are replying in, and you click on the x posts have been made ... click to view them, when you are in condensed mode, the new posts are all shown, even multiple ones in the same thread, and they are shown in the expanded mode, while all the older posts are still shown in the condensed mode.

you are putting the external data directly into the sql query statement. any sql special characters in a value, such as a quote, will break the sql query syntax, producing a sql error. this is also how sql injection is accomplished. the solution is to switch to use a prepared query, with place-holders for the sql query statement for each value, then supply the actual values when the query gets executed. you would also want to switch to the much simpler PDO database extension. the mysqli extension uses a completely different programming interface for non-prepared and prepared queries, which requires you to learn almost two different database extensions. the PDO extension treats a non-prepared and prepared query the same.

the above line is incorrect. if the cart isn't set, you would set it to an empty array, not an empty string. the code should also operate directly on the $_SESSION['cart'] variable, rather than copying it to another variable, than back again. this is just a waste of typing and processing. btw - this code is overly complicated and insecure, meaning any attempt at changing it will take a long time and still be insecure. the only things that should come from the client/browser are the item id and the quantity. this will greatly simplify all the code dealing with the cart and by accepting and using the price from the client/browser, you will end up with people setting their own price for items. if you are doing this as a learning exercise, you will better off defining your own cart operations, then design, write, test, and debug the code needed or each operation.

don't you recall in the ERD thread where this was suggested -

no, it seems like you think that the only way to produce the quantity * price for each row of data is if you hard-code the calculation for each row? you are missing the point, and probably not examining the posted information, of a computer program using variable/dynamic values at run-time. the term in the posted invoice sql query - oi.qty * p.price as amount, calculates the quantity * price for each row in the result set. the where clause - WHERE oi.order_id = ? determines which rows are in the result set, matching the current $order_id value.

aren't you at the point of inserting data in to the order table - member_id and date columns, get the last insert id from that query, get the current prices for the product ids from the product table, then insert the data in to the order_item table - order_id, product_id, qty, and price columns that you defined in the ERD?

no. this query should match, at most, one row (the username should be defined as a unique index.)

@Barand, the OP is using PDO. bindValue(), PDO::PARAM_STR, and errorInfo() are all PDO elements. the error you are getting, assuming that php's error_reporting is set to E_ALL, means that the query didn't match a row. you need to test when you fetch the row if anything was fetched. if a row was fetched, it means that the WHERE clause was true and there's no need to test in the current php code if the form username matched the fetched username. however, if no row was fetched, this indicates that the WHERE clause was false. that's the condition where you would setup the login failure message. as to why the query isn't matching a row, and isn't producing an error, are you sure the username/password that you used was correct? when you executed the query directly in phpmyadmin, did it contain the sha1() password hash or did it directly have the password in it? when you make the database connection are you - setting the character set to match your database tables? setting the error mode to exceptions setting emulated prepared queries to false setting the default fetch mode to assoc as to the link you posted, don't take a backward step and use the mysqli extension. the PDO extension is the best choice, though you can simplify how you are using it, and whatever is causing the current code to not match a row will still be a problem with a different database extension. btw - you should be using php's password_hash() and password_verify(). the simple sha... hashing functions where never intended for security purposes. you should also only store the user id (autoincrement primary index) in the session variable to identify who the logged in user is. you should query on each page request to get any other user information, such as the username or user role/permissions. this insures that any changes made to these values will take affect on the very next page request.

the DOM ids must be unique. since you are producing that markup in a loop, you either need to dynamically build the id attribute using unique values or if you are not using the id attribute at all, just remove it. $_POST['qty'] is an array, with the keys being the product ids and the values being the quantities. you would probably want to filter out the zero quantities, see array_filter() to do so. you would then have an array of the non-zero entries. rather than to waste time copying this to another variable, which you are doing incorrectly (you are setting the first element in $quantity to be the entire $_POST['qyt'] array), just loop over the original variable holding the data.

when you re-write this, before the for() loop you have now, execute one query to get all the data matching the $numMonth value, then index/pivot this data using the rc_date column when you fetch it. PDO has a fetch mode, PDO::FETCH_GROUP, that is used with the fetchAll() method, that will do this for you, if the first column you SELECT is the rc_date column. then, as you are looping over the dates in the month, at the point where you have the $sqlDate value, just test (use isset()) and get the matching sub-array of rows in the fetched data and loop over them to produce the output.

the error response you are getting has nothing directly to do with checkbox form data. you are getting an error with either the sql query statement or the execution of the sql query, but because the error handling does not display/log the raw error information, you don't have any idea why it is failing. you need to find what the problem is and correct it. just trying a bunch of different things results in a lot of wasted time, with no actual learning occurring. the current code is using the PDO extension, a prepared query with external, unknown, dynamic values, is supplying an array of the inputs to the execute() call, and is using exceptions for errors. this is the best choice for performing database operations and you should continue to use these practices. some changes for the current code - when you make the connection, set emulated prepared queries to false, i.e. you want to run real prepared queries. set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement. i would also name the connection variable $pdo, so that anyone looking at the code can tell what database extension it is using. because you are using exceptions for errors, there's no point in having discrete conditional error handling logic in your code, because it will never get executed upon an error. so, simply remove the if($result)... logic. if duplicate data is not an application error for this insert (and also for an update) query, you would NOT have any exception try/catch code at all, and simply let php catch the exception, where php will use its error related setting to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) for what you are currently experimenting with, this is probably the case. if you remove the try/catch code you have now, and assuming that your php is configuration to report and display all php errors, you will now start seeing database statement errors too. if this insert (and also for an update) query could result in duplicate data values and this is an error for your application, you would catch the exception in your code, test if the error number is for a duplicate index error, and setup a message for the user telling them what was wrong with the data they submitted. if the error number is for anything else, re-throw the exception and let php handle it. note: $_POST is always set, even if it is empty, so the current logic testing if(isset($_POST)){ will always true. also, don't copy variables to other variables for nothing, this is just a waste of your time typing all of that. your post method form processing code and form code should - detect if a post method form was submitted. keep the form data as an array variable, then operate on elements in this array variable throughout the rest of the code. trim all the input data at once. by keeping the data in an array variable, you can do this with one single line of code. validate all the inputs, storing validation errors in an array, using the field name as the array index. after the end of all the validation code, if the array holding the errors is empty, use the submitted form data. after using the submitted form date (which could cause user/validation errors in itself), if there are no errors, execute a redirect to the exact same url of the current page to cause a get request for that page. if you want to display a one-time success message, store it in a session variable, then test, display, and clear that session variable at the appropriate location in the html document. to allow the user to go to a different page, provide navigation links. if there are errors at step #6, the code would continue on to display the html document, where you would test and display the contents of the array holding the errors, then display the form, populating the form field values with any existing data. apply htmlentities to any values you output on a web page to help prevent cross site scripting.

they would anyway, because there would be no post method form processing code present on that page to even test for post data. also, by copying values to session variables, you are not adding any security, just complexity, because the value that was submitted to the form processing page, just got copied to a session variable, then is being finally used the same as if it had been used on the form processing page. you are over complicating this.

the php mail function is NOT a mail server. it provides a way for php to interface with the sending mail server at your web hosting, typically though a sendmail binary program on the host system. on your web hosting, there is a mail server that is being used as the sending mail server. since it is unlikely that you are using google cloud web hosting (you probably would have mentioned this) and/or a gmail mail server (this requires smtp authentication, which the php mail() function does not support), the From: mail domain MUST correspond to the domain of your web hosting. you cannot just makeup and put in an @gmail.com email address.

technically, the posted code will work. that means there's something outside of the posted code that's preventing it from working. since you haven't done anything that was suggested or showed any of the requested code, i'm not sure what help we can give you.

^^^ this means that some receiving mail servers will and some won't consider a bad From: domain enough to categorize any particular email as junk. based on the only information you have given us, it's likely that for the emails you are sending, gmail and yahoo didn't flag them as junk, whereas outlook/hotmail does. my question was are you sending the emails using a gmail mail server? can you directly answer this question?

you would be getting at least a php error if the query didn't match any data. can you echo anything, just as a test, after the posted code? what is the rest of the code up to the point where you are tyring to echo $row['rc_date']? 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 would help you by reporting and displaying all the errors it detects? do you have any error handling for the database statements that can fail - connection, query, prepare, and execute? the simplest way of adding error handling, without adding code at each of these statements is to set the PDO error mode to exceptions when you make the database connection, then simply let php catch and handle the exception, where php 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.) something tells me you are running this code inside of a loop, which could be the cause of the apparent incorrect operation, depending on how you are fetching the data and where you tried to echo it. you should instead query for all the data you want in a single query.

you are listing the From: email address @gmal.com. is your web hosting actually using a gmail mail server to send these emails? edit: if you are not sending the emails from a mail server that can be related back to the From: mail domain, different receiving mail servers will mark the mail as junk and may not even process it. for the code that @JacoSwanepoel posted, the from email address is probably related to the mail server that is being used to send the emails.

which may not have any rows at all for some of the dates, ergo you need to fill in those dates.

so, you always want to display data for the entire history of the stored values? how are you going to display this much information, since no human is going to want to look at thousands and tens of thousands of values on a web page?