mac_gyver

the php mysqli extension on your system must be compiled to use the mysqlnd driver, for the get_result and a few other functions/methods to be available - https://www.php.net/manual/en/mysqlnd.install.php i'm not sure this can be accomplished just through the hosting control panel. you will know when you are successful when there is a mysqlnd section in the phpinfo() output on your system. if you cannot enable this, your choices are, rewrite the code to - use the much simpler, more consistent, and better designed PDO extension. it has no mysqlnd driver gotya's like this. eliminate the use of the mysqli get_result function/method, which will require you to use mysqli_stmt::bind_result, and a bunch of code to dynamically fetch data as a result set or do a bunch of typing for all the columns/variables you are selecting from each query. however, if you are going to go through this much work, for each query, you might as well just spend the time to do item #1. converting a mysqli prepared query to use the PDO extension is fairly straight forward - make the database connection using PDO, storing the connection in a variable uniquely named, such as $pdo, so that you can identify/search which code has been converted or not. the use of ? positional prepared query place-holders is the same between mysqli and PDO. change the $mysqli->prepare() calls to use the $pdo connection variable, e.g. $pdo->prepare(). take the list of variables you are supplying to the ->bind_param() call, and supply them as an array to the ->execute([...]) call. remove the bind_param() calls and the get_result() calls. fetch the data using one of PDO's fetch methods - fetch(), fetchAll(), ... note: if you are using a foreach() loop to iterate over the msyqli result object (from the get_result call), you can loop over the PDO statement object in exactly the same way. for a non-prepared query, you would just use the PDO ->query() method instead of the mysqli ->query() method, then fetch/loop over the data as described above. any use of last insert id, num rows, or affected rows would need to use the equivalent PDO statements.

aside from that query needing the columns you are SELECTing listed, nothing about that select query itself needed to be changed. didn't the previous pagination code cause the correct page 2, 3, ... content to be queried for and displayed? the initial sql query used a variable named $initial_page. what is the code setting the value in that variable? when you integrated the code that i gave into your existing code, did you make sure that the $initial_page variable was producing the expected result? hint: i intentionally kept the name for the page value the same throughout the code, rather than to use two different names for it. you will need to go though the code and reconcile any variable name differences for that value.

you need to use oauth authentication. here's a phpmailer page - https://github.com/PHPMailer/PHPMailer/wiki/Using-Gmail-with-XOAUTH2

wouldn't that mean that you need to investigate why it isn't working in order to find and fix what's causing the incorrect operation?

if you are interested in displaying a range of links around the current page number (there's no guarantee the OP even saw the post suggesting that), here's some example code - <?php // build pagination links: prev, 1, range around current page, total_pages, next // number of +/- links around the current page number $range = 3; // number of items per page $limit = 12; // get total number of rows using a SELECT COUNT(*) ... query $total_rows = 3121; // calculate total number of pages $total_pages = ceil($total_rows / $limit); // get current page, default to page 1 $page = $_GET['page'] ?? 1; // limit page to be between 1 and $total_pages $page = max(1,min($total_pages,$page)); // produce array of pagination numbers: 1, range around current page, total_pages, without duplicates, between 1 and total_pages $links = array_filter(array_unique(array_merge([1],range($page-$range, $page+$range),[$total_pages])), function ($val) use ($total_pages) { return $val >= 1 && $val <= $total_pages; }); // build pagination links $pagination_links = ''; // get a copy of any existing get parameters $get = $_GET; // produce previous $get['page'] = $page - 1; $qs = http_build_query($get,'', '&amp;'); $pagination_links .= $page == 1 ? 'prev ' : "<a href='?$qs'>prev</a> "; // produce numerical links foreach($links as $link) { $get['page'] = $link; $qs = http_build_query($get,'', '&amp;'); $pagination_links .= $link == $page ? "$link " : "<a href='?$qs'>$link</a> "; } // produce next $get['page'] = $page + 1; $qs = http_build_query($get,'', '&amp;'); $pagination_links .= $page == $total_pages ? 'next' : "<a href='?$qs'>next</a>"; // output pagination echo $pagination_links; note: your query to get the total number of rows should NOT select all the columns and all the rows of data. you should use a SELECT COUNT(*) ... query, then fetch the counted value.

if you are doing this for real, you would NOT actually update any values. you would just use a UNION query to calculate the current total, between the stock and the sales table, for each item_id you are interested in. actually using the oldest inventory first, is a fulfilment issue, not a stock/inventory quantity problem.

you don't have to add php to the windows path, unless you want to run the php Command Line Interpreter (CLI) anywhere outside of the folder the CLI is located in. if all you are doing is running the web server based installation of php, you don't have to set the windows path at all. you would have to set/change values within the web server configuration to use the correct php folder/version files. i would make a copy of all your document root files/folders, export all your databases to .sql files, remove the existing ampps installation, then install a free xAMP stack.

the session variable is being used to determine which row of data to query for and use to populate the form field values with. you should also use the session variable to determine which row to update. your current method, of trying to use a get parameter in the form's action attribute (which contains a programming mistake anyways), will allow anyone to update anyone else's profile, since this value can be set to anything anyone wants, not just what you have attempted to set it to in the code. all external data submitted to your web pages can come from anywhere, can be set to anything, and cannot be trusted. also, your form processing code MUST trim, then validate all inputs before using them. had you done so, with the current attempted method of passing the id through the form's action attribute, your code would be producing an error for the user alerting them that there's no input id, and it would also be producing errors for the mismatch in form field names that @Barandhas pointed out, helping you to debug the mistakes in the code. here's an additional list of issues with the code - require isn't a function. the () around the filename are unnecessary clutter and should be removed. every redirect needs an exit/die statement after it to stop php code execution. a header() does not stop php code execution. all the code on that page is being executed every time the page gets requested. the code to retrieve the exiting data should come after the post method form processing code, should only be executed if the form has never been submitted, should keep the fetched data as an array, and should fetch the data into the same named variable that the post method form processing code is using (which should also be an array), so that after the form has been submitted, the form data will repopulate the form field values, so that the user doesn't need to keep reentering the changes over and over upon an error. if the query to get the existing data doesn't match a row, that's error and you should setup and display a message for the user alerting them to this problem, rather than to display a blank edit form. don't copy variables to other variables for nothing. this is just a waste of your time typing. the only time you should copy variables to other variables is when the meaning of the data in the variable has been altered, e.g. when trimming data, ... don't attempt to detect if the submit button is set. there are cases where it won't be. instead, detect if a post method form was submitted. if there can be more than one form processing code on a page, use a hidden field with a different value for each form, then use those values in the form processing code to control which code to execute. keep the form data as a set, in an array variable, then operate on elements in this array variable throughout the rest of the code. trim all the input data at once. since you will be keeping it in an array variable, you can do this will one single statement. validate all inputs, storing validation errors in an array, using the field name as the array index. after the end of the validation logic, if the array holding the user/validation errors is empty, use the submitted form data. because the update query can result in duplicate data (any column that must be unique should be defined as a unique index in the database table), you need error handling for that query that will test if a duplicate index error number has occurred, then setup a message for the user telling them what was wrong with the data that they submitted, so that they can correct the problem and resubmit the form. if there are errors at item #10, the code would continue on to display the html document, where you would test the array holding the errors and display its contents if there are, and redisplay the form, populating the form field values with the submitted form data. to get the form to submit to the same page it is on, simply leave the entire action='...' attribute out of the form tag. apply htmlentities() to any value you output on a web page to help prevent cross site scripting. don't write out code for every possible value. for the select/option choices and the radio buttons, define the choices in arrays, than loop over these defining arrays to produce the markup. you can also use these defining arrays in the validation logic to insure that only a permitted choice was made. the first select/option choice is usually an empty value with text that serves as a prompt to select one of the actual choices. this is actually need for the 'required' attribute to work, should the existing data being edited be empty or not match one of the permitted choices. this also results in an easily detected value for the server-side validation logic to test for. when you switch to use prepared queries, you would also want to switch to the much simpler PDO database extension.

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.