mac_gyver

most of the points will actually simplify the code e.g. putting the form processing and the form(s) on the same page will eliminate all those lines of code for the session variables. the only increase in code are for things that don't exist now that the code needs. i thought of two more things that could cause the code/query(ies) to work on one server but not another and you might not get any indication from the current code/configuration as to what the problem is - this has to do with the output_buffering setting (if it's on, turn it off) and using the procedural mysqli statements. the error response for the procedural mysqli statements is different from the OOP mysqli statements. things that would be a fatal runtime error, if using OOP, halting program execution, are just warnings, if using procedural statements, and the code will continue to run, which if output_buffering is on, will discard the php warning messages. this has to do with the database server's strict mode setting and having no error handling for the execute() calls. if strict mode is set to ON, on the cheep/free hosting, out of range values will produce an error, but since there's currently no error handling for the execute() call, you don't know if this is happening or not. using exceptions for errors will solve this since it will give you error handling for all the database statements that can fail. if strict mode is off, on your development system, out of range values will instead be truncated to the nearest legal value for the data type, without producing an error. i didn't state it previously, but switching to the much simpler, more consistent, and better designed PDO extension will also simplify the code.

there are a fairly large number of things that can cause your code to work on one system but not another and if your code is lacking validation and error handling logic, your code won't tell you why it is failing. under perfect conditions, on your development system, your code may work, but if anything goes wrong, you won't get any help from your code. firstly, you need to temporarily set php's error_reporting to E_ALL and set display_errors to ON, so that you will get immediate feedback if any php errors are occurring (the cheep/free web hosts may not allow you to do this.) you also need consistent and useful error handling for all the database statements that can fail - connection, query, prepare, and execute (which you don't currently have any error handling for.) the simplest way of adding error handling for all the database statements 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 (see the above paragraph) to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) this will let you remove the existing error handling logic and skip adding it where there is none. the exception to letting php catch the exceptions is when inserting/updating duplicate or out of range user submitted values, which is what you should be doing to detect if a product is already in the cart. in this case, your code should catch the exception, detect if the error number is for something that your code is designed to handle, then setup and display a message for the user telling them what was wrong with the data that they submitted. for all other error numbers, simply re-throw the exception and let php handle it. it doesn't appear that you have any validation logic? you should always trim, then validate all input data before using it. if there are no validation errors, use the submitted data. if there are validation errors, display them when you re-display the add product form(s). the only product information you insert into the cart is the product id and the quantity. all the other product data exists in the featuredlist table and should not be duplicated in the cart. you have a lot of unnecessary code that isn't helping. by putting the form processing code on a different page from the add product form(s), you have more code, a bunch of redirects, and are producing a bad user experience. when you put these on the same page, there will be less code, you can eliminate all but one redirect (upon successful completion), and you can display any validation/user error messages when you re-display the add product form(s). the only redirect you should have in your post method form processing code is upon successful completion of the processing code and it should be to the exact same url of the current page. this will cause a get request for that page. if you want the user to be able to navigate to other pages, provide navigation links. if you want to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document. as to another reason why your code may not work, on one system, but not another, and be giving the symptom of going back to the cart.html page - what does using a phpinfo() statement in a php script show for the output_buffering setting? because you are redirecting all over the place (which hopefully you will remove, see the above paragraph), any debugging output from your script and any non-fatal php errors will get discarded if the ouput_buffering setting is ON (any non-zero value.) you should set this to OFF. lastly, you should not attempt to SELECT data in order to decide if it already exists. you should set up the table with a unique composite index for the column(s) that identify the user id and product id combination, just attempt to insert the data, and detect if a duplicate index error occurred (see the above paragraph concerning catching an exception for a duplicate error.)

this doesn't directly answer your question, but you should store the user's id (auto-increment integer primary index) in a session variable to indicate who the logged in user is, then on each page request execute an sql query(ies) to get any other user information, such as the username, email address, or user permissions. this will insure that any changes made to this user information will take effect on the very next page request, without requiring someone to log out and back in again. if the user_id session variable is not set, you would setup a default set of 'user' values, in a regular php array variable, that indicates a non-logged in 'guest.' if the session variable is set, you would use it in a query to get the actual user's information and store it in the php array variable. you would then test and use the contents of this variable in the rest of the code on the page to determine what to display or what action can be performed on the page. if you want to halt execution if the user isn't logged in or is not an admin, per your example, you would test if the final user's permission data doesn't contain the admin permission value.

you would have an actual image containing whatever text or picture you want to use to indicate that there's no image to display and output it instead. for your images, you should store the actual file names in a database table, then use the id (auto-increment) value as the ?label=x parameter in the src="..." link, then query in the label.php code to get the corresponding file name. this will prevent someone from supplying a filename to something like your database connection credentials file and have the readfile() statement output the content of that file.

the Ternary Operator would produce shorter code and can be concatenated directly inside the string being built. you can also change any escaped double-quotes \" to single-quotes ' and put php variables directly into strings without using concatenation, simplifying the syntax. slightly off topic, you are repeating code 6 times, once for every bench_type value/range. there's at least two problems with this - 1) it is taking you a long time to produce code, and now that you are making a change to the code, you must make the change in 6 places, and 2) to add a new value will require that you find all the code using the values and add to it, then re-test the code to make sure there were no mistakes. instead of a hard-code approach, of writing out code for each value, repeated by the number of values, you need to use a dynamic processing approach, where you will organize/preprocess the data, then simply loop over the data to produce the output. it would take knowing what the overall data looks like to specifically help, but if you index(pivot) the data using the details, year, and bench_type, as array indexes, when you retrieve the data, you can probably reduce all the above to three nested foreach(){} loops, that will 'automatically' adjust if any new bench_type values are added to the data. if you do post an example of your $reg_years data, please use var_export() so that the data can be used for testing.

you probably have some broken markup on the form page (nested forms as an example.) the quickest way to get help would be to post all the code for that page.

a. the ? place-holders do not get surrounded by quotes in the sql statement. the single-quotes around them will result in literal ? characters being used as the values. b. as suspected, you cannot supply literal values in a bind_param() statement. you must either put literal values into the sql statement, put them into variables that would then be used in the bind_param() statement, or switch to the much better PDO extension. edit: or set them as the default values in your db table definition, and leave those columns out of the sql query.

you would need to post your current code to get any help with it. the previously posted code doesn't even have a bind_param() statement in it. best guess, you are trying to supply a literal value, rather than a variable as a parameter. this is yet another reason to switch to the much simpler, more consistent, and better designed PDO extension. you can supply an array of values to the ->execute([...]) call that can be anything - variables, function calls, literal values, math expressions, ...

less... $matched = array_intersect_key($all, array_flip($referred_by_Affiliate));

arrays are for sets of data, where you will operate on each member in the set in the same/similar way. by keeping the input data as a array, you can search through your code and find all references to that data, via the array variable name. using variable-variables, you are 'magically' creating those discrete variables and you must now know what they are named in order to search for them. by keeping the data as an array, you can directly operate on the data using php array functions. for your strtoupper example, where you want to apply that function to each entry in an array - $data = array_map('strtoupper',$data); you can then start doing things like trimming all the data, filtering out empty values, applying user written sort, filter, and validation functions to the data, all at once. also, as Barand has shown, you can build and use an array as a dynamic input to things like a PDO prepared query ->execute(...) call, or a templating system, so that you are not writing out lists of variables yourself. you can use general-purpose code to build those arrays of values based on entries you add to your defining $fields array.

you CAN configure the web server to treat .html (or any other extension) as a php file. the default is for only the .php extension.

that opens the file through the file system, not the web server, so, any links in the html will also be read through the file system. you must use a url to the html file, such as http://localhost/phptest.html. this will cause the src="phptest.php?id=1" attribute to be read through http://localhost/phptest.php?id=1

technically, the code you have posted should work. unfortunately, telling us something doesn't work doesn't help. exactly what symptom, error, or output do you get?

GROUP BY some_col consolidates all the rows having the same some_col value into a single row, so, for each user, there would only be one row in the result set. if you want the rows for each user adjacent to each other in the result set, add an ORDER BY term (almost every select query should have one) and/or index/pivot the data when you retrieve it using the user_id as the main array index, to produce an array of sub-arrays for each user. as to why you are only getting the data for a single (the last user), your code inside the loop is needlessly copying variables to other variables, overwriting any previous data, until finally, after the end of the loop, you are left with only the last row of data. once you have fetched all the data into an appropriately named variable, $result_records, simply loop over that variable to produce the output that you want, no need to create 12 lines of code coping data from one variable to another for nothing.

the post method form processing code's purpose is to detect and process the data from a post method form submission. when you are done doing that and execute a redirect, there's no connection between any code that was just executed and what will be executed after the redirect. perhaps this will help your understanding - web servers are stateless. they don't know or care about anything that happens outside of the current request they are servicing. a browser makes a http(s) request to a web server. the web server outputs the requested page, which can contain dynamic portions produced by server-side languages, e.g. php. the browser renders the html, css, and JavaScript on the page. if the page contains a html post method form (what you are currently doing), when that form is submitted, the form data is sent as part of the http(s) request to the page, given by the action attribute (a blank in your case, for the same page as the form. which is not actually valid html5. you should completely remove the form's action attribute in html5.) the section of the code on that page that's testing for a post method form submission will run, doing whatever it was written to do. there are two reasons for putting the post method form processing code above the remainder of the php code on the page - 1) allow any statement that uses a header to work (redirect, cookie, content type, ...), and 2) so that you can make a decision as to what to do on rest of the page based on the result of the post method from processing code. if the result contained any user correctable errors, you would continue running the code on the page, display the errors, and re-display the html document with the html form in it. if the result was successful processing of the form data, you should actually redirect to the exact same url of the current page, with an exit/die statement after it, as @Barand stated, to cause a get request for that page. this will prevent the browser from trying to re-submit the form data should you reload the page or browse away from and back to the page. each of these requests/responses are completely separate. it's up to the code you write on a page as to what happens during any request made to that page.

the code on a page should be laid out in this general order (yes there are exceptions) - initialization post method from processing code (the current problem you are having with a redirect) get method business logic - code that knows how to get/produce the data/content needed for the dynamic portions of the page html document

what does the 'view source' of the output show? what do you get if you use var_dump() instead of print_r()? your posted code should display the correct result (though the 2nd foreach() isn't needed, just reference the zeroth element), based on the print_r() output you have shown. if it isn't, either that's not the whole code that's being executed (are you doing something like running another query inside of the loop), where you are outputting the values is preventing them from all being displayed where you are looking (inside of a html table w/o being part of the table markup), or there's something about the data values that's preventing them from being seen (some non-printing or html around the remaining values, that the print_r doesn't show.)

it's acting like the submitted search value has some extra character(s) being added to it. it could also be that the code fetching and outputting the result is dropping value(s). if you cannot determine what's causing the issue, you will need to post all the code that it would take for someone to reproduce the problem.

after you use an array name for the form field, so that you can have a set of fields, or one field with the multiple attribute, without typing out a series of name-numbered field names, be advised that using a html form submission to upload multiple files will try to send all the data in one http request. this will easily cause the size of the request to exceed the post_max_size setting on the web server, which will cause the upload to fail and give empty $_POST and $_FILES arrays. even if uploading a single file, you can easily exceed the post_max_size setting. to handle this possibility, your form processing code must first detect if a post method form was submitted, then detect if the $_FILES array is empty or not before trying to reference any of the $_FILES data. there are other things that can cause the $_FILES array to be empty, such as uploads not being enabled or bad markup in the form. however, once you have successfully uploaded any file with your code, the total size of the form data will the reason for an empty $_FILES array. your code must detect this condition and setup a message for the user telling them that the total size of the submitted data was too large and could not be processed. once you have determined that there is data in the $_FILES array, you must test the ['error'] element for each file and only use the uploaded file information if there is no upload error. for the upload errors that the user has control over, you must setup a unique and helpful error message telling them exactly what they did wrong and how to correct it. for the upload errors the user has no control over, you would setup a general failure message for the user and log all the actual information about the error so that you know it is occurring and then can find and fix what's causing it on the server. to address uploading multiple files, you would need to use ajax to upload the files one at a time. there are existing scripts you can find on the web showing how to do this.

when hovering over a user's name/icon, the dialog box used to contain information about what they were doing at the time, e.g. viewing topic ... this was useful to prevent wasted time replying (if a contributing member was viewing a topic i would likely post a reply in, i would typically wait to see if they posted, in order to prevent repeating ourselves.) it was also helpful to know if the OP was actively viewing their own topic. this piece of information is no longer present in the dialog box.

these initial values must be related to something (an id?), that you would then use when updating the correct row(s) in the database table. you would use an array name for the form field, with the array index being the id. you would then loop over that array name in the post data, getting the index (id) and the submitted value to use in the update query. note: onInput is probably not a good choice to use to submit the data, since every keypress that alters what's in the field will cause a form submission. for your example of changing a 10.00 to 20.00, you can move the cursor to the '1' position, but deleting it will cause your submit function to be executed, then typing the 2 will cause the submit function to be executed again.

^ this is the problem. it apparently doesn't know that the point of constants are that they are global.

what makes you think that? since you are making a database connection in config.php, why are you making another one inside the process_database() function? making a database connection is one of the slowest operations you can do on a page. you are doing it at least twice.

have you checked the browser's developer console for errors? it looks like the jquery-1.11.2.min.js and bootstrap.js files have been altered and now contain syntax errors.

because you haven't specified a length of 1 (one) - https://www.php.net/manual/en/function.substr.php