mac_gyver

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?

what range of zero count dates do you want to include? the current year? current month? current week? between the lowest and highest dates with count values, and if so, what overall range, because your query could match data from as long ago as you have data stored, 10 years, 20 years? you would typically retrieve the data into an array using the date as the array index, then produce and loop over the date range you want to display, testing on each date being looped over if there is an entry in the array of fetched data, getting it if there is, otherwise displaying a zero.

the form processing code and the form should be on the same page, so, there's no 'going back' to the form, because if you need to redisplay it upon validation errors, you are already on the page where the form is. to cause the form to submit to the same page it is on, simply leave the entire action="..." attribute out of the form tag. the form processing 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.

if the rename() call is failing, there would be a php error message. 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 report and display all the errors it detects? what is the actual file name used, so that someone could determine if something about it is not permitted or if it's actually being moved to somewhere you are not expecting?

you were given a detailed list here -

this is nonsense code. it contains lines of code that do nothing. the author didn't even know that a header() statement doesn't stop php code execution.

all that did was stop the code from being executed, since the form(s) are post method forms and the submitted data will be in $_POST, not $_GET. if you haven't studied (class, book, online tutorial) any fundamentals of php programing, you won't be able to debug any problems in code, nor will you be able to understand and make use of any replies in help forums. what learning resources are you using to come up with this code?

the OP has been told this multiple times. the OP has a database table with the downloadable file information in it and has also been told to use the id (autoincrement primary index) from this table as the value in the link, which can then be validated via a database query, which he/she has acknowledged seeing and has stated will be implemented.

i told you to open the downloaded file in your programming editor to see what is in it. whatever you are using to translate our replies into your native language is not working.

if you open the downloaded file in your programming editor, you will probably see a clue as to the problem.

in your previous thread on this forum, you were given a detailed list of practices that will greatly simplify and fix issues in this code. I recommend that you go back and read that information before wasting any more time trying to make this current code work.

seems like a (trick) question on a quiz? if you can only modify the posted code, the simple answer would be to build each <option></option> list (4 places) with only a single choice, with fixed value (hour/minute) you want, that's pre-selected.

you easily have 2 times too much typing in that code, and burred somewhere in all that you have a mistake with an else statement. you need to start with the basics and keep it simple. your login system should only identify who the user is, with one session variable to hold the user_id (autoincrement primary index.) it is also not up to the user to specify their role when logging in. aside from a parent registering their children, the role should be determined completely by data stored only within your system. you should query on each page request to find any other user information, such as a username or user permissions/role. here's a list of things that will greatly simply the code and other issues - every header() redirect needs and exit/die statement after it to stop php code execution. don't use $_REQUEST. use the correct $_POST, $_GET, or $_COOKIE variable that you expected data in. don't copy variables to variables for no reason. you should trim() all input data before validating data. validating separate inputs is not mutually exclusive, i.e. don't use elseif. validate all separate inputs at once. after the end of all the validation logic, simply test if the array holding the errors is empty to decide if you are going to use the submitted data. only put try/catch logic in your code for insert/update queries to handle duplicate or out of range errors. in all other cases there's no point in doing this since the user on your site cannot do anything about a database error. don't store plain-text passwords. use php's password_hash and password_verify. simply supply an array of the input values to the PDO execute([...]) specify the default fetch mode when you make the database connection so that you don't need to specify it in each fetch statement. don't use a loop to fetch data from a query that will at most match one row of data. just directly fetch/test the row of data. if you were able to fetch a row of data, you know that the conditions in the WHERE clause in the query are true. there's no point in having logic to test these same conditions. setting regular variables then performing a redirect, does nothing. if you want to display a one-time success message, store it in a session variable, then test, display, and clear this session variable at the appropriate location in the html document. when conditional 'failure' logic is much shorter than the 'success' logic, invert the condition being tested and put the failure logic first. this will make your code easier to read (which will help avoid the current error.) the only header() redirect you have inside the post method form processing code should be to the exact same URL of the current page. this will cause a get request for that page. this will prevent the browser from trying to resubmit the form data should the user reload the page or navigate away from and back to that page. if you want the visitor to be able to navigate to other pages, provide navigation links. you should have a single home/content page. if the current visitor is not logged in, display the non-logged in content. if the current logged in visitor is an administrator, parent, or swimmer, display the the appropriate content.

these statements are defining filesystem paths. on your development system this results in: SITE_ROOT being set to the folder - $_SERVER['DOCUMENT_ROOT']/job1212 and LIB_PATH being set to the folder - $_SERVER['DOCUMENT_ROOT']/job1212/include on your live site, the full URL of your web site has nothing directly to do with the filesystem paths (the document root value may in fact contain a portion of your domain/account name) that will be used by php to require those various files. what exactly is the filesystem structure within the document root folder on the live site for the main files and the include folder?

my 2¢. your offer table should hold the unique/one-time information about each offer. once you have inserted a row of data into that table it should only be updated in the case of a mistake in a value or its status changes, such as being marked as deleted. you need all the raw offer data to be stored in that table, giving you an audit trail, so that you can detect if a programming mistake, multiple form submission, or nefarious activity has inserted an incorrect offer. if a new offer supersedes or modifies an existing offer, that should be handled when the data is queried for or in the processing when it is fetched.

you have actually been give the answer - don't put function definitions inside of other function definitions.