PFMaBiSmAd

You would display anything you want, such as an empty string, when your code detects a null value for any field value.

For an empty numerical value, the sql syntax is broken (i.e. two consecutive ,, commas) and produces a sql syntax error. With the single-quotes around a numerical value, it is treated as a string containing a numerical value and an empty string is converted to a zero. There are two ways to get the default/null sql value to be used - 1) Don't put the field name into the field list (this will require you to dynamically build the field list in the query statement) and don't put the value into the VALUE list. 2) Put the DEFAULT or the NULL keyword in as the value (with no quotes around it inside the query statement.)

You need single-quotes inside the query statement around string data, otherwise mysql will treat the string as an identifier. You also need to escape string data (doing so prevents special sql characters from breaking the sql syntax and it will prevent sql injection by hackers.)

Ummm. You didn't show us what the string is that doesn't work? Anyway, you need to use your database class's escape function (mysql_real_escape string or mysqli_real_escape_string) on ALL string data that you put into a query that could contain any special sql characters that could break the sql syntax of the query statement.

Also, the code that Zephni posted is undoing (stripslashes) the escaping that it adds to the username, so it is possible to satisfy the log in code without knowing the password (you just need to know, find, or guess any username that is in the table) and since the unescaped username is being stored in a session variable and re-used in other queries, all the queries using that value can be bypassed.

It's also highly likely that you configure the selections through the Prestashop admin panel. Have you tried asking on their help Forum?

The template should only define the layout/style and in this case the text legends. The actual data is defined elsewhere. I would guess in the '/config/config.inc.php' file.

If all you are trying to pass are numbers (in a comma separated list), there's no point in using serialize (the serialized data ends up with a lot of characters that urlencode must convert, which only makes the url longer.) <?php $ids = array(); for($i = 0; $i < $cart["idx"]; $i++) { $ids[] = $cart[$i]['product_id']; } ?> <a href="/test/getcart.php?cartinfo=<?php echo urlencode(implode(',',$ids)); ?>">test</a> <?php if(isset($_GET['cartinfo'])){ $ids = explode(',',$_GET['cartinfo']); var_dump($ids); } If you eliminate the ['idx'] business from your cart, you can more simply use a foreach loop any time you need to iterate over the cart. You don't need all the extra code to maintain the idx/number of items in the cart. Also, ALL your code will be much simpler if you store the cart in a session variable - $_SESSION['cart'] and solve what ever problem you were having with session variables. Edit: It will also simplify things even more if the cart[xxxx] index is the product_id. You can just get the array_keys to get a list of products in the cart and while iterating over the cart, using a foreach loop, the key is the product_id.

Only some of the array functions modify the source values that they expect to be passed by reference. None of the functions in this thread are coded to do so and produce a 'Call-time pass-by-reference has been deprecated' error to boot. <?php $a = ' s '; // space s space trim(&$a); var_dump($a); // string(3) " s "

Also, if allow_url_fopen is enabled, both file_exists and readfile can operate on files using some of the url wrappers and the posted code could be used to read files from a different server and output them. If allow_url_fopen is enabled, you need to turn if off, if possible, and you should always validate/filter ALL eternal data. If $filename is expected to be only a filename.ext, make sure that's all it is.

str_getcsv in available in PHP 5 >= 5.3.0

^^^ Just calling those functions doesn't do anything, because each of those functions returns the resulting string to the calling code. You must assign or use the return value.

I use notepad++ - http://notepad-plus-plus.org/ Dreamweaver has never been very server-side code aware.

And the single-quote(s) above those... You need to be using an editor with code highlighting and use <?php (lowercase) for your opening php tag (at least the forum highlighting doesn't see the <?PHP, perhaps your current editor doesn't either.)

The N%3B value is a N;, which is (apparently, just tested using serialize(null)) what serialize produces for a null or non-existent value. That implies that the value you are supplying to the serialize function doesn't exist at the time you are calling serialize.

There's nothing wrong with the snippets of code you posted (works for me as expected with some made up data.) Either your actual code is doing something to the value or the data is too long to transfer through a URL (browsers and web servers have limits starting around 2000/4000 characters for the complete URL) or you have some URL rewriting that is not carrying the get parameters or you are redirecting and not carrying the get parameters. How long is the string in $strenc? All you need for a cart is an array of product id's and the quantity for each id.

If that output is after the form has been submitted, its likely that the size of the file exceeded the post_max_size setting (which causes both the $_POST and $_FILES arrays to be empty - http://www.php.net/manual/en/ini.core.php#ini.post-max-size ) or uploads are not enabled on your server or the form is invalid or the form does not have a type='file' input field. What size file did you attempt to upload?

I'm not sure it is possible to help you further with this. You don't seem to know your own code (to the point of not being able to identify where you would replaced lines in it with a statement that I modified for you) and seem to be lost over what it is, where to put it, or how to use most of the information that is being posted, which is probably why El Chupacodra posted his reply above. So, to just recap, before I ignore this thread - The session code you put into the start of the treats.php file doesn't actually do anything toward using session variables to hold the cart contents, because the treats.php page isn't POSTED to by a form and that code won't ever assign anything to the session variable (you also wouldn't blindly use external data without validating it first.) You also don't have any code anywhere else to use the data stored in the session variable. You seem to have hacked together and added a few lines of code to one of your files, posted your code in a forum, and hope someone can figure out what you are trying to accomplish and will fix it for you. Sorry, but we cannot figure out from that attempt what it is you are trying to accomplish and we aren't here to think through and write your whole application for you. ^^^ Someone then did post the code you would need to change (i.e. Your echo statement(s) on the treats.php page would be..) and posted an example of the resulting data that would be submitted (i.e. your $_POST array will end up looking like the following...) Your treats.php code doesn't have that many lines of code in it and not many echo statements, but you didn't seem to get it that you are expected to take the supplied information and know enough about your own code to be able to apply that information to what you are doing. Once your treats.php page is submitting the $_POST data you expect, it is up to you to write the correspond code in your checkout.php page to use that data. There's at least two replies of yours where you seem to think the example of "your $_POST array will end up looking like the following..." is something you put into your source code. I'm afraid not, but that only confirms that you don't understand what your own code is currently doing or that the form's submitted data will be received in the $_POST array in the checkout.php page. Lastly, here is something I posted above - Programming is like writing a Math Word Problem and then solving that math word problem. You must have a clearly defined and stateable goal before you can write any code to accomplish that goal. This thread doesn't have any apparent goal, which is why it has not gotten very far, and I even questioned the intent, but got no reply - Before you work on your code further or ask for more help with your code, you need to define what you are trying to accomplish (I suspect it has something to do with storing the cart in a session variable so that your update/delete ajax code will have something to operate on) so that both you can write code that has meaning toward that goal and someone here will be able to post replies having something to do with achieving that stated goal.

If you mean copy rows from one table to another, yes, you would use an INSERT ... SELECT query -

Yes, that would cause the quantity for each product_id to be submitted in an easy to use format that you can test for and process. There's also no need to loop through the entire contents of your database table in the checkout.php page. You can simply filter the quantities that are not empty and then directly query for just the matching rows from your database table. I would also hope that your product_id's are the auto-increment index values (will result in the least amount of data and the quickest queries.)

There are a number of existing database display/edit scripts with pagination/column ordering - http://www.phpmyedit.org/

I have looked at your checkOut.php code further, and if your intent (per the title of this thread) is to store the cart contents (id/quantity) in a session variable, where's your code to do that? There's nothing in the posted code that stores any of the cart information in a session variable. I recommend that you first define what you want to do, then try to write (and test) the code to do it.

As already stated, there is no $_FILES array when you exceed the post_max_size setting. There's nothing to loop over (you are likely getting php error messages when you do try.) You need to test for the existence of the $_FILES array and/or test the $_SERVER['CONTENT_LENGTH'] against the post_max_size value.

You should check the ['error'] element for that particular problem. http://www.php.net/manual/en/features.file-upload.errors.php Note, exceeding the post_max_size setting will result in both the $_POST and $_FILES arrays being empty. Also an invalid form, a form with no type='file' field, and uploads not enabled on the server will result in an empty $_FILES array. You can get the actual size of the uploaded file in $_SERVER['CONTENT_LENGTH']

Further to the above (concerning using one table for all your products.) Your checkOut.php page queries against the `treats` table, but it has no queries against the `specialty_treats` table. There's no way your current checkOut.php page will work correctly if someone selects something form the specialty_treats table. Use one table for all your products or you will be forever writing duplicate sections of code or forgetting to write them as the case may be. You also have a hundred plus dog breads in a select menu. Why did you write out all that code? You should either have a database table with that list in it or at a minimum an array with the list. You would then have about three lines of php code to produce all the options.