mac_gyver

rather than to try and MAKE your existing code do what you want, i would just take the list of sections from the linked to post and define what you have and what you want to do for each section (which would become comments in the code). when you get to the point of creating the code for each of those sections, you can reuse some of your existing code. this is the list of those sections, with some specific comments relative to what you are doing - initialization - your head.php file is apparently part of the html page markup? if so, you should require it in the html page/template section. start of database dependent code - you should switch to the PDO api to replace the mysql_ functions. it is more consistent and it is easier to use exceptions with to handle all the database errors than the msyqli_ api. determine user state and permissions - the userid you reference in the code should be from a session variable. there's a comment in your code about it being from a cookie. you should NOT use a cookie to store the user's id. since your code REQUIRES a userid to work, you should make sure there's an id before running any of the code that's dependent on the id value. post method form processing - your form should use method='post' since you are changing data on the server. get requests should be used to control what to display on a page, not to change data. get method business logic - this is the code that retrieves just the data to display the cart. it's the sql statement, running the query, and fetching any/all the rows into a php array variable. end of database dependent code - no comment beyond what is mentioned at the linked to post. get method presentation logic - since you are calculating tax, shipping, and totals (which you can probably do most of in the data retrieval query), you would perform those calculations in this section while you are looping over the contents of the cart and producing the output in a php variable(s). i see that you are using htmlspecialchars() on some values being used in queries and in calculations. htmlspecialchars() is an output function. you use it at the point where you are producing output that goes to the browser. it actually has no effect on the numbers you are using it on and is just cluttering up the code where it is being used that doesn't have anything to do with output to the browser. you are also running a query inside of a loop. you should instead JOIN the postage table in with the cart data retrieval query. html page/template - no comment beyond what is mentioned at the linked to post.

i'm surprised you are still trying to get this code to work. you could have completely rewritten it by now and gotten it to do what you want. even ignoring that your programming editor is using line endings that are non-standard, resulting in the forum software adding over 600 blank lines that we have to wade through, this code is disorganized to the the point that i cannot even determine where to look to find what may be causing the symptom you are asking about and it's so disorganized that you cannot troubleshoot it or isolate just the relevant part to post for us to consider. you need to organize and separate the different concerns in the code, this will make it easier to write, change, or debug. see the following post for a layout suggestion - http://forums.phpfreaks.com/topic/297824-database-issues-and-working/?do=findComment&comment=1519095 in addition to just the organization of the code, here are some specific things i see in the code that either won't work or are contrary to good programming - 1) you are using a get method form to alter data on the server. a post method form should be used (you even have two nested <form> tags, which are invalid and the inner one is using method='post', which has no effect, because the first <form tag with method='get' wins.) 2) htmlentities() is an output function, not an input function. using it on the input data isn't going to protect against sql injection. you need to properly escape/case input data or use prepared queries to protect against sql injection. 3) you have some variables - $HTTP_REFERER and $userID that unless you are using an old version of php, these don't exist, which may be the cause of the symptom you are asking about. 4) your database statements don't have any error checking logic and the msyql_ database statements are obsolete and will be removed from php fairly soon. 5) your queries for inserting/updating the rows in the basket should be replaced with a single INSERT ... ON DUPLICATE KEY UPDATE query. there's no need to first try to select a row, then either insert or update the row. just run a single INSERT ... ON DUPLICATE KEY UPDATE query. with the appropriate index set up, it will insert a row if it doesn't exist or update it if it does. 6) item #5 would also apply to your 'shopper' table, which i'm guessing is an order table? if the information in the 'shopper' table is just derived information, you shouldn't have the table at all.

what makes you think that the php source code in a .php file would be accessible?

this is exactly the same as what your last thread was about. if the query runs without any errors, the mysqli_query() statement returns a result resource that you use to access the result of the query (fetch data, check the number of rows...) not matching a row is not an error, it's an empty result set (no rows.) the mysqii_query() statement returns a false value only if the query failed due to an error of some kind, usually something wrong with the sql statement, the database, or the database connection. the php error message you are getting about the parameter you are passing to the mysqli_num_rows() function not being of an expected value supersedes the value the mysqli_num_rows() function is designed to return. if you are passing garbage into the function, you get garbage out. your code needs to test if each query runs or fails before you can use the result from the query. this is not just a debugging step when you have a problem. you must always do this. if the query has failed, you need to use the error information from php/mysql to find out why and fix the problem and you should stop the code from running any further statements that are dependent on the result of the query, since there isn't any. the error you are getting in this thread is a follow-on error due to a problem earlier in the code. it's not where the problem is at.

there's no need to do an update query at all. you don't need to store the location in your equipment table, because you know the location from the location table. you are just duplicating data that you can easily find by running a query that JOINs the two tables.

your post contains absolutely no information upon which to help you find what's wrong with what you are doing. you got an answer that was equally useful (42 is the Answer to the Ultimate Question of Life, the Universe, and Everything from the The Hitchhiker's Guide to the Galaxy.) the only thing anyone can determine from your post is that the problem is somewhere in what you are doing. care to show us your query and code that reproduces the problem so that someone could tell you if the problem is in your database query, in the php code retrieving the data from the database query, or in the html that's being produced?

the answer is 42

the four biggest problems with the code are - 1) you have stored same meaning data in two separate tables, one for members and one for clients, which you are querying for but not using. 2) you are retrieving all the data, not just the data being displayed. you are outputting all the data to the client for it to handle. 3) you are running multiple queries inside of a loop. 4) some of your data is not stored correctly, requiring you to do a substr_replace() on it every time you use it. items #2 and #3 are the cause of your performance problem. you should only retrieve the data you are currently displaying and i'm betting that all those queries can be replaced with a single query.

in order to fix a problem, you must first find the cause of the problem. if you had a noticeable change in the page generation/loading time as the number of data items increased, your code is doing something extremely inefficient and it may be that caching cannot be used due to the nature of the data or won't have any effect on the problem. if you want someone here to help find the cause of the problem and make suggestions that would help, you will need to post enough of your code and some sample data that demonstrates and reproduces the problem.

@Sedona, you need to be careful when posting the debugging output you are getting. it contains cookie values that will allow anyone to visit your site and impersonate you. I reported the two previous posts in this thread that contain those values and they were hidden/removed. Now you have posted two more sets of cookie values for someone to use. this header is indicative of going through a proxy server, either where the client is at or the web server is behind a proxy where it is hosted. either of these, or even a .htaccess file could be causing this, but i doubt it would be dependent on there being a completely specified http url or not in the posted data. if that's your whole form processing code in post #31, there's nothing in it that could be causing this, aside from the fact that it isn't bothering to test if a from was submitted at all. you didn't post your form/the whole client-side code.. i'm guessing you have some client-side validation that could be causing this, only when it finds something that starts with a completely specified http url? i also don't see where you are logging the information that scootstah gave you code to do.

validation of the form data and using the form data are two different concerns and have to be separated. you have to validate the form data first, then use the resulting error information to determine what the rest of the code should do. if you use an array to hold your validation errors, your logic will be easier to write. create an array to hold the errors - $errors = array(); to added errors to the array - $errors[] = "some validation error message"; to test if there are not or are errors at any point in your program flow - if(empty($errors)){} - no errors or - if(!empty($errors)){} - there are errors.

i'm going to guess this is a symptom of a page getting requested twice/redirected back to, combined with php's output_buffering being on to hide things (thanks php), and the second request doesn't have any post data and you are only seeing the output from the second/last request. to start with, the php code you posted isn't even checking if a form was submitted, so any time the page gets requested, it will run that code. if the page was requested with a get request, $_POST will be empty and you will get an empty value inserted into your database table and your "New record created successfully" message will be output. i'm not sure if the phpinfo() output you posted was supposed to be from the result of submitting the form with a valid url, but the REQUEST_METHOD showing in that output is GET. any chance that your page is doing a header() redirect back to itself based on some condition related to the url/non-url being submitted? it would take seeing all your code involved with this problem, less any database credentials, posted in the forum, for anyone else reading this thread to help. by sending code via pm, you are preventing anyone else, with a fresh set of eyes, from offering any specific help.

you might want to use a prepared query to get the $type value into the sql statement in order to prevent sql injection or errors if the value contains sql special-characters. using a prepared query to provide the $type value, would have also prevented the original error you are getting.

if your token check isn't working, i'm betting you would be getting php errors that would help pin down the problem. do you have php's error_reporting set to E_ALL and display_errors set to ON, ideally in your php.ini, so that php would help you by reporting and displaying all the errors it detects? your token check is there to detect if someone/something didn't visit your form before submitting to your form processing code. wouldn't you want to display (during development) and log (on a live server) all the information about a request that fails the token check? if your code was already doing this (in most cases, every if(){} statement needs an else{} to handle the case where something didn't work), your code would likely be telling you why the token check is failing. what? it inserts only 1 file at a time? does that mean that it eventually inserts all of them or does that actually mean that it is only inserting the first one or it is only inserting the last one or it is only inserting a arbitrary one but only if it is a particular type or size? you need to tell or show us what result you are getting and what result you expected.

that tool would be your brain and the documentation for what you are doing. you have to learn the basic syntax for php or (my)sql before you can use that syntax to write your code and your sql queries. knowing that commas go between lists of same meaning things (columnA = 'valueA', columnB = 'valueB') and aren't used on the end of that list, takes learning the meaning of what you are doing and of thinking about the context when you are doing it. you also have to look at your code and sql queries when you get an error in them and try to find and fix what's wrong with them. just dumping each successive code/query/error on a help forum isn't really you doing this thing called programming. the mysql documentation contains syntax prototypes for each kind of query, that show what's required, what's optional, what order the terms go in the query, and where lists of same meaning things, separated with commas, can be used.

your SELECT query, with the various conditions in the WHERE clause is for finding records that match those conditions, for display purposes. unless your intent is to update all the matching records from UNPAID to PAID, which in real life usually doesn't happen all at once, you wouldn't do an UPDATE query this way. after you display the UNPAID recored(s) for the selected reseller, you/someone would pick (using a check-box) the specific record(s) you want to update from UNPAID to PAID. your form would submit the id's of the records that were checked and you would use the ids in the WHERE clause to update just those records. the only thing in the WHERE clause would be the id comparison. "UPDATE orders SET has_reseller_been_paid = 'PAID' WHERE id IN(...)" the ... would be a comma separated list of id(s) (one or more) that were submitted from the form. you do understand that the % in these values - '%PAID%', '%Order Completed%', and '%UNPAID%' are wildcard characters that are only used in the LIKE syntax? if these strings are the exact values stored in the database, you would not use any wildcard. what you have in the query above would require that the % characters be stored in with your data for a match to occur, which they are not. btw - the sql syntax error you are getting is because you have an extra comma something at the end of - has_reseller_been_paid = '%PAID%', <--- not sure if that is a comma or a period, which i'm pretty sure you had a problem with in a previous thread. are you looking at the errors and at the place in the query near to where the error is pointing out a problem?

1) if you had php's error_reporting set to E_ALL, you would likely be getting php errors that would help pin down the problem with $con. 2) don't use global to bring values into functions. pass them in as call-time parameters. 3) we cannot help you with what is wrong with your code unless you post enough of your code (less things like database credentials) that reproduces the problem. there could be at least a half-dozen different things that could be causing your current symptom.

and since you are already selecting resellers_id and you know that o.resellers_id = r.id from the join condition, why are you selecting r.id at all?

do you have a specific question about doing this that you need help with?

i'm wondering what the purpose of this database entry is even for?

these things you are including/requiring are all relative to the document root folder. use $_SERVER['DOCUMENT_ROOT'] to form an absolute file system path to them - require $_SERVER['DOCUMENT_ROOT'] . /'core/init.php'; you also need to be consistent, just use require everywhere.

i'm not sure what overall goal you are trying to accomplish based on your description and program logic (showing us what result you expect and what result you are actually getting from your code would be helpful), but making a series of numbered form field names - outcome1, outcome2, ... is not the easiest way of handling sets of form field data. use an array name instead - name='outcome[]' you can either leave the array index empty, which will result in sequentiality numbered indexes in the submitted array, or you can supply your own associative or numerical array indexes to tie each form field to specific meaning data on the server.

i looked a little at the code for this plug-in and the only thing i could see it doing for data storage is using a cookie to hold a plain-text email address. IF that's all it is doing, setting a cookie (the readme implies they previously put the plain-text email in the link) with the email address on the sign-up form processing page, then using that cookie value to subscribe to the mail-chimp list when the linked to page is visited, this provides absolutely no security. anyone can send a cookie with any value they want with a request to a page. i even saw that the code was using $_REQUEST, so, it's not even required to simulate a cookie when making the request, just include the email address in the url being requested. it would help if you posted what the emailed link looks like. does it contain any sort of random/unique token as a get parameter or is it just the url of page? if this supposition about how this code is doing this is true, the correct way of doing this is to generate a unique and hard to guess token and put the token value in the link that gets emailed. store the token value and the email address on the server. on the page that gets linked to in the email, you use the token that's in the url to retrieve the email address. a less secure method, but better than a plain-text value in a cookie, would be to encrypt the email address the gets stored in the cookie. encryption is NOT encoding. things like hexadecimal and base64 are encoding. if you recognize the encoding method being used, you can simply encode your own values and put them into the cookie. encryption involves an encryption key that you produce/makeup that only your code should know and an encryption algorithm. the key and the data are passed through the encryption algorithm and knowing the key allows you to decrypt the data later. the problem with this, is without having any storage method on the server, the key will be a fixed value (rather than a random value that's different for each visitor) and someone could go through all the encryption algorithms that php has available (there are not that many) and brute-force find a key that successfully decrypts the encrypted cookie value they got when they signed up. this would let them produce their own encrypted value that the code would happily accept and decrypt to get an email address to use.

if you are getting hundreds per hour, the problem could be in the page that the email link goes to, to verify and finalize the subscription. perhaps it has a code bug that allows empty or special encoded values (i'm thinking a hexadecimal encoded sql injection string combined with php/mysql converting such a value back to the string it contains when it sticks it into a sql query) to match/bypass the check and cause any email address to be verified. it could also be that the email link is attempting to do something tricky, but meaningless from a security standpoint, like doing a base64 encode of the email in the link and someone is just submitting link after link that they have produced, that the software happily accepts, extracts the email from and adds it to the list of verified emails. i would log all the available information that comes with the http requests, both in the sign-up form processing page (to see if that page is even being visited that number of times) and in the link/verify/finalize page.

producing the token is part of the code that produces the output on the page and outputs the form. you have it before the start of the form processing code, so it (re)generates a token when the form is submitted and the value being used in the form processing code is a newly generated value, not the value that was generated at the time the form was produced. put the token generation logic after the form processing code, and before the form code.