PFMaBiSmAd

You need to make your session variable an array where the array index is the item id number and the array value is the quantity of that item. By storing a string into the session variable, you need to have about 3-4 times more logic to manipulate it. Inserting an item (w/o duplicates), changing the quantity, and deleting it are all harder when it is stored as a string. To actually add an item (insert it if it is not in the cart or change the quantity if it is already in the cart), your logic would look like - <?php // code to 'add' an item to the cart if(isset($some_variable_that_indicates_add_to_cart_was_picked)){ $item_id = .... ; // your code that gets and validates the item id $quantity = .... ; // your code that gets and validates the quantity if(!isset($_SESSION[$item_id])){ // the item id is not already in the cart, insert it $_SESSION[$item_id] = $quantity; } else { // the item id is already in the cart, modify the quantity instead $_SESSION[$item_id] += $quantity; } }

^^^ That logic is wrong. $savepath is the result from a mysql_query() statement (a bool true/1 in this case.) You cannot put a result from one query into another mysql_query() statement. The mysql_query() statement expects an SQL query string.

I've had a chance to look closer at your session handler code. You cannot CONDITIONALLY execute the REPLACE query in the write() function. You are trying to integrate the user part of your application code with the low level session call-back functions. That will prevent using session variables for anything else and they won't work in the current code unless you have logged in. You must at least execute the data save logic in the session call-back write() function every time php calls it.

This code seems familiar. Wizzle, you already bumped an old thread with a post to add this or very similar code, where I relied what is causing the symptom and what you needed to do to troubleshoot what is causing the problem - http://www.phpfreaks.com/forums/index.php?topic=272971.msg1658897#msg1658897

Your session statement isn't assigning anything to a session variable. An assignment statement looks like - $var = some_number; or $var = 'some_string'; or $var = $some_other_var; $var in the above can be any kind of php variable, such as a $_SESSION variable.

Does your database table have id either as a primary key or an unique index? If not, then the REPLACE query will always insert the data into a new row every time the page ends, but the first row in the table is what will be fetched when the data is read back into your script.

Browsers and web servers operate using a HTTP request/response - http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol The browser makes a request for the page. The server outputs the requested page back to the browser. You must either output everything to the browser and incrementally reveal the content using client side code (javascript) or you must use separate HTTP requests/responses to get the information for each section of question/checkboxes. Since your desired output implies not refreshing the whole page to get and display the next section, you would use AJAX to make the separate HTTP requests and handle the response send back to the browsers to build and display each section in the browser.

The closing </table> tag goes after the end of the 'outside' loop. The point of using php to produce and output HTML to the browser, is that the HTML must be valid and be what you want it to be, the same as if you had written it by hand. If you do a 'view source' of the page in your browser, is the HTML what you expect?

What does the 'view source' of the blank page in your browser show? Does adding an echo 'testing....'; statement on that page output anything?

There's no stored result, so - mysqli_free_result($result); isn't needed (it would be mysqli_free_result($stmt); if it was being used.)

Without an exit; statement after that header() redirect, the code in your 'protected' file still runs when the file is requested.

Your form processing code needs to be form processing code. You need a specific test and conditional statement around the block of code that you only want to execute when the form has been submitted. I'm going to guess that your form has a submit button or a hidden field named 'submit' - <?php if(isset($_POST['submit'])){ // ALL the code that processes the form's $_POST values goes here.... } The above will prevent undefined error messages that are due to the code being executed when the expected form has not been submitted, because all references to $_POST values will be inside that conditional statement. Any other undefined error messages are due to referencing the wrong or non-existent variable name and you would need to determine the correct variable name or why an expected variable does not exist.

That's not how mysqli_stmt_store_result is used. I'll get back with an answer shortly... Edit: When you use mysqli_stmt_store_result, you will still use mysqli_stmt_fetch($stmt) to fetch each row. Perhaps you were trying to use mysqli_stmt_get_result? Which would allow you to use mysqli_fetch_xxxxx statements to fetch each row?

is_int does NOT test if the value in the variable is an integer, it tests if the variable is of type integer.

Your values in the file are strings AND your code is not removing the end-of-line (EOL) character(s), so your values are actually "trueEOL" and "falseEOL" and the string comparisons don't match and the string replace still leaves the EOL character(s). You need to trim the data or otherwise remove the EOL character(s) before you use the data.

Assignment statements = assign the value on the right-hand side to the left-hand variable. Also, php variables are not parsed and replaced with their value when inside of single-quotes.

Session variables that change depending on what the url is or disappear/reappear as you navigate around on your site or it seems like you have two different sets of them at the same time - are usually due to the session id cookie only matching some of your host-name/sub-domain variations in your URL and/or specific paths in the URL. Since this seems to correct itself when not using the custom session handler, is there any chance that you are setting any other session parameters (session name, session cookie path, session cookie domain) in your various include files and when you temporarily change the code to stop the custom session handler from being used that you are also either stopping some too restrictive session parameter settings from being used or allowing some more general session parameter settings to be used? It would help if you posted the whole URL that is in the browser's address bar for the pages you described and for the cases where the session variables worked on those pages and where they did not. Alter the domain name if you don't want to post that information, but accurately show any www. or no www. and any paths that are in the URLs. Why are you using a custom session save handler at all? It is only needed in a very limited case (multiple web servers under one domain that need access to the same session data) and since it uses parsed, tokenized, interpreted php code and has extra overhead for the database queries, it is slower than using the built in file session save handler. Edit: Also when switching back and forth between using the custom session save handler and not using it, are you completely closing your browser so that any session id cookie is deleted or if you have set the session cookie lifetime to a non-zero value, are you manually deleting the session id cookie in your browser so that you will start a new session with the matching session data in the correct place?

So, is this database table even being used to hold anything besides the project number/autoincrement column? Your first post states that the form doesn't insert into the table. If all you are doing is generating the project number, execute an INSERT query to insert the next auto-increment value, followed by a mysql_insert_id statement to get the id.

Slightly off topic, but now that I am somewhat up to speed on what that data means, if you were doing this query for security purposes, you would want the suggested AND um2.meta_key = 'wp_capabilities' in the query so that someone could not just store "administrator" or a higher user level string as a value in any one of their meta_value fields and magically become an administrator or gain a higher user level.

I just installed the latest of wp and that s2member script and when you create a field in the profile and update the value (tested multiple times, different values, then back to a zero), it updates the one single row in the database. The row is initially created on the first edit/update of the value. It would appear that your sets of two rows for wp_s2member_custom_fields with the same user_id are due to multiple data insertion in your database and are not the result of the operation of the script. Edit: I would make the user_id/meta_key columns a composite and unique index to prevent duplicates.

Any chance that the non-zero 'country' value is the 'active' one? (The current version of that plugin apparently stores a two character country code, not a number.) The current version of that plugin actually calls a wp function to get the data. I doubt it expects more than one matching row. Someone (I don't have the time right now) might want to trace through the code for that plugin and the relevant function in wp to find out if it does anything special when a request for user information matches more than one row.

You assign the value that unserialize() returns to a php variable - $arr = unserialize($str);

That's the output representation that the print_r statement uses so that you can identify what is what. The array keys are just fine.

At this point, because the point of storing serialized data, is to store an array in a database, I suspect that there should only be one row with the wp_s2member_custom_fields per user_id and when you edit your profile, it reads that row, modifies the values, and writes the result back into that row.

Since I don't know what the umeta_id value means, I don't think I can offer any further assistance. One could start making assumptions about it, but one could also make an assumption that wp would not store the same data in two different rows (the two sets of wp_capabilities are identical for that user, but with different umeta_id values.)