mac_gyver

the WHERE clause in the UPDATE query does not identify a single row. the UPDATE query is repeatedly updating all the rows matching the class, term, and year value with the new data, so it first updates all three rows with the first row of data, the second row of data, then the third, leaving all three rows with the third/last set of data in them. when a row of data should be updated, what columns can contain new values and what columns identify the row of data? note: you won't include the columns that are in the WHERE clause in the SET ... list, because by definition, they won't have different values in them, because they are what identifies the row data. also, don't use columns that end in numerical sequences. this indicates that you are trying to threat the database as a spreadsheet, which will result in overly complicated code and queries to accomplish any task. your database design should have one row for each data item. you would have a (one) subject column and a (one) test score column. you would insert a separate row for each test/test score. such data would also have a datetime column that indicates when the test/test score occurred.

the existence or absence of a session is under the control of the client/script making the requests to your site. you cannot use session (or cookie) data to detect or control the login attempts, since the client/script can simply not propagate the session id (or cookie) between requests and they will get a new session. you must store the data needed to detect or control the login attempts in a database table. you have two pieces of identifying information from the requests, the ip address (where the request came from and where you will send the response back to, along with any session id cookie or remember me cookie token) and the username/email for the login attempt. you would store the datetime, ip, and username/email for each failed login attempt, as a separate row, in a database table. it is this data that you would test to detect and control the login attempts. also, you don't 'lock' the accounts, you rate limit the login attempts. if a user is already logged in, they should still be able to access the site, i.e. they are won't be attempting to login, since they already are logged in.

this is a sign that your php code isn't being executed, but is instead being output to the browser, where the browser is only 'rendering' the quoted string. what does the 'view source' in your browser show?

there's nothing wrong with the POSTED code (just tested.) errors like this are usually caused by copy/pasting code that's been published on the web, with smart/curly quotes, which then produce php errors since those type of characters have no meaning in php, but which get converted back to straight quotes when code gets posted on a programming help forum, and therefor work when tried. delete and re-type the line of code.

what output do you get, e.g. item #4 on my list? do you have php's error_reporting set to E_ALL and display_errors set to ON, in the php.ini on your system, so that php will help you by reporting and displaying ALL the errors it detects? stop and start your web server to get any changes made to the php.ini to take effect and check using a phpinfo(); statement in a .php script that the settings actually got changed to those values.

Php 101 - php is a server-side scripting language. do you have a web server with php installed? the php file must be placed in the web server's document root folder, which may have different paths/names depending on what operating system is in use and how you obtained and installed the web server/php. to run a php script, you must make a http(s) request to the web server. what URL did you use in your browser to request the file? it should be something like - http://localhost/1.php (for a localhost development system.) if is starts with file:///..., that's not a URL, that's a filesystem path, which means that you opened the .php file directly in the browser, which won't invoke the php language engine that's installed on the web server. if you made a http(s) request to a URL and got a blank page, what does the 'view source' of the page in your browser show? you can also check in your browser's developer tools, network tab to see what the response is.

at one per second, it will take 25 minutes to send all the emails. php scripts are not intended to run continuously. you would need to call set_time_limit(...) inside the loop to keep the script from fatally timing out and halting, but not using set_time_limit(0) so as to not prevent the script from stopping due to a programming mistake. this is normally done by queuing, in a database table, all the mail addresses to be sent to. having a cron job/scheduled task that runs at some reasonable interval, such as once a minute. the code that the cron job triggers checks if the queue has any unsent messages in it, loops, with a sleep() call inside the loop, to send fewer emails than the time to the next execution of the cron job, to prevent overlap, and marks each email in the queue as having been sent. e.g. with the datetime when it was sent. doing this, you would send ~50 email per minute, in 30 executions of the cron job.

you would have been getting php errors at the reference to the connection variable. php's error_reporting should always be set to E_ALL. when learning, developing, and debugging code/query(ies), display_errors should be set to ON. when on a live/public server, display_errors should be set to OFF, and log_errors should be set to ON.

what output are you getting on the web page? if it's a blank page, what does the 'view source' in your browser show? can you echo a string using php code? is your code doing any redirects that could discard any output from the web page if php's output_buffering is ON? 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? stop and start your web server to get any changes made to the php.ini to take effect and check that the settings actually got changed to those values by using a phpinfo(); statement in a .php script file. do you have error handling for all the database statements that can fail - connection, query, prepare, execute, and a few others? the simplest way of adding error handling, without adding conditional logic at each statement, is to use exceptions for errors and in most cases simply let php catch and handle the exception, where php will use its error related settings (see the previous paragraph above) 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);

almost none of that is what i wrote, and you must echo the id in the field array index for it to be output (check the view source of the output in your browser.) see the following example (uses made up checkbox data instead of sql query data) - // for debugging, examine the input data echo '<pre>'; print_r($_POST); echo '</pre>'; // post method form processing if($_SERVER['REQUEST_METHOD']==='POST') { // test if any checkbox is checked if(isset($_POST['weekday'])) { // get and loop over the checked checkbox ids foreach(array_keys($_POST['weekday']) as $id) { // access the timing field value echo "Weekday id: $id, Timing: {$_POST['timing'][$id]}<br>"; } } } // make up some checkbox data $days = []; $days[] = ['id'=>1,'name'=>'Monday']; $days[] = ['id'=>2,'name'=>'Tuesday']; $days[] = ['id'=>3,'name'=>'Wednesday']; $days[] = ['id'=>4,'name'=>'Thursday']; $days[] = ['id'=>5,'name'=>'Friday']; ?> <form method='post'> <button type='submit'>Submit</button><br> <?php foreach($days as $row) { $chk = isset($_POST['weekday'][$row['id']]) ? 'checked' : ''; ?> <input name="weekday[<?=$row['id']?>]" type="checkbox" <?=$chk?> class='weekday'> <?=$row['name']?> <br>Timing<br> <input type="text" name="timing[<?=$row['id']?>]" value="<?=$_POST['timing'][$row['id']]??''?>" class='timepicker'><br> <?php } ?> </form>

only checked checkboxes will be set. if no checkboxes are checked, $_POST['weekday'] won't be set and any reference to it will produce a php error. you must test if $_POST['weekday'] isset() before referencing it. next, to associate each timing[] field to the corresponding weekday[] field, you should use the id as the array index for both fields, and forget about using a value attribute for the checkboxes. after you have determined that $_POST['weekday'] isset(), you can get the ids/keys (see php's array_keys()), then loop over the ids and access the corresponding timing[] field values.

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 telling you why the setcookie() call is failing?

just because code produces the expected result under perfect conditions, doesn't mean that the code is finished and ready to be used. this code will fall apart when it has to deal with real-world inputs. this code needs to be completely rewritten to make it secure, provide a good user experience, to eliminate all the unnecessary variables, and to add useful validation logic and error handling, so that the code will either work or it will tell you why it doesn't.

this code always produced the list of posted undefined errors, but they were hidden due to php's error related settings not setup so that ALL php detected errors would be reported and displayed. basically, this code was developed on a system where php wasn't setup to help the developer write good code. the solution is to find and fix what's causing each error. for the first add-task error in this line - if ($_POST['add-task']) {. the generally correct way of detecting which of several post method forms has been submitted is to use a hidden form field, with a unique value in it that you can test and use to control what form processing code to execute. the post method form processing for the add-task, is not secure (none of the database code is), has no validation logic, is filled with copying of variables to other variables for nothing, is filled without verbose variable names, shouldn't unconditionally output raw database statement errors onto a web page, doesn't have any exit/die statement to stop php code execution, and should redirect to the exact same url of the current page upon successful completion.

the following appendices list the major changes to php - https://www.php.net/manual/en/appendices.php you will need to go through and make sure that your code isn't using any backward incompatible or removed features. the error you posted above has nothing to do with php version. it's due to output being sent prior to the session_start statement. correcting it would involve finding what the output is and eliminating it and/or organizing your code so that the session_start occurs before any output. if you want anyone here to help with your code, you will need to post it.

php variables are case sensitive. $_SESSION['test'] is not the same as $_SESSION['Test']. you would have been getting a php error to alert you to the problem. do you have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your development system, so that php will help you by reporting and displaying all the errors it detects? you will save a ton of time. most of the form markup is broken, and it's doubtful that you even have some of the shown input data. you need to trim, then validate all inputs before using them. if a 'required' input is not valid, that's an error and you should setup and display a user message rather then blindly attempting to use non-existent data. you should validate the resulting web pages at validator.w3.org to help find the mistakes in the markup. the user errors you do have are also not preventing the code needing the inputs from running, likely producing php errors and no result. $display_block is being overwritten by later code, so any user errors you may have setup are being lost. you need to store user/validation errors in an array, using the field name as the array index, then only use the input data if the array holding the errors is empty.

i was able to get the view page to display red, but could not get the audio file to play (probably a browser permission or timing issue.) i recommend adding logging code in both the alert and alert_generate files, with datetime, file, and action being performed so that you can see what the code is actually doing. for what this code is doing, there's about three times too much code and most of the markup is out of date, and even when it wasn't there's a huge amount of broken html present. if you rewrite it, the major things that will simplify it are - put the form processing code and the form on the same page. there's no need for the alert.php file, the ajax request to it, and requesting it when the submit button is pressed (which doesn't even mean that the form got submitted.) at the point of successfully completing the post method form processing code, you would set the alert status flag in the row in the alert database table. there's also no need for the alert_generate.php file and the ajax requests to it at 300 millisecond intervals. you are already causing the view page to be periodically reloaded. if the alert status flag is set when the page is requested, just output the markup needed to cause the page to display red, play the audio file, and reset the alert status flag. as already stated, put the database connection code into a separate .php file and require it when needed. switching to the much simpler and more modern PDO extension will simplify all the database code. the only time handling database statement errors in your application code will do any good are for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted values. since you are not dealing with these (you should use a run-once token to prevent multiple form submissions), there's no need for any database error handling logic in your code. just use exceptions for database statement errors and let php catch and handle any 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.) the code for any web page should be laid out in this general order (this would apply to the form processing/form page and the view page) - initialization post method form processing get method business logic - get/produce data needed to display the page html document the form processing/form page should - detect if a post method form was submitted. keep the form data as a set in a php array variable, then operate on elements in this array throughout the rest of the code, i.e. don't write out lines of code copying each form field to other variables for nothing. trim all the input data before validating it. after you do item #2 on this list, you can accomplish this with one line of code. validate all the inputs at once, storing validation errors in an array using the field name as the array index. note: there is no 'song' field in the form and those lines of code you have for it in the form processing code are/should be producing php errors. after the end of all the validation logic, if there are no errors (the array holding the errors will be empty), use the form data. use a prepared query when supplying external, unknown, dynamic values to the query when it gets executed. after using the form data (since that code could produce additional errors, if there are no errors, perform a redirect to the exact same url of the current page to cause a get request for the page. to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document. it is at this point where you would set the alert status flag in the alert database table. if there are errors at step #5 or #7, the code will continue on to display the html document, display any errors, redisplay the form, populating the field values with the existing data. any value you output in a html context should have htmlentities() applied to it to help prevent cross site scripting. you should validate the resulting web pages at validator.w3.org

how many rows are in the alert database table? this nonsense code assumes that there is one row of data, with an id of 1, is using a loop to retrieve the data from the table, and isn't doing anything to insure that the single expected row exists.

the following is the only documentation that i found - https://www.godaddy.com/help/send-form-mail-using-an-smtp-relay-server-953 so, first question, which type of hosting do you have, since it determines what hostname you use? next, you can get the phpmailer to use php's mail() by calling the isMail() method, instead of the isSMTP() method. if using the isMail() method, you would not use any of the settings. if using the isSMTP() method, i would not use the username and password settings.

your current code will always only output one form field, because count($hasil) is zero, and there's nothing in your code to cause more form fields to be output. if you are attempting to provide a way of entering a dynamic amount of data, this is typically done by outputting one form field, then using javascript to add a new (set of) field(s) upon pushing a button. if you want to do this without using javascript, you need to decide the maximum number of fields you want, then use that number to control the looping.

just post all your current code so that someone can actually help with what it is or is not doing, rather than guessing based on snippets of information.

you need error handling for ALL the database statements that can fail - connection, query, prepare, and execute. you currently don't have any error handling for the execute call, which would be telling you why the query is failing at execution time. the easiest way of adding error handling for all the database statements, without adding logic at each one, is to use exceptions for errors and in most cases 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.) this will allow you to remove the existing error handling logic, since it will no longer get executed upon an error. the exception to this rule is when inserting/updating duplicate or out of range user submitted data. in this case, you would catch the exception in your code, test if the error number is for something that your code is designed to handle, and setup a unique and helpful error message letting the visitor know what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php handle it. to enable exceptions for errors for the mysqli extension, add the following line of code before the point where you make the database connection, and remove the existing error handling logic you have now - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

the nested data structures and the statement of 'arbitrary expressions' indicates that you are expected to write a recursive function to do this and since you wouldn't have been given this assignment without first having covered recursive functions, what information has been covered prior to this assignment?

no display/a blank page from a php script is usually due to fatal parse errors or fatal runtime errors. this is throwing a fatal error, since $up_user is an object, $user doesn't exist, and you are trying to get the ->wallet property of that object. the likely (since we don't know the backstory about what you are doing) syntax should be $uploader_wallet = $up_user->wallet; do you have php's error_reporting set to E_ALL and display_errors set to ON, in the php.ini on your system so that php will help you by reporting and displaying ALL the errors it detects? you will save a ton of time.

you have far too much code for this task. it is filled with repetitive logic, copying of variables to other variables for nothing, and while it is adding user/validation errors to an array, it isn't testing that array for the main activity of executing the INSERT query, which is why it is always inserting the new data values. i recommend that you start over, with just the logic you need - Keep It Simple (KISS) and Don't Repeat Yourself (DRY.) you should make one database connection in your main code, then supply it to any function that needs it, as a call-time parameter. you should use the much simpler and more modern PDO database extension. you should also use exceptions for database statement errors (the PDO extension always uses exceptions for any connection error and starting with php8 always uses exceptions for the rest of the statements that can fail - query, prepare, execute, and exec.) your post method form processing code should - detect if a post method form has been submitted keep all the form data as a set, in a php array variable trim all the input data at once. after you do item #2 on this list, you can trim all the data using one single line of code validate each input separately, storing user/validation errors in an array, using the field name as the array index after the end of the validation logic, if there are no errors (the array holding the errors will be empty), use the submitted form data as already stated, the correct way of determining if uniquely defined database columns/fields are duplicate, is to just attempt to insert the data and test if the query produced a duplicate index error number in the exception catch logic. for all other error numbers, just rethrow the exception and let php handle it. since you have more than one unique field, it is at this point where you would execute a (one) SELECT query to find which fields contain duplicate values. you would add error messages to the array holding the user/validation errors for each field that is found to contain duplicate values. after the end of post method form processing logic, if there are no errors, redirect to the exact same url of the current page to cause a get request for the 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. if there are errors at step #5 or #7, the code will continue on to display the html document, display any errors, redisplay the form, populating the fields with any existing form data. any dynamic value that gets output in a html context needs to have htmlentities() applied to it to help prevent cross site scripting.