mac_gyver

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

the main point of using a prepared query is to prevent sql special characters in the data values from breaking the sql query syntax, which will prevent the insert query from working. when you examine the contents of the imgs/uploaded/ folder, does it contain the files you have been uploading? again, the code is lacking in error handling that would let you know if and why it is failing. what does the 'view source' of the output with the <img ... tag show?

when you examine the data in the database table, are there any values in the product_image column? your php code is lacking in error handling that would tell you if and why the upload is failing. there is information in the php.net document and posted all over the web on how to use prepared queries. you should however switch to the much simpler and more consistent PDO extension. your insert query would look like the following if using the PDO extension - $sql = "INSERT INTO products (product_cat, product_title, product_price, product_desc, product_image, product_keywords) VALUES (?,?,?,?,?,?)"; $stmt = $pdo->prepare($sql); $stmt->execute([ $product_cat, $product_title, $product_price, $product_desc, $product_image, $product_keywords ]);

works correctly for me. if your posted code didn't create the constants, either - that's not the actual code that was executed, e.g. that exact code didn't get saved to and executed on the web server. there's more code involved, such as function definition(s), so that the scope of the $db array and the foreach(){} loop are different so that the foreach code failed (there would be a bunch of php notice/warning errors.)

for the set of values that you want to optionally include, you should use a html array for the form field name, with the item id as the array index, then you can test and loop over that array of values to dynamically add them to the email body. you would use the item id values to query for the information about the items to include them in the email so that it will have helpful context for whoever must deal with the order information. if you have more than 2-3 form fields, you should use a data-driven design, where you have a data structure (array or database table) that defines the expected fields, which fields are required, and which fields have specific formats that must be met, e.g. an email... you would then loop over this defining structure and use general-purpose code to validate and process the data. your form processing code should - detect if a post method form has been submitted before using any of the form data. your current logic, because it doesn't stop code execution, actually runs everything even if a form has not been submitted. don't copy variables to other variables for nothing. this is just a waste of typing time. instead, keep the set of form data as an array and operate on elements in this array throughout the rest of the code. trim all input data before using it so that you can detect if all white-space characters were entered. this can be done using one singe statement, provided you have done item #2 in this list. validate all the trimmed data before using it, storing validation error messages in an array using the field name as the array index. if there are no validation errors, the array holding the error messages will be empty, use the summitted form data. any external, unknown, dynamic value you put into the mail body need to have htmlentities() applied to it in order to prevent any html, css, or javascript in it from being rendered when you read the email in a browser. any value you put into a mail header, such as the visitor's email address as a Reply-to: field, must be validated that it is exactly and only one properly formatted email address in order to prevent mail header injection.

given the number of mistakes in the first posted code, post your current php code. also, for debugging, add the following immediately before the if($_SERVER["REQUEST_METHOD"] == "POST") { line of code - echo '<pre>'; print_r($_POST); echo '</pre>'; after you submit the form, what output do you get on the page? i'm thinking you have something like a header redirect in your code, that you are not showing us, and any output from your code is being discarded and you are seeing the original page being output to the browser. requiring the user to know and enter id values is error prone. you should provide some method of selecting from existing records. lastly, depending on how the data originally got inserted into the table, you could have white-space characters as part of the data, so nothing you enter in a form field will ever match the values. how did the data get inserted?

are you requesting this page using a URL, so that the php code will get executed, or a file system path, which would show the raw php code in the 'view source' in your browser? what do you see when you look at the 'view source' in your browser? is the html markup for the page valid, so that you don't have something like nested forms going on? to get the browser to submit to the same page and get any existing get parameters in the url to automatically be propagated between pages, just leave the entire action attribute out of the form tag. you need to validate all inputs before using them, and set up a user error message for required inputs that don't exist. the return value from the mysqli_query() call for a delete query doesn't tell you if the row was deleted or not. it just tells you if the query executed with or without an error. however, since you are also using an or die() for error handling (which shouldn't be used at all, you should use exceptions for error handling for database statements), you will never see the else {} "Error deleting record" message. to actually detect if a row was delete, you need test the number of affected rows. a prepared query has nothing to do with where or how a value is entered. they are about protecting against sql special characters in external, unknown, dynamic values from breaking the sql query syntax, which is how sql injection is accomplished.

the main issue is due to local variable scope within functions (the $errors array you are returning is being created anew inside each function call) and wrong-responsibility of function code. user written functions should do useful things (building blocks) that help you to create applications (they should not contain your application specific code), they should accept all input data as call-time parameters, and they should return the result to the calling code. in short, breaking up and wrapping your main code inside of function definitions, then needing to make everything global to get it to work, is just adding a lot of typing that doesn't add any value to what you are doing. also, buried within this wall of code is a logic mistake (the looks like it came from w3schools) - if(!$username){ $errors[] = "A username is mandatory"; echo "A username is mandatory <br>"; } else { $username = clean_names($username); } that code is first testing if the raw value is false or not, then it is using whatever the clean_names() function does to the value throughout the rest of the code. based on what w3schools code has done in the past, this will let a value consisting of all white-space characters pass the raw test, but will use an empty string in the rest of the code. the only modification you should make to user submitted data is to trim it, first, then use that trimmed value throughout all the rest of the code. as to testing if a username (or any other unique value) already exists, define the column as a unique index, just attempt to insert the data, then detect if a duplicate index error occurred. by first trying to select the data, there's a time gap where dozens of queries can be executed which could then take the value that you think is not in use. you should also be using a prepared query when supplying external, unknown, dynamic values to a query when it gets executed.

define: Are hackers able to see ... anything in your server-side code? if someone gains direct access to your server-side files or gets their server-side code to run on your server (which typically includes a file-manager/control-panel), they can see everything in all the files. for the simplest case of someone just getting their server-side code running on your server to grab and output all main program (global) variables and defined constants, yes, database connection credentials defined within the main program scope are accessible. for this simple case only, using the local variable scope within a user written function/class-method or non-public visibility for properties/constants within a user written class would prevent access to these values. if someone makes a http(s) request to your server-side files, as long as the server-side programming language is functioning, they can only see what your server-side code outputs in response to the request. for the extremely rare case where the web server is functioning but the server-side language is not, i.e. the raw php code would be output in response to a request, putting the server-side files containing things like database connection credentials either in a folder outside of the document root folder or if that option is not available inside a folder inside the document root folder but which has had http requests disabled for that folder will prevent http requests to those files.

see the following link on how you can log what the $_FILES array actually contains and what your post method form processing code should do - https://forums.phpfreaks.com/topic/312874-cant-access-_files-after-form-submission/?do=findComment&comment=1587078

i would compare the size, then the hash. if the size/hash for existing files is in a db table, you can just query to find any potential matches, then compare the contents only for files with a size/hash match. some code i did long ago, with some new comments related to including a newly uploaded file in the data - <?php // dupless (a file compare utility) using php // read all the files and file size, store using the size as main array key, path/file as the data // all sizes with only one file are unique - remove // loop though each size array and get the md5 of the file, store using the md5 as a key, path/file as the data // all sizes/md5 with only one file are unique - remove // remaining with same size/md5 are likely the same, you would need to actually compare contents at this point $path = './keep/'; // get list of existing files $files = glob($path.'*.*'); // because the $files data contains the path/file, you can array_merge() other files here to // include them in the comparison, such as a newly uploaded file. if the path/file is in the results, // there's an existing file with the same size/hash as the uploaded file $files = array_merge($files, glob('*.*')); $data = array(); // get data by size foreach($files as $file){ $data[filesize($file)][] = $file; } foreach($data as $size=>$arr){ // remove unique size if(count($arr)==1){ unset($data[$size]); } else { // more than one for this size foreach($arr as $pos=>$file){ // remove existing element unset($data[$size][$pos]); // replace with md5 of the file $data[$size][md5_file($file)][] = $file; } // for the current size array, remove unique md5 entries foreach($data[$size] as $key2=>$arr2){ if(count($arr2)== 1){ unset($data[$size][$key2]); } } // if the current size is now empty, remove if(count($data[$size])==0){ unset($data[$size]); } } } echo '<pre>',print_r($data,true),'</pre>';

https://www.php.net/manual/en/language.oop5.visibility.php

php creates class properties (variables) without having to define them. the only thing defining them does is enforce the stated visibility.

i tried your client-side code and it works for me. however, the things i bypassed or added to make it work, which you didn't include, may have altered the operation of the code. it is always helpful if you post complete, working, code. you may want to log the $_FILES information on the server so that you can see what it actually is. add something like the following to the php code in the file that's the target of the ajax call - file_put_contents('log.txt',print_r($_FILES,true),FILE_APPEND); your post method form processing code should have always been in the target file of the ajax call. your form processing code should - detect if a post method form was submitted, i.e. you need the if($_SERVER['REQUEST_METHOD'] === 'POST'){...} logic. next, if you exceed the post_max_size setting, which is what i think is probably occurring, both the $_POST and $_FILES arrays will be empty. you must test for this condition after item #1 above, and setup a message for the user telling them that the total size of the form data was too large. you would also want to log this information, including the actual size of the post data, so that you, the developer/programmer, will know that it is occurring as the result of user actions on your site. if the $_FILES array is not empty, you can then use elements in that array. you must next test if the ['error'] element is zero (no errors) or some other value (see the upload handling section in the php.net documentation for all the possible error values.) for errors that the user has control over, you need to setup a unique and helpful error message telling the user what was wrong with what they did. for the errors that the user has no control over, you should log the actual error information and setup a general failure message for the user. only after you have done the above three things, will you have actual uploaded file information that you can use.

You can and should put configuration files outside of the document root folder. The variable $_SERVER['DOCUMENT_ROOT'] contains the path to the current document root folder, which you can then concatenate the desired path to the configuration file to, to arrive at the actual path.

^^^ this is the upfront information that should have been included in the first post in the thread, i.e. what top level thing you are actually trying to accomplish. your reactive, after the fact, attempted solution to use DOMDocument, in the php code on the web server, WON'T work because the web server doesn't have direct access to the user modified DOM that only exists in the user's browser. your attempt at opening and reading the index.php FILE, was both misleading and would read the raw content of that file. even if you used a http wrapper and requested the index.php page from your own web server, you would only get the initial DOM, that the web server sends out to the user's browser. repeating now what @requinix has stated, the only way of getting anything from the browser to the web server requires that you make a http(s) request to the web server that contains the information that you want. you will need to pick some point in the code in the browser where the value(s) have been changed, then get those value(s) and include them in a http(s) request to the web server.

why have you thrown away the code at that start of this thread, using the mysqli extension, and are now trying to use the mysql extension? what is the overall goal/end point of doing this?