mac_gyver

that's not a valid opening php tag. it should be <?php (no space)

if you have a wp based query/code that you need help with, you will need to post it. if your goal is to use the wpdb class or the PDO extension, there's no point in wasting time with the mysqli extension. note: you can use the PDO extension within WP, by getting the WP configuration connection credentials and making your own PDO connection. using the try it, throw it away if it doesn't work, try something else method doesn't result in any actual learning and takes a long time, sometimes never, to accomplish any programming. if something doesn't work, you need to find out why, both so that you will learn what was right or wrong with your understanding of the attempted solution and so that you can keep the parts that work and just do the work needed to fix the part(s) that don't work. if this is asking about developing and testing the actual sql query statement, do this directly against the database using a tool like phpmyadmin, which i'm guessing the image at the top of this thread is the result of. if this is asking something else, please clarify.

aside from something preventing this from working, there's two problems with trying to maintain a value this way - it's not concurrent safe/atomic. if more than one instance of your script is requested at the same time, they will all get the same starting value, modify it, and update it to the same ending value, resulting in only one instance of the value being modified. if you did have a need to do this, you would do it all in one single UPDATE query, which will work properly regardless of how many concurrent instances of the script is running, since the database will get the existing value, modify it, and save it while doing the necessary table locking so that this occurs during one 'atomic' operation. you should insert a row for every transaction that affects a value, so that you will have an audit trail that would let you known if a programming mistake, an accidental key press, or nefarious activity has modified the value. you would simply SUM() the +/- amounts from the relevant rows for any particular account number to get the current amount, just like your bank, credit card, utility account, ... does.

this is the first time i/we have seen this problem. it wouldn't be anything MySql is doing since it results in an error. most likely something between the point where you are logging the value and where it is being sent to the database server. the only thing that comes to mind that results in a three character time zone value is the date 'T' format character. could this value actually be coming from some sort of date/time picker, rather than that date() call you are showing? it would take seeing all the code needed to reproduce the problem.

in your previous thread on this forum, you successfully built, prepared, and executed a prepared query with a ? place-holder in it. did you not learn anything by doing that? you are doing the same thing here, just with a different sql query statement. some points about what you are showing us (applies to the previous thread's code too) - don't make, then destroy a database connection inside of every method call. instead, your main code should make ONE connection for the whole application and use dependency injection to supply that connection to any class that needs it. once you do this, you would have a class property for the connection, that you would use when needed. both the prepare() and execute() calls can fail with an error. however, for a SELECT query, these would be due to a programming mistake or a problem with the database server. both of these are fatal problems for a SELECT query. there's no good reason to have ANY code to handle an error for a SELECT query. you should also use exceptions for ALL database statement errors. the PDO connection already always uses an exception for an error, you might as well use exceptions for query, prepare, and execute errors too. and in fact, in php8 the default error mode has been changed to use exceptions, so your current conditional logic won't do anything anymore and should be removed for a SELECT query. the only database statement errors that the visitor to a site can do anything about are when inserting/updating duplicate or out of range user submitted data values. this is the only case where you should have database statement error handling, which when using exceptions for errors is in the form of try/catch logic. the catch logic would test the sql error number and if it is for anything that the user can recover from, setup a message telling the user exactly what was wrong with the data that they submitted, so that they can potentially submit a different value that will succeed. when you make the connection, you should - set the character set to match your database tables. set the error mode to exceptions, set emulated prepared queries to false. set the default fetch mode to assoc so that you don' t need to specify it in each fetch statement. Keep It Simple (KISS.) lastly, return is not a function. the () do nothing and are unnecessary typing. once you do these things, the code simply becomes - protected function getSample($numLocations) { $stmt = $this->pdo->prepare(' SELECT * from tblRouteQuiz ORDER BY RAND() LIMIT ?'); $stmt->execute([$numLocations]); return $stmt->fetchAll(); }

firstly, it's generally a bad idea to store files in a database. the extra work you have to do to get them in and every time you retrieve them is not worth the trouble. also, when you create a .sql dump of a database, blob data is output as hex, requiring twice as many character-bytes as the actual blob data. simply store the files in the filesystem, that's what it's for. do you have error handling for all the database statements that can fail - connection, query. prepare, and execute, so that you will know if and why they are failing? without any error handling for the execute call, the number of affected rows won't be 1 if the execution of the query fails. the simplest way of adding error handling for these 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.) 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); if you read the php.net documentation examples for mysqli stmt send_long_data(), you will find that you should loop to read and send the file in chunks if the size of the file (actually the total size of all column values) exceeds the max_allowed_packet setting on the database server. this setting can be set to anything on any particular database server (the default size has changed from 1Mb to 64Mb over time.) you need to validate/test the size of the uploaded file so that you will know if it will fit in the defined size of the database column (if it's too large, that's a user error and you should setup a message telling the user what was wrong with the data that they submitted and not attempt to use the data in your code) , and you also need to loop to read chunks of the file and call send_long_data() multiple times. some additional points about the code - if the total size of the form data exceeds the php post_max_size setting, both the $_FILES and $_POST arrays will be empty. your code MUST test for this condition before referencing any of the form data you MUST make sure that the file actually uploaded without any errors before using any of the uploaded file information. the ['error'] element will be a zero (UPLOAD_ERR_OK). you should actually set up user error messages for all the possible ['error'] values. they can be found in the documentation. if you are going to read the file using code, you need to first use is_uploaded_file() to make sure that the file was actually uploaded through the server/php. the ['type'] value comes from whatever submitted the data to the web server, it can be nefariously set to anything and cannot be trusted. you should always determine the mime type of the actual uploaded file using your own code. if you do have a case where a value can be one of several different choices, put the choices in an array, then use in_array() to test if the value is one of the possible choices. the redirects indicate that the form and form processing code are on different pages. if you put them on the same page, it will simplify all the code, provide a better user experience, and be more secure. since you are redirecting (assuming that they are 'working'), the $msg variable in the posted code isn't doing anything. you should actually put user/validation errors into an array variable, using the field name as the array index. then test and display the contents of this variable at the appropriate location in the html document.

PDO has a fetchAll() method that fetches all the rows of data from a query at once, and you should set the default fetch mode to assoc when you make the database connection so that you don't need to specify it in each fetch statement. also, based on the whole query posted elsewhere, this is not a prepared query. there's no actual place-holders in it. the only reason it isn't producing an error is probably because you are using an emulated prepared query. when you make the connection you should set emulated prepared queries to false, i.e. you want to run real prepared queries. your function getSMSUsers, should only get and return the data. it should not also be responsible for producing any of the presentation output, nor should any function actually echo/print any output they produce, only return it so that the calling code can us it in whatever context it is being used in.

Nmbr_value and Nmbr_Value are not the same. php is case-sensitive concerning variable/property/associative index names. consistency counts in programming. always using all lowercase identifier names won't have you trying to remember what they should be.

here's a data driven example. tested with some fake data for the 1st form field and id field. requires coding for other field types. <?php // data-driven example // update table name $table = 'contacts'; // define update fields $fields = []; // notes: // the array index is the field name // label is the visible label for the field and is also used when building error messages // type is the form field type. this allows different processing code for the different field types, using a switch/case statement. // choices are for checkbox, radio, and select/option fields. these can be used to dynamically produce the form fields, and are used when validating the submitted data. can be entirely left out for other field types. // required is either true or false and determines the required (non-empty) validation // update_set and update_where being true or false determines where the field is used when building the query // elements that can be true or false can be entirely left out for the false case. // add elements to this definition and the corresponding code as needed for each different situation // i have guessed as to the type and required value for the first field for demonstration purposes $fields['current_living_situation'] = ['label'=>'Current Living Situation','type'=>'text','choices'=>[],'required'=>true,'update_set'=>true,'update_where'=>false]; // here are empty definitions for the rest, to get you started /* $fields['personal_strengths'] = []; $fields['skills_training'] = []; $fields['currently_spend_time'] = []; $fields['personal_goals'] = []; $fields['housing_situation_transport_childcare'] = []; $fields['learning_actual_end_date'] = []; $fields['partcipant_complete_course'] = []; $fields['withdrawal_reason'] = []; $fields['participant_intended_learning'] = []; $fields['pcp_education'] = []; $fields['coursestart_date'] = []; $fields['education_provider_name'] = []; $fields['course_title'] = []; $fields['course_level'] = []; $fields['planned_glh'] = []; $fields['in_paid_employment'] = []; $fields['in_paid_employment_start_date'] = []; $fields['in_paid_employer_name_address'] = []; $fields['in_paid_job_title'] = []; $fields['in_paid_contracted_hour'] = []; $fields['not_in_paid_employment'] = []; $fields['pcp_gap_year'] = []; $fields['pcp_others'] = []; $fields['pcp_voluntary_work'] = []; $fields['destination_progression_date'] = []; $fields['destination_progression_collection_date'] = []; $fields['project_officer_name'] = []; $fields['project_officer_signature'] = []; $fields['project_officer_date'] = []; $fields['participant__name'] = []; $fields['participant__signature'] = []; $fields['participant__date'] = []; $fields['final_assessment_progress_you_made'] = []; $fields['final_assessment_progress_your_goal'] = []; $fields['final_assessment_progress_your_reach_goal'] = []; $fields['final_assessment_progress_overall'] = []; $fields['final_assessment_participat_name'] = []; $fields['final_assessment_participat_signature'] = []; $fields['final_assessment_participat_date'] = []; $fields['final_assessment_project_worker_name'] = []; $fields['final_assessment_project_worker_signature'] = []; $fields['final_assessment_project_worker_date'] = []; $fields['learning_opportunities'] = []; $fields['contact_for_other_purposes'] = []; $fields['empowering_communities'] = []; $fields['empowering_communities_name'] = []; $fields['empowering_communities_sign'] = []; $fields['empowering_communities_date'] = []; $fields['participant_enrolled_onto'] = []; $fields['participant_moved_another_provider'] = []; $fields['participant_eligible_free_school'] = []; $fields['british_passport'] = []; $fields['eec_passport'] = []; $fields['euss_via_home'] = []; $fields['preferred_evidence'] = []; $fields['provide_preferred_evidence'] = []; $fields['option_adoption_vertificate'] = []; $fields['option_driving_licence'] = []; $fields['option_non_eu_passport'] = []; $fields['option_biometric_immigration'] = []; $fields['option_current_immigration'] = []; $fields['option_marriage_civil_partnership'] = []; $fields['option_other_evidence'] = []; $fields['option_nine'] = []; $fields['details_evidence_provided'] = []; $fields['dwp_job_centre_letter'] = []; $fields['confirmation_relevant_organisation'] = []; $fields['self_certification_evidence'] = []; $fields['partcipant_told_support'] = []; $fields['participant_file_completed_remotly'] = []; $fields['declaration_name_please_print'] = []; $fields['declaration_job_title'] = []; $fields['declaration_organisation'] = []; $fields['declaration_signature_date'] = []; $fields['declaration_signature'] = []; */ // note: if you get an error for this field, it's due to either a programming mistake or something submitting their own data w/o an id $fields['id'] = ['label'=>'Contact ID','type'=>'hidden','choices'=>[],'required'=>true,'update_set'=>false,'update_where'=>true]; // make database connection here... $post = []; // array to hold a trimmed working copy of the form data $errors = []; // array to hold user/validation errors // post method form processing code if($_SERVER['REQUEST_METHOD'] == 'POST') { // trim all the data at once $post = array_map('trim',$_POST); // if any of the fields are arrays, use a recursive trim call-back function here instead of php's trim function // validate inputs // required validation foreach($fields as $field=>$arr) { switch($arr['type']) { case 'text': case 'hidden': if(($arr['required'] ?? false) && $post[$field] === '') { $errors[$field] = "{$arr['label']} is required."; } break; } } // add other types of validation here, such as checkbox, radio, select/option choice... // if no errors, use the submitted data if(empty($errors)) { $set_terms = []; // array to hold each set term $set_params = []; // array to hold prepared query set inputs $where_terms = []; // array to hold each where term $where_params = []; // array to hold prepared query where inputs // build sql update query foreach($fields as $field=>$arr) { if($arr['update_set'] ?? false) { $set_terms[] = "`$field`=?"; $set_params[] = $post[$field]; } if($arr['update_where'] ?? false) { $where_terms[] = "`$field`=?"; $where_params[] = $post[$field]; } } $where = !empty($where_terms) ? " WHERE ".implode(' AND ',$where_terms) : ''; $sql = "UPDATE `$table` SET ".implode(',',$set_terms).$where; $stmt=$pdo->prepare($sql); $params = array_merge($set_params,$where_params); $stmt->execute($params); } // if no errors, success if(empty($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 here, // then test, display, and clear that session variable at the appropriate point in the html document die(header("Refresh:0")); } } // get method business logic - get/produce data needed to display the page // trim and validate the get id input $get_id = isset($_GET['id']) ? intval(trim($_GET['id'])) : 0; if($get_id < 1) { $errors['get_id'] = 'Input id is not valid.'; } // query for and fetch the initial data needed for the page, if there is a valid get_id and the form has never been submitted if(empty($errors['get_id']) && empty($post)) { $sql="SELECT * FROM contacts WHERE id = ?"; $stmt = $pdo->prepare($sql); $stmt->execute([ $get_id ]); if(!$post = $stmt->fetch()) { $errors['get_id'] = "Contact doesn't exist for the submitted ID!"; } } // html document starts here... ?> <?php // display any errors if(!empty($errors)) { echo "<p>".implode('<br>',$errors)."</p>"; } ?> <?php // display form echo "<form method='post'>\n"; foreach($fields as $field=>$arr) { switch($arr['type']) { case 'text': $req = ($arr['required'] ?? false) ? ' required' : ''; echo "<label>{$arr['label']}: <input type='{$arr['type']}' name='$field'$req value='".htmlentities($post[$field] ?? '',ENT_QUOTES)."'></label><br>\n"; break; case 'hidden': echo "<input type='{$arr['type']}' name='$field' value='".htmlentities($post[$field] ?? '',ENT_QUOTES)."'>\n"; break; } } echo "<input type='submit'>\n</form>\n"; for the code needed for other field types, pick one field of a new type and get it working completely. once you have code for each different field type, fill in the $fields definitions.

based on the posted code, the reason for that field not updating is clear. you are assigning the result of the isset() test to - $contact['learning_opportunities'], not $learning_opportunities, like you miss-posted at the top of this thread. this should have been producing an undefined variable error at the use of $learning_opportunities in the execute() call. is your php's error_reporting value set to E_ALL so that all php errors are being reported? edit: here's another issue. except for unchecked checkbox/radio buttons, all form fields will be set once the form has been submitted. by using isset() for these always set fields, you are hiding simple typing mistakes and adding to the wall of unmaintainable code. the only isset() statements should be for the cases of checkbox/radio fields.

after you find and fix the current problem, you need to switch to use a data-driven design, where you have a data structure (array, database table) that defines the fields, labels, types, validation, and processing (which fields are part of the set or where term in an update query) that you then loop over to get the computer to do the work for you, rather than doing assembly line typing out of code for every field. Edit: doing this will also eliminate the need to create and manage verbose variable names. Edit2: based on the wall of code you have, perhaps using a data-driven design might be the first step toward produce mistake free code, not the second step.

the code you have posted is not your actual code, and it's likely that the apparent sql syntax error is not really present, since you state other fields are working. there's a different list and order of fields in the query than the values that are being supplied when the query is executed. you are probably updating the checkbox value into some other column. post your actual code to get help with what is wrong with it. you also have a mistake in that the value attribute for this particular checkbox is not the string "Yes" that you think it is in the code setting the checked attribute. when you make the connection, you should also set emulated prepared queries to false (you want to run real prepared queries), and set the default fetch mode to assoc (so that you don't need to specify it in each fetch statement.) lastly, there's no good reason to catch the connection error, then rethrow it with only some of the values. you are loosing the line number and file name by doing this. simple remove the try/catch logic for the connection and let php directly handle the connection exception. the only time you should catch an handle a database exception in your code are for errors that the visitor can recover from, such as when inserting/updating duplicate or out or range data values.

this is generally a symptom of something being output to the browser prior to the headers. if this is the case, there would be a php error at the headers stating where the output was started at. is php's error_reporting set to E_ALL and log_errors set to ON, preferably in the php.ini on your system, so that php would log all error? if so, check the web servers error log file. what code is there before the headers? could it be outputting anything to the browser, such as upon an unexpected received value? also, for the screenshot, for the file in question, if you open the original or a successfully downloaded copy of it, it in your programming editor, does it start with exactly the same characters as in the screenshot?

see this post - also, don't select all the columns and all the rows to get a total count of rows/pages. use a COUNT(*) query and you don't need an ORDER BY term in this query.

it means only write code that contributes something useful to what your application is trying to accomplish. for connection errors and errors from query(), prepare(), and most execute() calls (except for duplicate or out of range errors when inserting/updating user submitted data), there's nothing the visitor to your site can do to recover from the error, they are due to programming mistakes or a database server that's not running, ... therefore, there's no point in writing any code for these cases. just let php catch the exceptions in these cases and display (when developing code/query(ies)) or log (when on a live/public server) the actual error information, so that you, the programmer/developer, will know when these type of errors are occurring, so that you can find and fix what's causing them. the only types of database errors that the visitor to a site can do anything about are when inserting/updating duplicate or out of range visitor submitted data. this is the only case where having database error handling code in your application will do anything useful. you would catch the database exception, test the error number, setup a message telling the visitor exactly what was wrong with the data that they submitted, so that they can potentially submit a different value that will succeed.

there's no good reason to have a try/catch block for the connection code. this is just typing for nothing. a connection error is a fatal problem for a database dependent web page. just let php catch any connection exception, where php will 'automatically' display/log the connection error for you. Keep It Simple (KISS.)

the ~3500 lines of phpmailer code should not be in-line in your file. they should be in external file(s) that get required by the main file. i see that you have hard-coded the to: and subject: values in the code. these and the still present 'sendmethod' should have never come from the form. i recommend that you delete any remaining logic using the 'sendmethod' value. this code is using ajax to submit the form data, therefore nothing the server-side post method processing code does to try to redirect will have any effect on the form page. it would take javascript code in the ajax completion code ( if ( request.readyState==4 ) { ) to test a value returned to it by the server-side code to either display a message or take an action, such as redirecting to a different page.

VSC reporting that the function is not defined is because VSC is not smart enough to know that the function can be defined in a separate file or if the code you posted at the top of this thread is an accurate arrangement of code in a single file (doubtful now), that you can define a function anywhere in a php project with respect to where it is called, provided it's not conditionally defined or conditionally required/included (the first two cases I posted.) You have been side-tracked by VSC's reporting of a problem that doesn't actually exist. You are going to have to actually learn the fundamentals of php programming so that you are smarter then the Microsoft tool you are trying to use.

relying on a Microsoft product as a programming aid is foolish. if you are not posting actual errors that you got from PHP on your localhost web server when you tried to run your code, you are wasting yours and our time. if you are not posting, copy/pasting, your actual code, you are wasting our time as well.

the posted code contains a php syntax error (a closing ?> tag inside the function definition) and doesn't run at all, so that's not the actual code producing that error. a few possibilities why the function definition is not present in the current program scope - the function definition is inside of a conditional statement, and so isn't defined until the code where that statements is at has been executed and the conditional statement is true. the function definition is inside of another function definition, and so isn't defined until the parent function has been called. the function definition is being required (you should use require for things your program just have) using a url, not a file system path, and is not in the same instance of your program as the function call. after you correct the php syntax error, the posted code produces an undefined constant error because the function call is before the point where the constants are defined. it would take seeing the actual code producing the error to help with what is wrong with it.

if you use the email address, that was just created for you at your web hosting, as the To: email address, you can probably get the mail() function to work.

gmail has recently stopped accepting emails that are being sent by unknown, unauthenticated email clients/systems, such as a sending mail server at some random web hosting. you must generate an OAuth token and use it to authenticate when sending to gmail. see the following post and thread it is in - prior to this, you were required to use smtp authentication against your gmail mailbox, which the php mail() function does not support, so you need to use either the phpmailer or swiftmailer class in any case.

most database errors are fatal problems, due to programming mistakes, or due to data issues like have been listed in this thread. since there's no user interaction with this code, there's no case where a database statement error is recoverable by the non-existent user. therefore, all database statement errors should simply get logged. the simplest way of doing this, which requires no code in the application (the current catch logic, if it is being executed at all, is only logging the error message, it does not include the filename and line number where the error occurred, and it is allowing execution to continue when a fatal problem has occurred) is to use exceptions for database statement errors and simply let php catch 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.) the PDO connection already always uses exceptions for errors, but if there's tri/catch code present that isn't properly dealing with a connection error, it's not helping, and should be removed anyways. setting the PDO error mode to use exceptions, applies to all the rest of the statements - query, prepare, and execute. after insuring that this is being set, for what this application is for, any try/catch code should be removed so that php will catch the database exceptions.

as a separate post. this code is typical misuse of OOP. someone took a few lines of main code, building and executing an insert query, threw a class definition around it, then to make it 'work' had to add $this-> in front of everything, add a bunch more code to build the input properties, code to instantiate the class, code to call the various methods, code (if any) to test the returned values, and code (if any) to use the output properties. if this method gets called and there isn't a database connection (what the first few lines of code are testing), it means that the connection code doesn't have error handling that would have stopped the whole database dependent application from being executed upon a connection error, and for the rare cases where a connection was successfully made, but lost during execution of the code, the fatal php error that would have occurred when the non-existent connection was used should be getting logged to let you know what type of problems are occurring. edit: since the code is just returning in this case, and it's doubtful that the returned value is causing any sort of logging/reporting to occur, you will never know if this is the cause of the missing inserted data. this brings up an additional point for debugging the problem. php's error_reporting should be set to E_ALL and log_errors should be set to ON, preferably in the php.ini on the system, so that all php errors will get reported and logged. if the php/web server error log is empty, either this is not the case or the log file settings are not setup.

if the PDO error mode IS set to use exceptions, the $this->_debugOn code won't have any effect, since it won't ever get executed upon an error. if the PDO error mode is not set to use exceptions, the $this->_debugOn code will be executed, but it is then up to the application code to actually test and use those class properties. since this code apparently doesn't have a user interface, the $this->_debugOn code was probably only ever there for direct requests during developmental testing. for the the try/catch code to 'work' the PDO error mode must be set to use exceptions. there would be something in the database connection code using PDO::ATTR_ERRMODE and PDO::ERRMODE_EXCEPTION if this setting is on. without investigating (logging) what the actual sql syntax being built is and what is being supplied to the ->execute(...) call, there's no guarantee that this is an actual prepared query, and if an emulated prepared query is being used, sql special characters in a value can still break the sql query syntax if the character set that php is using is not the same as the character set of the database tables. posting the database connection code, less any connection credentials, would show the error mode setting, emulated prepared query setting, and any character set setting.