mac_gyver

did you look at the 'view source' of the page as suggested? there's nothing php version specific in this code.

define: stopped working? what does happen and if you are getting a blank page, what does the 'view source' in your browser show? (the problem is probably the short-open tag no longer working.) next, don't do this without validating that $_GET['con'] is exactly and only a permitted value. by using directory traversal or remote code inclusion, i.e. including path information or a remote url in the value, anyone can cause your code to include any file on your server, and if enabled, any code in a remote file, because file_exists($id) will be true.

no. the most likely thing is php's output_buffering setting being previously ON, but now it is off, preventing things like the session_start() from working, combined with bad code not doing things like halting php execution following header redirects. there would be php errors.

the error is because the session variable doesn't contain a value. so, two things - code should ALWAYS validate inputs before using them. if a required input isn't valid, that's an error and the code should setup and display a message for the user telling them what is wrong and not attempt to use the input. you need to determine why the session variable doesn't contain an expected value. either it's not being set or it is being lost somewhere along the way. based on the name of that variable, this either has something to do with the user authentication/login system or a user permission system. do other things requiring user authentication/permissions work? there should be other php errors that will help pin point where the problem is starting at. is php's error_reporting set to E_ALL? beyond that, it would take having the code where that session variable is being set at through to the posted code in order to come up with specific things to look at.

here's a laundry list of items, repeating some already posted above - for a login page, you care - 1) that the current visitor is not already logged in, 2) that the trimmed email and password are not empty strings, and 3) that the email/password matches the email/password_verify() result. you don't care if the email address is properly formatted (in the registration logic, you do care.) in fact, the current code testing $email, the result of the filter_var() statement, will incorrectly report that the email was empty, when it is not properly formatted. the session_start goes near the top of the code in the initialization section, both for consistency and so that you can check if the current visitor is not already logged in before allowing access to the login form and the form processing code. require_once is not a function. the () are unnecessary clutter. also, the _once version takes more processing since php must check the table of already required files. post method form processing code should first detect if a post method form was submitted, then trim, and validate all the input data. you should trim all the post data at once, keeping it in an array variable, then operate on elements of this array variable throughout the rest of the code. htmlspecialchars is an output function. it is used when you output dynamic values in a html context. except for unchecked check-boxes/radio-buttons, all other form field types will be set after the form has been submitted. do not use isset() on these type of fields. the trimmed value will either be an empty string or it will contain the submitted value to use. when you add the error messages to the $err array, use the field name as the array index. this will let you perform any dependent validation steps only if there is not an existing error for the field and will let you test/output the errors adjacent to the corresponding field if you so desire. use the simplest logic/syntax available. boolean tests exist so that you can directly test things in conditional statements. you would test if the $err array is empty before using the submitted data and run the rest of the post method form processing code. at the appropriate location in the html document, you would test if the $err is not empty and display its contents. only catch database statement errors in your code for things that are user recoverable, such as inserting/updating duplicate or out of range values. in all other cases, simply let php catch and handle any database statement errors. if you do catch database statement errors in your code, do not unconditionally echo the raw error information onto a web page. when you make the PDO database connection - 1) set the character set to match your database tables, 2) set the error mode to exceptions, 3) set emulated prepared queries to false, and 4) set the default fetch mode to assoc. if you use ? prepared query place-holders, it will reduce the amount of typing and typo mistakes. the semi-colon ; on the end of sql query statements is not needed/used when executing them through php. if someone successfully authenticates who they are, but their account is inactive, you would want to specifically tell them that, so, you want to query for their row of data regardless of the IS_INACTIVE value. after doing the above item #18, the email column should be a unique index, so there's no point in having a LIMIT clause in this query. as already posted, don't use fetchAll, then use more code/variables to get/test a single row. just use fetch. you can directly test the result of the fetch statement, requiring no additional code. when conditional failure logic is much shorter than the success logic, invert the conditional test and put the failure logic first. this will result in clearer code. the login failure message should be added to the $err array, then displayed at the appropriate location in the html document. the only user value that should be stored in a session variable is the user id. you would then query on each page request to get any other user data. this will allow the other values to be edited and they will take effect on the next page request. after the end of all the validation/authentication logic, if there are no errors, redirect to the exact same url of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data if the user reloads that page or browses away from and back to the page. provide navigation link(s) to allow the user to go to any other page. example code showing these points - // initialization session_start(); // is the visitor already logged in if(isset($_SESSION['user_id'])) { // either redirect or output an error that you cannot access this page if already logged in die; // stop code execution } require "dbcfg.php"; //Create an empty ERRORS array $err = []; // array to hold a trimmed working copy of the form data. access elements in this array throughout the rest of the code $post = []; // post method form processing if($_SERVER['REQUEST_METHOD'] == 'POST') { // trim all the data at once (if any of the fields are arrays, use a recursive trim call-back function here, instead of php's trim function) $post = array_map('trim',$_POST); if($post['email'] === '') { $err['email'] = " - 'Email Address' cannot be empty."; } if($post['password'] === '') { $err['password'] = " - 'Password' cannot be empty."; } // if no errors, use the submitted data if(empty($err)) { $sql = "SELECT ID, PWORD, IS_INACTIVE FROM users WHERE EMAIL=?"; $stmt = $pdo->prepare($sql); $stmt->execute([ $post['email'] ]); if(!$row = $stmt->fetch()) { // email didn't match $err['login'] = "Invalid email and/or password"; } else { // verify hashed password if(!password_verify($post['password'], $row["PWORD"])) { // password didn't match $err['login'] = "Invalid email and/or password"; } else { // successful login // at this point, you would test and setup messages for things like IS_INACTIVE... // only store the user id in a session variable. query on each page request to get any other user data. $_SESSION['user_id'] = $row["ID"]; } } } // if no errors, success if(empty($err)) { // redirect to the exact same url of this page to cause a get request - PRG Post, Redirect, Get. die(header("Refresh:0")); // note: if you want to display a one-time success message, store it in a session variable, then test, display, and clear that variable in the html document } } // the html document starts here... ?> <?php //If the array is not empty, then return the errors back to the user if(!empty($err)) { echo implode("<br>", $err); } ?>

also, your login form processing code should log information at each failure point so that you know what is occurring. if the username check is failing, log that occurrence. if the password hash is failing, log that occurrence. hopefully, you already have error handling for the database statements that is logging db errors and are you using prepared queries so that any sql special characters in the submitted values won't break the sql query syntax? posting your code would get the quickest, most comprehensive solution.

does that mean they are receiving an invalid username/password error when they authenticate themselves or does it mean that they are not being seen as being logged in when navigating around on the site because the login session variable is not working?

that date format is not directly sortable. where is this data coming from/stored at? you should store dates in a YYYY-MM-DD format, which will allow easy sorting by the date, then output the date in the format that you want when you display it. if this data is coming from a database, sort it in the sql query. if this data must be sorted in php, you would use php's usort() function, with a call-back function to sort on the date field. if that incoming date format cannot be corrected at the source, i would first convert the format, all at once, to be YYYY-MM-DD, then sort the data, then format the date back to that format when you display it.

change the code to use arrays for the sets of data under each major category, rather than processing each list/site separately. write two new functions (keeping the old code as is.) the new add_all_subscribers_lists_array() function would build arrays of parameters inside the inner foreach() loop, then call a new add_subscriber_list_array() function once, after the end of the inner foreach() loop. the code in the new add_subscriber_list_array() function would loop over the arrays of input parameters, query for the data and build each .csv file, then call the wp_mail() function once, supplying an array of the attachments. of some concern is that the code is creating a new database connection for each list/site. are all these databases on the same database server, with the only difference being which database is selected? if so, the code only needs to select the database before each query, rather than create an entirely new connection for each list/site query. for the 7warriors .csv, the posted code only outputs three headings, but there are four columns of data. to fix this, you would define a specific $column_names array inside the 7warriors conditional logic.

if the order of the posted code is actually what exists, your validation logic is after the point where you are inserting the data. how do you expect this to prevent the insert query from executing? you would need to validate the data first, then execute the insert query if there are no validation errors. the simple way to do this is add any validation errors to an array, using the field name as the array index, then after all the validation logic, test if the array holding the validation errors is empty. if the array is empty, you would build, prepare, and execute the insert query. to display the validation errors, when you re-display the form, you would test and display the non-empty content of the array. next, validating each different input is not dependent on the result of the previous validation step. you should validate all the inputs at once, so that the visitor can correct all the validation errors at one time. you should also not use isset() for inputs that will always be set when the form has been submitted. only un-checked checkbox and radio buttons won't be set. by using isset() for the always set form fields, you are hiding programming/typo mistakes and cluttering up your code with unnecessary typing. you should trim all inputs at once, then use the trimmed values throughout the rest of your code. if your current code was in the proper order, you are validating the trimmed values, but using the original untrimmed values in the query. the simple way of correcting this is to keep the input data as an array, use array_map() to make a trimmed copy into a different, working variable (you want to leave the original $_POST data as is), then operate on elements in this working array variable throughout the rest of the code. finally, the header() redirect in your post method form processing code should be to the exact same URL of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data if the user reloads that page or browses away from and back to that page. the header() redirect also needs an exit; statement after it to stop php code execution. if you want the user to be able to go to a different page, provide navigation link(s.)

the most immediate problem is that the query didn't match any data (or possibly didn't execute at all, but there would have been another php error at the mysqli_fetch_array statement.) see the php.net documentation for mysqli_fetch_array's return value - https://www.php.net/manual/en/mysqli-result.fetch-array.php code should ALWAYS test if data was fetched from a query before trying to use the data, and setup a user message if there was no data. // at the point of using the data if(!$fetch) { echo 'no data was found.'; } else { // use the data here... } the most likely reason for no matching data is either because $_GET['id'] doesn't contain any value or the value it does contain doesn't match any data in the table. you should ALWAYS validate inputs to your code before using them. if $_GET['id'] isn't set, is empty, or doesn't contain an integer value > 0, that's an error. you should setup a user message in this case and not attempt to run the sql query. you should ALWAYS have error handling for statements that can fail. for database statements that can fail - connection, query, prepare, and execute, the easiest way of adding error handling, without adding logic at each statement, is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information, via and uncaught exception error (database statement errors will 'automatically' get displayed/logged the same as php errors.) next, don't put external, unknown, dynamic values directly into an sql query statement. use a prepared query instead. lastly, don't copy variables to other variables for nothing. this is just a waste of typing. just use the original variables.

it appears that php is not seeing or using the php.ini. there are a couple of common possibilities - the php.ini is actually named php.ini.txt, due to editing by a MS program, such as notepad.exe. have the file extensions been 'exposed' (a web search should show how to do this) on the computer, so that you actually see the whole filename.ext? when you browse to folders, do you see extensions like .exe, .txt. .dll? AFAIK, right-clicking on the php.ini and selecting 'properties' should show the actual full filename? if the php.ini is actually php.ini.txt, rename it to be just php.ini php doesn't report when there are syntax errors in .ini files, i.e. there is not a parse/syntax/reporting phase, just run-time errors for statements that fail when executed. how was php obtained and installed on the computer, i.e. has anyone else been editing the php.ini and could have introduced syntax errors in it?

are there any other extensions enabled in the php.ini that DO show up in the phpinfo output? check the web server's error log for any recent lines mentioning problems with loading the mysqli library/dll. also, delete and retype the mysqli in your line of php code in case it contains some non-printing or non-ascii characters, the result of copy/pasting, that are causing it to not be recognized by php.

you must find and set those three php error settings in the php.ini on your system, because - your main code file never runs upon a php syntax error, so putting the settings in your code won't do anything for this type of error. the display_startup_errors setting does nothing when in your php code because php has already started. while you are changing settings in the php.ini, find the output_buffering setting and set it to OFF. php's output buffering should only be used when you want to buffer output and it being on hides non-fatal php errors and any output from your code when you have header statements in your code. by putting these in the php.ini, you have one location where you can change them and you don't need to edit any code when you move your project to a live/public server. stop and start your web server to get any changes made to the php.ini to take effect and then use a phpinfo() statement in a .php script that you open as a web page to conform that the settings actually got changed in case the php.ini that you are changing is not the one that php is using.

did you stop and start your web server to get any changes made to the php.ini to take effect? also, is the php.ini that you are changing the one that php is using (there's a loaded configuration... line in the phpinfo() output that states what file is being used.) the phpinfo() output will also list if/when the mysqli extension is being successfully loaded.

the sample data, which was probably defined to demonstrate this issue, ran out of users that could perform role id 7 before reaching the role id 7 evaluation. when this occurs, you need to be willing to accept a less than ideal solution, by introducing a random element into the process. a general method would be to take the top n (n = 1, 2, 3, ...) initial entries in the $roles_array, shuffle it/them, and produce a 'current' array consisting with those shuffled entries and the remaining unshuffled entries and try to produce a solution using that data that satisfies all the roles that have required importance. repeat the shuffling for each n value at least n squared times to give the shuffling a chance to produce unique results (computers are not very good at doing things randomly.) after each shuffle, check if the key order has already been tried, by remembering the composite key sequences, that have been evaluated, in an array, by imploding the keys with some unique character, e.g. a | or similar. if the key order has already been tried, skip the current evaluation loop.

of topic, but please use var_export() when posting sample data.

this issue has nothing to do with any php version/change. it appears that the checkInput() function definition was just thrown around some main code, based on the number of undefined/uninitialized variables and on the result of the function processing not being returned to the calling code. the main problem causing the error is here - $serial->sendMessage("$senddata\r"); checkInput($senddata); what does supplying $senddata, which contains a string, i.e. the data that was defined to be sent by calling sendMessage(), have to do with calling checkInput? hint: checkInput($serial);

the error means that $serial contains a string, rather than an instance of a class. you would need to determine how a string got assigned to the variable.

php functions have (proper) black-box model local variable scope, so that you can freely write code for a function definition without needing to know what every variable is throughout the rest of the code base (wordpress has thousands of functions) in order to avoid conflicts and improper operation. the $pega variable inside the get_future_conferences function doesn't exist. if you had php's error_reporting set to E_ALL and display_errors set to ON, you would be getting an undefined variable error at the 'value'=>$pega line that would alert you to the problem. the $pega variable should be an optional (there are undoubtedly existing calls) call-time input to the get_future_conferences function, telling it what date to use to match future conferences. apparently the filtering code used by get_posts() uses the current date when no value is supplied.

this is a set of data where you will be operating on each element in the set in the same/similar way. arrays are for sets of data. you should be using arrays for the form fields and loop over the submitted arrays of data.

when you have more than about 2-3 form fields, you should use a data-driven design and dynamically validate and process the form data. based on the copying of post variables to discrete variables, apparently this information was not seen - at the point of populating form field values, again, if you have more than just a few of them, you need to switch to a templating system where you would supply an array of values as the input to the template, rather than use a discrete variable for each one.

unconditionally doing this will end up hiding programming mistakes and when hackers/bot-scripts submit form data that doesn't include expected fields. you would want to see (when developing) or log (when on a live server) the errors so that you know what is occurring and can fix problems. where exactly are the errors occurring at? if it is when you are populating form field values, before the form has ever been submitted, the ideal solution would be to use php's null coalescing operator at the point of using the value. however, your example above indicates you are copying post variables to discrete variables (inside the form processing code?). you should instead keep the form data as a set, in a working array variable, usually having been trimmed, then operate on elements of this array variable throughout the rest of the code. doing this supports dynamically validating and processing the data.

you would set php's error related settings so that all php detected errors are reported and logged. error_reporting should be set to E_ALL and log_errors should be set to ON. the mysqli_report line will then throw an exception upon a mysqli error which php will catch and log the actual error information. the above logic has no useful error handling. it should be logging unique and helpful error information for each separate thing that can fail, so that you can find and fix any problem that is occurring. when validating data, every if() conditional test needs an else branch so that code does something useful when the test fails. you should also not lump together tests in one statement. if the verifyTransaction fails, that's a different issue from duplicate data and for every possible return value from addPaymet, there should be a separate conditional test and logged information.

only the raw data values belong in the database table. the presentation markup is not part of the data and would be applied if/when you output the data in a html context.