mac_gyver

unless you can have multiple images per weapon, now or in the future, you don't need a separate table for the images. if it is possible that a weapon doesn't have an image, you would either skip producing the markup for the image or display a general 'no image available' image instead. this php error message indicates that the query failed due to an error (or perhaps your full code is overwriting or using the variable for something else), and that you don't have any error handling for database statements that can fail. see my first post in this thread, point #5 about using exceptions for database statement errors. a) you should be using php8+ and b) you should set the error mode to exceptions for the database extension you are using if you are not using php8+. edit: i see that, at least in the documentation, a null is returned when there is no (more) data to fetch (it used to be a false value for this condition.) if so, this indicates that the query didn't match any data. if this is a case of no image for a weapon, you need conditional logic to test for an image or not and take an appropriate action in the code. the snippet of code and variable naming also implies you are executing queries inside of loops. this is extremely inefficient and is resulting in a wall of unnecessary code/query(ies). when you have related data in multiple tables, you need to use an appropriate type of JOIN query to get all the data that you want in a single query, then simply loop over the result from that single query to produce the output that you want.

did you look at the resulting markup in your browser's 'view source' of the page to see what might be wrong with it?

presumably, you have a weapon table, that holds the definition of each weapon, with damage value for each weapon? the total damage is a derived value. you would query/calculate it when needed. you would use a JOIN query, between the playeritem table and the weapon table, to SUM() the damage value for each weapon that the user has. some points about the posted code - you should trim all input data, mainly so that you can detect if it was all white-space characters, then validate it before using it. if an input is required to be non-empty or must have a specific format, don't use it if it isn't valid. don't copy variables to other variables for nothing. you should use a post method form when performing an action on the servers, such as when inserting, updating, or deleting data. don't put external, dynamic values directly into sql query statements, where an sql special character can break the sql query syntax. use a prepared query instead. if it seems like using prepared queries with the mysqli extension is overly complicated, it is. this would be a good time to switch to the much simpler and more modern PDO extension. don't use or die() for error handling. you should instead use exceptions for database statement error handling (this is the default setting now in php8+) and only catch and handle database exceptions for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted data. for all other query errors and other types of queries, simply do nothing in your code and let php catch and handle any database exception. don't create specific variable names for nothing. e.g. $reequip, $equip. the only variable names that must be unique are the result from any section of code that will be used elsewhere in the code. for these two variables, just use $sql or similar, since you will completely deal with one query before going on to do something else in the code. don't echo static markup. just drop out of php mode and put the markup inline.

the user registration/login system on your web site is for the purpose of determining what a user can see and do on the web pages. this has nothing to do with database connections. it is your application code that is performing the database operations and the database connection credentials are making a connection to allow your application code to do its work. it is up to your application code to determine what database operations can be performed for any user to your site. this is not how web applications are implemented. post or describe an example of something you think requires this, and a forum member will provide information on how to correctly implement it.

your login code should put the user's id (auto-increment primary index) into a uniquely named session variable, such as $_SESSION['user_id']. you would then test if that session variable is set on any page that requires a logged in user. you would query on each page request, using $_SESSION['user_id'], to get any other user data, such as the username, email, access type, ... don't do that. once you have the user's data, just test/use it on a single page to control what content gets displayed on the page and what action the user can perform on that page. since this query to get the access type will at most match one row of data, don't use a loop at all. just fetch/test the data. i reviewed your previous thread on this forum. you were using a single fetch() statement in it. what happended? this implies your db() function creates a new database connection every time it is called. don't do that. a database connection is one of the slowest operations you can perform on a page. your application should create one database connection, then use that single connection for every database operation on the page. don't do this. as of php8, the default setting for PDO error handling is to use exceptions for all the database statements that can fail - connection, query, exec, prepare, and execute. with exceptions, any discrete error check logic in your code won't ever get executed upon an error since execution transfers elsewhere. this is one of the great points of using exceptions. your main code will only 'see' error free execution. if execution continues past a statement that can fail, you know the statement was successful without needing conditional logic to test if it was or was not. this simplifies the code, allowing you to remove all the now unnecessary conditional logic. the only time you should catch and handle a database exception in your code is for recoverable user error, such as when inserting/updating duplicate or out of range user data. for all other error numbers and all other query types, just let php catch and handle any database exception. if you set the default fetch mode to assoc when you make the database connection, you don't need to specify it in each fetch statement, simplifying the code.

you logic makes no sense. $bob is an array. the comparison with == 1 'works' because a non-empty array is a true value that is loosely equal to 1. your goal should be to test the value in $bob['fk_usertypes_id'] also, is there more than one row of data matching the email address? if there is not, don't use the fetchAll() method and don't use a loop to loop over the data. just fetch the single row of data.

a space in an attribute value is a stop character, indicating the end of the value. to make this work, you need to enclose the attribute value in quotes (single or double.) you should actually always enclose attribute values in quotes, for consistency, even in those cases where they are not required. however, the value attributes should be the organization ids, not the organization names, so that when you store the submitted data, you are storing the organization id. this will result in the least amount of data storage, the fastest queries, and allow you to edit the organization name or even display the organization name in a different language, without affecting the stored data. next, for the 'required' attribute to work, the first option choice needs to have an empty value attribute and serve as a prompt, e.g. <option value=''>Select an Organization</option>. lastly, there's no good reason to catch and handle an exception from a SELECT query. any error from this type of query, is either due to a programming mistake or the database server is not running, is not recoverable by the user, and the user doesn't need to know anything about its occurrence. simply do nothing in this case and let php catch and handle any database exception from a SELECT query.

if you got an error, you need to post it. the $page_count variable doesn't exist, likely causing an undefined variable error, nor is it used anywhere in the posted code. you don't need to SELECT data in order to decide to insert or update it. just use an INSERT ... ON DUPLICATE KEY UPDATE ... query. you can use the MySql LAST_INSERT_ID(expr) function in the query to make the counts column value accessible via the expr (expression) argument without needing to execute another query. don't put external, unknown, dynamic values directly into an sql query statement. use a prepared query instead. if it seems like using a prepared query with the mysqli extension, this would be a good time to switch to the much simpler and more modern PDO extension.

the reason to use the name as the array index is this allows you to directly test for and access the entry in the array, without needing to search through the entire array. this is the same reason that you index data in a database. this greatly simplifies and speeds up the code/query. the reason your code doesn't work when the data starts at the zeroth index in the array is because array_search() returns the index if the value is found, but the zero index is a false value in a loose-comparison. array_search() returns an exact false value when the search fails to match a value. to test for a not-found condition, you must test if the returned values is exactly false, e.g. ===false. to test for a found condition, you must if the returned value is not exactly false, e.g. !==false.

the code is doing exactly what it was written to do, build a <tr><td>num</td></tr> for each number. if you want to produce a single <tr></tr>, you would need to add the opening <tr> before the start of the looping and add the closing </tr> after the end of the looping.

you can also use the BC math functions, which expects strings as input and operates on each character as a bcd digit, like a hand held calculator works.

instead of doing math, just explode the string on the '.' character, fill the cents part to two places with trailing '0' characters, and concatenate the two pieces together.

don't attempt to test if a submit button is set. there are cases where it won't be. one of these cases is if the total size of the form data exceeds the post_max_size setting on the server, both the $_POST and $_FILES arrays will be empty. you should instead test if a post method form was submitted - if($_SERVER['REQUEST_METHOD'] === 'POST'), then test if there is $_POST and/or $_FILES data, before referencing any of the form data. after you have tested that there is data in $_FILES, you must test the ['error'] element to make sure that the file upload was successful. there's a list of the possible error values in the documentation - https://www.php.net/manual/en/features.file-upload.errors.php after you have determined that the file uploaded without any error, you can test/use the uploaded file information.

programming is an exact science. when you have a whole web page that doesn't work, you need to post all the actual code, less any database connection credentials, necessary to reproduce the problem. there could be a dozen different things wrong that could cause this symptom. we need to see what your actual code is in order to concentrate on what the code is or is not doing correctly.

this is because as of php8 the mysqli (and PDO) extension uses exceptions for all database statement errors, by default, and execution transferred to the nearest correct type of exception handling (try/catch logic) in your code or to php's exception handling if there is no correct type of exception handling in your code, and all your code after the point where an exception occurred is not executed. a great point of using exceptions is that your main/inline code only 'sees' error free execution. if execution continues past a statement that throws an exception, you know that there was no error, without needing logic in your code to test if there was or was not an error. this lets you eliminate all the existing conditional logic in your code testing for connection and query errors, since it won't ever get executed upon an error, simplifying the code. because you didn't get any error indication at all, that means that php's error related settings are not set up on your system so that php will help you by reporting and displaying all the errors it detects. php's error_reporting should always be set to E_ALL and when learning, developing, and debugging code/query(ies), display_errors should be set to ON. when running code on a live/public server, display_errors should be set to OFF and log_errors should be set to ON. these settings should be in the php.ini on your system so that they can be set or changed at a single point. stop and start your web server to get any changes to the php.ini to take effect and check using a phpinfo() statement in a .php script file that the settings actually go changed to the desired values. the only time you should catch and handle a database exception in your code is for user recoverable errors, such as when inserting/updating duplicate user submitted data, which is something you are/should be doing. at a minimum, the email database column should be defined as a unique index. you would then have exception try/catch logic in your code around at least the execute() statement, check in the catch block if the error number is for a duplicate index error, and setup a message for the user that the email is already in use. for all other error numbers, just re-throw the exception and let php handle it. and if that wasn't enough, here's a list of practices, most of which will simplify the code - the form and form processing code should be on the same page. the code for any page should be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document. the post method form processing code should only test if the request method == 'POST'. this is because there are cases where the submit button won't be set. you should keep the form data as a set, in a php array variable, then operate on elements in this array variable throughout the rest of the code, i.e. don't write out line after line of code that copies variables to other variables for nothing. you should trim all user entered data, mainly so that you can detect if it was all white-space characters, before validating it. after you do item #3 on this list, you can trim all the data using one single line of code. you should validate all input data, on the server, before using it, storing user/validation errors in an array using the field name as the main array index. except for unchecked checkbox/radio fields, all form fields will be set once the form has been submitted. there's no good reason to have isset() statements for always-set fields, and in fact doing so hides typo mistakes. as @Barand has already pointed out, you should be using a prepared query and switch to the much simpler and more modern PDO extension. after successfully processing the form data, you should execute a 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 should that page get reloaded or browsed away from and back to. 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 get a form to submit to the same page it is on, leave out the entire action attribute. if you put the closing </label> tag after the form field it corresponds to, you can leave out the for and matching id attributes, simplifying the code and eliminate a source of typos. in the name form field, your for attribute doesn't match the id attribute. the closing / in tags is no longer used. you need to validate the resulting web pages at validator.w3.org the form should be 'sticky' and repopulate the form fields with any existing values/choices so that the user doesn't need to keep reentering data over and over upon an error. any dynamic value you output in a html context should have htmlentities() applied to it to help prevent cross site scripting.

to convert old mysql_ based code, you need to 1) convert the database extension to a currently supported one, 2) provide protection against sql special characters in a value being able to break the sql query syntax, which is how sql injection is accomplished, and 3) handle database statement errors. for item #1, the PDO extension is much simpler and more modern then the mysqli extension. for item #2, the simplest way of doing this is to use prepared queries, which provides protection for all data types. converting any query to a prepared query is straightforward - remove the php variables (keep these for later) and any single-quotes, {}, and quotes/concatenation dots that were used to get the variables into the sql query statement. put a ? place-holder into the sql query statement for each variable you removed. prepare the query. supply an array of the variables to the ->execute([...]) call. note: any wild-card search characters, typically used with a LIKE comparison, are part of the value, not part of the sql query statement. for item #3, as of php8, both the mysqli and PDO extensions use exceptions by default for all the database statements that can fail - connection, query, exec, prepare, and execute. this simplifies your code, since you can remove any existing error handling logic. the only database exceptions you should catch and handle in your code are for user recoverable errors, such as when inserting/updating user submitted data (which you are not doing in this case.) in all other cases, simply let php catch and handle any database exceptions, 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 not UPDATE amounts in a table to track this data, since that doesn't provide an accounting trail should a programming mistake, duplicate entry, or nafarious activity alter a value. these are derived amounts that you would calculate when needed. you would have an invoice_accounting (or similar named) table, that gets a row inserted for every amount that affects an invoice amount. you would query when needed (a UNION between the invoice(s) table and the invoice accounting table) to determine the current total +/-/0 for any invoice.

programming already is a tedious typing task. don't make it harder than it needs to be. buried within the unnecessary echoing of static html markup, is the problem. form fields must have a name='...' attribute for the value to be included in the submitted form data. here's a list of practices the will simplify and help secure the code - use 'require' for things your code must have for it to work to get a form to submit to the same page it is on, leave out the entire action attribute don't pass display messages or message flag values through the url, as this opens your site to phishing attacks any dynamic value you output in a html context needs htmlentities/htmlspecialchars applied to it to help prevent cross site scripting. you have some cases using this and some that are not the search form needs to be a get method form, it needs to be sticky and repopulate the field value with any existing data so that the user can just alter the value if a search didn't produce the result they were looking for the code for any page needs to be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document don't copy variables to other variables for nothing. just use the original variables you need to trim all user entered data, mainly so that you can detect if it was all white-space characters you need to validate all inputs before using them don't echo static css/html/javascript functions should return the result they produce, i.e. don't echo output inside a function, return it to the calling code don't use php functions, with css/html/javascript in them to build the html document use implicit binding and simply supply an array of input values to the PDOstatement ->execute([...]) call set the default fetch mode to assoc when you make the PDO connection so that you don't need to specify it in each fetch statement require/include are not functions. the () around the path/filename do nothing and should be removed

you should use a data-driven design, with an array that maps the data field to the database column, then dynamically build the sql query statement and get the data values, by looping over the defining array. this will prevent typos, mismatched entries,... and allow you to change what the code does simply by changing the defining array.

you also need to profile your code (calculate differences in microtime(true) values for the different operations on the page) to determine where it spends its time. i suspect that the time taken on the server isn't where the problem is, but in the execution of the javascript in the browser.

the code for any page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document all the database specific code you have on this page should be in section #3 in this layout. this makes it easier to write, test, and debug your code and query(ies), and now that you need to modify the code/query(ies), puts it all in one place. if you are only getting a count of the number of matching rows, don't select all the columns (SELECT *) and all the rows. use a SELECT COUNT(*) ... query instead, then fetch the count value. the three queries getting a count of the number of matching rows with status = 0, 1, and 2 can be done in a single query. you can get the SUM(amount) and COUNT(*), where the rest of the query is the same, in a single query. lastly, the json_encode() should not be inside the loops. this is repeatedly encoding the array after each row is added, leaving only the last result. this probably where the most time is being taken. the json_encode() statements should be after the end of the relevant loop.

there's a setting - https://www.php.net/manual/en/ini.core.php#ini.max-file-uploads

there are xAMP pre-built systems you can download and install on windows, e.g. https://www.apachefriends.org/

from a reply in your previous thread - also in your previous thread, two different forum members (ignoring the chatbot replies by the 3rd respondent in that thread) pointed out that you need to change all the short opening php tags to full <?php tags. i also use windows (10) for development, with PDO and php8.

the key/index for the 'a+' entry is 0. this is a boolean false value, so the if() logic branch is skipped. you need to perform an exact match for a non-false value. e.g. !== false