mac_gyver

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.

the error about an undefined variable is the same problem at the start of your thread in a different help forum. php class methods have local variable scope. if the logic class is truly dependent on the data class, you would use dependency injection to make the instance of the data class available in the logic class. however, i doubt that is actually what you are trying to do. you need to post all the relevant code in order to get the best solution. based on the names you have given your classes, you have taken the data and processing for a task and surrounded each of them with class definitions. this is not OOP. OOP is not about doing a bunch of typing adding a bunch of defining and calling syntax, then adding $var-> or $this-> in front of everything in order to make it work. all this is doing is wasting time adding a layer to your code that adds no value to that you are doing.

and what exactly was the output that you got from those statements?

yes. you would create one page that accepts a $_GET variable as an input. you would test if the variables is set (see isset()), trim, validate that the value is an integer greater than zero, then securely use the value in an sql query to get the matching data to display on the page.

pagination involves two sql queries. the first one gets the total number of matching rows (including any join, where, or having terms), so that you can calculate the total number of pages, used when looping to produce pagination links and to test/limit the requested page number. the second one adds a limit term to the base query to get the requested page of data. it doesn't matter what your presentation code is doing with the data that it loops over. you are just producing some output for each pass through the loop. you should actually remove the database specific code from the html document, put it above the start of the html document, then fetch the data that the query matches into an appropriately named php variable. you would then test/loop over this variable where the database specific code is currently at in your html document.

It's possible that some of the data values that are not present for a one-way trip don't have an acceptable default value and/or are not allowed to be a null value in the database table definition, and the database server mode is now set to strict mode, which will cause an error for those columns, rather than truncating data to the nearest min/max value. this code doesn't have any (useful) error handling for the database statements that can fail and the one place it does have some, won't work, because the connection variable is missing from the msyqli_error(...) call. the easiest way of adding error handling for all the database statements, without adding logic at each statement, is to use exceptions for database statement 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 (database statement errors will get displayed/logged the same as php errors.) to use exceptions for errors for the mysqli extension, add the following line of code before the point where you make the one/single/first connection - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); i hope that this code is just part of an assignment and is not on a live/public server, because it has no protection against sql special characters in the data values from breaking the sql query syntax, which is how sql injection is accomplished. you should be using prepared queries when supplying external, unknown, dynamic values to a query when it gets executed.

this is a lot of unnecessary typing, processing, and evaluating the count() inside the loop statement is the slowest way to do this, just to convert an array of objects to an array of arrays (presumably you are doing something with $post_data on each pass through the loop) and to format the date/time. just originally fetch the data as an array of arrays, not of objects, and either format the date/time in the query or as a one-time operation on the fetched data.

no. the code using mysqli_fetch_xxxx statement is fetching a row of data from the result of the query, as an associative, a numeric array, or both (default is both), assigning the fetched row of data to the $row variable, then the while() conditional/loop statement is testing the true/false result from that fetch/assignment. this stops because when there is no more data to fetch, a false value is returned by the fetch statement. the while loop code works because the condition being tested changes from true to false when the end of the data is reached. the while loop code you proposed is assigning the whole array in $this->data() to $obj, each pass through the loop, which is always a true value for a non-empty array, so, the loop becomes a forever-loop. while (pun intended) you can make a while() loop loop over an array, the php function needed to do so has been removed in php8, i.e. there's no good reason to change from using a foreach() loop to loop over an array of data. what problem are you having by using a foeach loop that you are trying to solve?

these functions have multiple false return points, each with a different cause. to debug this, wouldn't you need to determine (display/log) which conditional branch has failed? you need to write a debugging function, that you can add to various points in the code, that will either display/log, depending on the value of a DISPLAY_DEBUG (or similarly named) defined constant, useful and unique information about each failure point. this code also has inconsistent error handling for the database statements that can fail - prepare() and execute() (yes an execute call can fail due to an error, such as when a hacker submits data exceeding the max packet size between php and the database server.) for some of the prepare failures, you do nothing, which would cause the function to return a null value and in another case you are explicitly returning a false value, meaning that the login failed. rather than to add error handling logic for those cases where it is missing and fix the one case that does exist, just use exceptions for database statement 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 (database statement errors will automatically get displayed/logged the same as php errors.) you would then remove the existing database error handling logic since it will no longer get executed upon an error, simplifying your code. the exception to this rule is when inserting/updating duplicate or out of range user submitted data (which you are not doing in the code posted in this thread.) in this case, your code would catch the exception, test if the error number is for something your code is supposed to handle, then setup an error message for the user telling then what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php handle it as already described. 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);

to define what quantities are/are-not available, for each item, you need an item_carton table - id, item_id, quantity, any other useful status/flag columns. there can be cases where there is more than one carton size for an item, i.e. 15, 25, either concurrently or as time passes. there can also be cases where a unit item cannot be bought, only a full carton. you would assume that unit items can be bought, unless overridden by an entry in this table. you would also need a status flag, somewhere, indicating if the available quantity is limited to the stock on hand, i.e. more of the item cannot be obtained. if an item has an entry with this flag set, you could query to get the available quantity and display it on the item add to cart page as the maximum quantity available. for your example, there would be a row with the noodle item_id and quantity 15 to indicate that a carton quantity of 15 is available for that item. the lack of a row indicating that unit items cannot be bought would indicate that unit items are available. when you search and list items on the add to cart page, you would left join the item table with the item_carton table to determine what can/can-not be bought for each item. for your example, you would list that single items and cartons with quantity 15 can be bought. you would need an inventory table that would have a row inserted for every transaction that affects the inventory of an item. to handle both carton and unit items, in addition to item_id and quantity columns, you would have an item_carton_id column (an id from the above item_carton table.) if this column contains a value, it indicates the row is for a carton and the quantity is the number of cartons. if this column does not contain a value, the quantity is the number of unit items. for your example, when the 30 cartons were received, a row with the noodle item_id, 30 for the quantity, and the corresponding item_carton_id from the item_carton table would be inserted. when the cart is finalized and converted to an order, you would insert a row into an order table, with the unique/one time order information, establishing an order id, and insert row(s) for the carton/unit items into an order_item table. the order_item table would have an item_carton_id column, the same as defined for the inventory table (you will end up doing a UNION query between the two tables to determine the current carton/unit quantity of item(s)). to determine if a full case needs to be opened and broken into unit items, you would then query to find the current unit quantity for the item id that was just inserted. if it is a negative value, you would then insert a row into the inventory table that deducts enough full case(s) and insert a row into the inventory table that adds that many case quantity of unit items. for your example, when the order is submitted, you would insert a row for one carton and two unit items into the order_item table. since there are initially no unit items in the inventory, the above logic would get a negative 2, determine that this requires one carton to be broken into unit items, insert a row to deduct one full carton from the inventory, and insert a row with 15 unit items into the inventory table.

is the partID column value unique? if it is, there's no point in looping to produce the form fields. if it is not, you would need to use array names for the form fields and use some unique id as the field indexes so that you can update more than one row of data. does your form have partUpdate and partID fields so that the php code will do anything? always validate input data before using it ($_GET['partEdit']) and don't put external, unknown, dynamic values directly into an sql query statement. if you did this for the SELECT query because of how hard it is to use the mysqli extension for a prepared query, switch to the much simpler PDO extension. do not pass unnecessary values through a form since all external data can be set to anything and cannot be trusted. query inside the form processing code to get the existing/old values. your post method form processing code must detect if a post method form was submitted before referencing any of the form data. next, if the total size of the submitted form data exceeds the post_max_size setting, both the $_POST and $_FILES arrays will be empty. you must detect this and setup a message for the user telling them that the form data was too large and could not be processed. after you have determined that there is data in $_FILES, you must test the ['error'] element to find out if the file was successfully uploaded or not. the current test of the ['name'] element is not sufficient, i.e. some of the possible upload errors will have a non-empty name, but there is no file to save. only if the ['error'] element is a zero (UPLOAD_ERR_OK) can you actually use the uploaded file information. if it's a 4 (UPLOAD_ERR_NO_FILE), it would mean that no image was selected to be uploaded. for the other error values that the user has control over, you would setup a message telling them what was wrong. for the error values that the user has no control over, you would setup a general failure message, and log the actual information about what error occurred. lastly, you ALWAYS need error handling for all statements that can fail. for database statements, the easiest way of adding error handling, without adding logic at each statement that can fail - connection, query, prepare, and execute, 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 an uncaught exception error (database statement errors will 'automatically' get displayed/logged the same as php errors.)

how do you know that? one possible reason for not seeing your connection error message, for the case of intentionally invalid connection credentials, is that your php code is not being executed, perhaps due to being directly opened as a file in the browser instead of being requested via a url on your web server. another possibility is that where you are trying to create the connection is inside of some html markup where any output from your code/php won't be seen unless you look at the 'view source' of the page in your browser (you should do any initialization like this, or any main php business logic, above the start of the html document so that you won't have an issue with things not being seen on a web page.)

or you can just use a database and write a simple sql query to find and retrieve the data that you want.

it's not exactly the same. when there are php variables inside of a string, the type of quotes around the string matter. double-quotes are required to get the php variables to be replaced with their values.

stock/inventory should be handled using an accounting/transaction ledger type system, where a separate row is inserted for every +/- transaction that affects a value. this will provide you with an audit trail so that you can tell if a programming mistake, duplicate submission, or nefarious activity has altered a value. you would then query to SUM() the +/- amounts for each item id to get the current stock/inventory amounts. when you submit the items making up an order/sale, you would insert a row into an order/sale table, with the unique/one-time information about the order. you would then get the last insert id from that query and use it when inserting the rows containing the item id/quantity into an order_item table.

there's no need to compare, in php code, the column value fetched from the query with the column value being tested in the where clause. if the query matched a row(s) of data, the where clause was true. next, if you are not actually using the row(s) of data that a query matches, i.e. you are only testing if a value exists or how many times it exists, use SELECT COUNT(*) ..., and if this is for a 'registration' script, where you are deciding if you are going to insert a row of data, instead, just define that column as a unique index, attempt to insert the data, then test if the query produced a duplicate error. lastly, if you switch to the much simpler PDO database extension, a majority of the lines of code will go away.