mac_gyver

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.

the whole point of having a server-side scripting language is so that you don't have to write out and maintain 100's or even 10's of pages for a web site, like you would have had to do 20 years ago with static html pages. instead, you store just the information that's different (category, title, content, ...) between the pages in a database or an array (if you don't have that much different information), then you use a simple server-side program in one physical file to dynamically produce the navigation menu and dynamically produce each logical page from that stored information. if you or someone you know produced 10's or 100's of actual .php files that contain whole html documents, with navigation menus, and different content, you are 20 years out of date. web sites are not made this way in the year 2015.

in addition to the problems in your sql statement itself, the error you are getting is because your line of code that's running your query is incorrect. this is your line of code for running the query in the last post in this thread - if($myconn->query($user_query ===true)){ this is the equivalent line of code from the 1st, 4th and 6th posts in this thread - if($myconn->query($user_query)===TRUE){ look at those two lines of code carefully and find what's different between them. this is why in one of your threads, someone told you not to just copy/paste things you have seen somewhere. copy/pasting things doesn't teach you what they mean. your line of code is doing three things - 1) it contains an if(...){ conditional statement to test if an expression is true. 2) it's calling a mysqii database method to execute a sql query statement - $myconn->query($user_query) 3) it's comparing the value returned from the msyqli ->query() method with an exact TRUE value - ===TRUE. the result of this comparison is then being tested by the if(...){ conditional statement. this 3rd part is completely unnecessary and is just adding clutter to your code, which may be the reason the line of code you wrote in post #9 is incorrect. you are writing more code than is needed, making it difficult to see what you are actually doing. there's an expression we have in English - you cannot see the forest for the trees, which means you cannot see the big picture of what you are trying to accomplish because you are getting stuck on the small details. there's another expression/acronym - KISS (Keep It Simple Stupid.) which means to use the simplest method that works and don't overly complicate something. since all you need are parts #1 and #2, an if(){ conditional statement and a mysqli ->query() method call, this is all you need to do to call and test if the mysqli ->query() method returned a true value - if($myconn->query($user_query)){ by actually learning the meaning of what you are doing, you can write simple, error free code that does what you want.

this shouldn't be a matter of removing incorrect information after the fact, but of building the correct information in the first place, especially since the url that's being built is invalid with multiple sets of same name keys and could easily end up being longer than what browsers/servers accept for url lengths. it sounds like the pagination code is trying to append things to the url, rather than to just build the url from any existing get parameters and the page number it is responsible for. if you do an advanced search on the forum (the snow-flake thing to the right of the search box) and search for http_build_query and my user name as the author, you will find a page of results that show how to use http_build_query() to properly take any existing get parameters, without needing to know what they are or if there are any at all, and allowing the pagination code to just set the page value that is is responsible for and produce the pagination links.

what is the data type of the active column? what are some of the values in it? and is there any chance that you imported that data into that column from a csv file or copy/pasted into a form field or you have an error in your code inserting the data and you could have some white-space characters (either a space or a tab) in the column in front of the data so that when the 'apparent/visible' value is converted to a number for the comparison, all the values end up being a zero, which results in a TRUE WHERE clause for every row?

i think this is more of a theoretical problem, rather than a real situation, given that there's another current similar thread asking about two different switch/case statements, one for a book selection and a second one about chapters for each book.

we generally don't write code for people, but since you and whoever that is in the other thread are stuck on needing to use switch/case statements to do this assignment, here's an example of how you would do this if your book/chapter content is stored in files and folders/files - // condition/cast inputs $book_id = isset($_GET['book_id']) ? (int)$_GET['book_id'] : 0; $chapter_no = isset($_GET['chapter_no']) ? (int)$_GET['chapter_no'] : 0; $file = ''; if($book_id && !$chapter_no){ // only the book_id was given $file = "book{$book_id}.php"; // change this to whatever maps the book_id to the book file } if($book_id && $chapter_no){ // both were given $file = "book{$book_id}/chapter{$chapter_no}.php"; // change this to whatever maps the book_id/chapter_no to the chapter file } if(!$file){ // nothing or nothing using valid numbers was requested echo "no book or book/chapter was requested"; } else { // a book or a book/chapter was requested, test if what was requested exists if(!file_exists($file)){ // the book or book/chapter doesn't exist echo "the book or book/chapter requested doesn't exist."; } else { // the book or book/chapter exists, include it include $file; } } there are no switch/case statements needed, and this will work for any number of books and any number of chapters in any book. using some glob() statements and a little bit of program logic would let you dynamically produce the navigation menu/links without hard-coding them too. if you are taking a class and the instructor has suggested you use a switch/case statement for this task, he should have assigned a task that actually would use a switch/case statement. when the processing is the same for each input value, you would not use a switch/case statement. some examples where you could use a swtich/case statement would be - the CUD (create, update, delete) part of CRUD (create, read, update, delete) data coding, the different operations you can perform on a shopping cart (which is actually just CRUD coding).

someone else recently asked about using a switch/case to just test/map values to determine what content to include/produce on a page. you wouldn't use a switch/case statement just to do this since that would require that you first create the switch/case statement with all your values, then find and edit the correct place in your switch/case logic every time you add or delete content. see my reply in this thread - http://forums.phpfreaks.com/topic/297827-switchcase-for-about-800-pages/ for what you are asking, you would use either one or two get parameters in the url - index.php?book_id=1 or index.php?book_id=1&chapter_no=1 the php code would receive these as $_GET['book_id'] and $_GET['chapter_no']. you would test if the first or both of these are present, validate or cast their value so that they are safe to use, then use the value(s) to determine what content to retrieve/include into the page. in short, you would use the computer to do the work for you rather than you writing out several 10's or several 100's of lines of code that only differs in the value they are testing/mapping.

afaik (after doing a little research) dates would need to be enclosed in #. give this a try - WHERE Date between #8/1/2015# and #8/30/2015# also, what is your date column definition? Short Date?

in your previous thread about forms and form processing, the forum members were trying to get you to organize your code so that it grouped common actions together and that it put any form processing code before any code that gets or uses data to be displayed on the page. and now that you have added database code into the process, you need to put code that inserts/updates/deletes database data and code that retrieves data into the proper locations in the code on your page the code on your page should be laid out in this general order - initialization, start of database dependent code, determine user state and permissions, post method form processing, get method business logic, end of database dependent code, get method presentation logic, and html page/template. 1) initialization - create/define things your code needs - session_start(), require files holding configuration data/function definitions, setup an autoloader for class definitions... 2) start of database dependent code - create a database connection. if you are using exceptions to handle database errors, this would be where the try block starts. 3) determine user state and permissions - check if the current user is logged in and retrieve any permissions the user has. the rest of the code on the page would make use of the logged in state and permissions to determine what code can be ran and what content will be produced. 4) post method form processing - the post method form processing code, which creates/modifies/deletes data on the server, should come near the start of your file so that you aren't tempted to output anything to the browser before any data has been updated by the processing code. if your page has multiple sections of form processing code, you would have them all groped together in this section of code. after successfully (no errors) processing any post data, do a header() redirect to the exact same url that the form submitted to. this will cause a get request for your page. this will cause the browser to forget that a form was submitted and it won't try to resubmit the form data if you refresh the page or browse back to the same url. this also enforces separation of concerns. post method form processing, which modifies data on the server is a separate concern from displaying data due to a get request for your page. if you want to display a one-time 'success' message after the header() redirect, pass it in a session variable, then clear he session variable after the the message gets displayed. if there are errors while processing any post data, you would not redirect, stay on the page, let the rest of the code on the page display the errors, (re)display the form, and repopulate the form fields with the previously submitted values. 5) get method business logic - code that produces/gets data needed for the dynamic content on the page. this code contains any database specific code that knows how to retrieve data from your database tables. the result of this code should be php variables that the code later on the page uses as its input. this code should contain NO html/css/javascript markup. 6) end of database dependent code - if you are using exceptions to handle database errors, you would catch the errors at this point. you can also destroy any query result resources and the database connection at this point since you won't need them any longer. 7) get method presentation logic - code that knows how to take the data (database data, errors, form data...) from ALL the above code and produce the dynamic output for the page. if the output doesn't require any 'heavy' processing/formatting, just use the data directly in the html page/template code. the result from this code should be php variables that the html page/template uses. this code should contain NO database specific statements. if your page has multiple sections of get method presentation logic, you would have them all groped together in this section of code. html page/template - this section starts with the <!DOCTYPE ... tag and ends with the </html> tag. it is the actual html document that the dynamic output is put into to make the complete page. only simple php conditional logic/loops, function calls (that are responsible for producing output), and echo statements should be present in this section of code. if you organize the code on your page like this, it will separate all the different concerns, making it easier to see what your code is doing, easier to test, and easier to get help with because you can isolate and post just the relevant part. also, in your 'Is php easy' thread, i made a post about defining the inputs, processing, and output/result for your code. if you do this for your form processing code, it will make it easier for you to write code that does what you want.

you would not use a switch/case statement to do this. switch/case statements are used when you have to select between different processing logic in each case. if all you are doing is checking if a value is one out of a permissible set, you would define the set of permissible values in a data structure somewhere (database table, array), test the input value against that data structure (db query, in_array()), then produce the output value based on the input value and use it. if you have more than a few pages on a web site you should also be dynamically serving those pages using a content management system, where the content that's different between the pages is stored in a database, and the navigation menus and the logical pages are dynamically produced by simple php code on one physical page that uses the information stored in the database. the PHPFreaks.com Questions, Comments, & Suggestions forum section where you posted this is not for asking programming questions, it's for asking questions or making comments/suggestions about this site.

@heeha, don't jump to conclusions. certain forum sections are configured to NOT count posts so that those members that are only posting generic and spammy nonsense won't accumulate post counts.

i have a more basic question, why are you trying to use database based session data handling? using the default file based session data handling, insuring that you are storing the session data files in a location of your choosing and with permissions set so that only your hosting account can access the files, is adequate in all but a very few cases. you also have a problem with database based session security if you are using the same database connection that your application code is using and ANY of your code allows sql injection, someone can grab all the session data. if the reason you are doing this is for a perceived security problem, to make this as secure as possible, you would need a separate database with a separate connection username that only has access to that database and you would want to encapsulate the database connection into your session handler so that no other code can use possibly it.