PFMaBiSmAd

You are (apparently) redirecting/linking to different variations of your domain name, both with and without the www. on them, and you are also redirecting/linking to different paths after your domain name. Unless your session id cookie is setup to match those variations/paths, the session id cookie will only match the exact domain-variation/path where it was set at. What does a phpinfo statement show for the session.cookie_domain and session.cookie_path settings? To match all variations of your domain name (with and without the www. on them), the session.cookie_domain setting must be .yourdomain.com (with the leading dot and of course using your actual domain name.) The session.cookie_path setting should be a / to match all paths after your domain name. BTW - you only need a session_start statement on a page that sets or references a $_SESSION variable (the second piece of code you posted at the start of this thread doesn't seem to use any session variables, so I'm not sure why you even posted it), and if you happen to be passing the session id in the URL, which you are probably not, then you have bigger concerns then to worry about how search engines see you site.

Other than the $option_name/$option_id, which you are not setting, I don't see anywhere in your cart data where you have used the 'prints' option value for the item? Have you stored that value in the cart at all? That would be the first step, making sure that your cart contains the data it needs for each item.

Your code worked on your original hosting because register_globals were on and the php program variables ($studentsname, ... ) being used in the $body that matched the $_POST index names were magically being created. The lines of code setting the variables with Field on the end of them ($studentsnameField, ...) were just taking up space in the code and weren't setting variables with names that were being used in the $body variable. On your new hosting register_globals are off, or even completely removed (they were depreciated and turned off over 10 years ago, and were removed as of php5.4) and there needs to be lines of code like - $studentsname = $_POST['studentsname']; to get your code to work.

Your database design is bad, making this task about 5 times harder than it needs to be. You should be storing each separate piece of information in its own row in your table. Then the task would be easy, just add a row and if you are trying to limit the number of entires, just count how many of them there are, by getting a count of the matching rows.

The two ini_set() statements you added don't do anything because those two settings cannot be set inside of a script. They must be set in the master or local php.ini, because php uses them before it transfers control to the .php script. Also, they affect the size of the uploaded file and don't have anything to do with how your resize script runs. You need to set php's error_reporting to E_ALL and display_errors to ON, which you can set in your script, to see what kind of php detected errors are occurring.

Here's some hints for your option menu - 1) You should assign and use an id(identifier) to data items so that you produce and send the minimum amount of information back and forth between the browser and the server. Your option value="..." attributes would simply be the assigned identifier for that option. You would have a data structure (array, database table...) that associates the item identifier to the rest of the information for that item, such as the price, and the description. Also, by have the definition of the options in a data structure, you can let the computer produce the option list, rather than you doing it and fixing all the typo's ... You only need to maintain the defining data structure to add, change, or remove option choices. 2) AFAIK, <option> tags don't have names, so there's no point in the name="..." attribute in the <option> tags. 3) Unless you are specifically using the id="..." attributes, don't put them into the markup. Also, since id attributes must be unique, using the price as the id value would prevent you from correctly repeating that select menu on a page or having any other id with the same price as an existing one. 4) The only place you should actually have and use the price of an item for any calculation is on the server. Any price you output to the browser is for display purposes only. The visitor can submit any value for any form field, so accepting the price from the visitor will mean that you will be selling a lot of things for a lot less they their actual price (or you must now add extra code to make sure that the submitted price is correct.) 5) You should not repeat information - DRY (Don't Repeat Yourself.) For example, each price is now repeated 4 different times (ignoring the things you don't need in the markup.) What happens when you need to change the price of a choice? You must find all the occurrences and modify them. Storing the defining data in a data structure will mean that the price, description, and any other specific information will only exist in one place. 6) You are missing a closing </select> tag. The following is sample code that does the above - <?php // define the print options (array key is the id/identifier) $print_options[1] = array('price'=>175.00,'name'=>"11x14 Canvas Wrap"); $print_options[2] = array('price'=>250.00,'name'=>"16x20 Canvas Wrap"); $print_options[3] = array('price'=>280.00,'name'=>"20x30 Canvas Wrap"); $print_options[4] = array('price'=>325.00,'name'=>"30x40 Canvas Wrap"); $print_options[5] = array('price'=>20.00,'name'=>"4x6 Print"); $print_options[6] = array('price'=>30.00,'name'=>"5x7 Print"); $print_options[7] = array('price'=>50.00,'name'=>"8x10 Print"); $print_options[8] = array('price'=>75.00,'name'=>"11x14 Print"); $print_options[9] = array('price'=>100.00,'name'=>"16x20 Print"); $print_options[10] = array('price'=>125.00,'name'=>"16x24 Print"); $print_options[11] = array('price'=>150.00,'name'=>"20x30 Print"); $print_options[12] = array('price'=>175.00,'name'=>"24x36 Print"); $print_options[13] = array('price'=>200.00,'name'=>"30x40 Print"); $print_options[14] = array('price'=>250.00,'name'=>"40x50 Print"); $print_options[15] = array('price'=>300.00,'name'=>"40x60 Print"); ?> <form action="cart.php" method="post"> <select name="prints"> <option value="">Select a print size</option> <?php foreach($print_options as $option_id=>$option){ echo "<option value='$option_id'>{$option['name']} - $".number_format($option['price'],2)."</option>\n"; } ?> </select> <input type="hidden" name="pid" id="pid" value="<?php echo $id; ?>" /> <input type="submit" name="button" id="button" value="Add Selected to Shopping Cart" /></form><br /> When you submit the above form, you would store the submitted option value (which is the option_id) in the cart for the item it goes with, which I would guess is your pid value. When you display the cart, you would take the option_id value for each item and use it to access the price and description(name) from the data structure where you have the information stored (i.e. the $print_options array in this example.)

The HTTP request that the browser makes must be to a publicly accessible .php file that then reads the actual file and outputs it with the correct content-type header followed by the contents of the file. The actual file id/name is specified on the end of the url as a GET parameter (file.php?id=123 or via url rewriting (somepath/123)

You have a previous thread concerning output being echoed in functions. Did you read that thread - http://forums.phpfreaks.com/topic/272367-function-echo-vs-return/

By using session_write_close() in your authentication logic, the $_SESSION variables after that point are just regular program variables and anything you do to them won't be saved to the session data file. The only time you need to use session_write_close is if you have a page that takes a long time to generate (the php script is still running) and things you link to on that page also have a session_start statement that need to access the same session as the main page. These would be things like dynamically generated images, css, javascript, iframe, page requested by javasciprt/ajax, ... that use session variables. If you do use session_write_close, you would use it ONCE on a page, after the last place where you assign or unset any session variables.

Without all of your code that would be needed to reproduce the problem, it's just a guess what is causing it. The fact that you just mentioned that there's some javascript as part of the problem, opens up about 3 more possibilities, in addition to the original 3-4 things that could be causing the problem. Post the exact code that we would need that reproduces the complete problem, less anything like database credentials. And since you are just trying to clear one session variable that holds a status message, you would NOT want to use session_destroy.

If you change this code - while($result = mysql_fetch_assoc($query){ $startList[] = $result; } To this - while($result = mysql_fetch_assoc($query){ $refactorList[$result['assoc_menu']][] = $result; } you can eliminate that entire middle loop. To detect if there's only one item in the menu, inside the last foreach(){} loop, you would test how many entires are in the $menu array using count and decide if you need to output the link as a button or loop over the $menu array and output it as the drop-down menu (the existing contents of that foreach(){} loop.)

Php has a GD image extension that is typically used to resize images. If you search for PHP GD resize script, I'm sure you can find something to try/test with.

That <form tag cannot upload a file. It's missing the enctype="multipart/form-data" attribute.

Either uploads are not enabled on the server or the size of the file you are trying to upload is larger then the post_max_size setting, or you actually have something different about your form, such as nesting it inside of another form or the <form tag doesn't have the enctype attribute. What does a phpinfo statement show for the file_uploads and post_max_size settings and what size of file did you try to upload?

If the same code works on a different server, your form is likely okay. Unfortunately, the upload code you are using is based on the w3schools example and it is crap. It tests for upload errors after it has tried to use some of the uploaded file information, so if there is an upload error, that code will indicate an invalid file and will never actually display the upload error code. You must test if the upload worked before you can use any of the , [type], [tmp_name], or [name] values. There's a whole host of other problems with that code, such as not lumping together the type and size validation tests, because you will never know which condition caused the validation to fail (wouldn't it be a good idea to tell the visitor if the file was the wrong type OR that he uploaded a file that was too big, so that he could correct what he did), and when validating user supplied input, you should display the incorrect value that failed a test, along with the accepted values. For debugging purposes, add the following code right before the code that you posted - echo '<pre>',print_r($_FILES,true),'</pre>';

$images = glob("$root/$cat/$prod/*_LARGE.{jpg,JPG}", GLOB_BRACE);

It would probably help if you posted an example of the file name(s) you are trying to match.

The point in your query where the error is being reported at - near 'write ... is because mysql found a keyword in a location where it is not permitted. Write is a reserved keyword. You should change your column name to something else or you must enclose it in back-ticks `write` every time you use it in a query.

You wouldn't. You would change the * wild-card character in the glob() search pattern to match the files you are interested in.

Your code is missing the first row because you have the following line of code that is fetching and discarding the first row in the result set - $row = mysql_fetch_array($query); Why do you have that line of code in your code?

Changing the array index to be the item_id will also have the benefit of making your 'remove from cart' code so that it won't keep removing other items if you refresh the page. You should always act upon data items by their specific id/identifier, not by their position in a list/array.

Can that code be simplified, yes, greatly. If the cart array index is changed so that it is the item_id - $_SESSION['cart_array'][$pid] = array(....); all the code for adding, removing, and getting the details for the items, can be greatly simplified - if (isset($_POST['pid'])) { // add (+1) item to cart $pid = (int)$_POST['pid']; // cast as integer // valid pids are > 0 if($pid > 0){ if(!isset($_SESSION['cart_array'][$pid])){ // item is not in the cart, add it with quantity = 1 $_SESSION['cart_array'][$pid] = array("item_id" => $pid, "quantity" => 1); // I left the array in the cart the same, but it could also be simplified so that it is only the quantity, since the item_id is now the cart array index } else { // item is in the cart, increment quantity $_SESSION['cart_array'][$pid]['quantity']++; } } header("location: cart.php"); exit(); } To get the details for the cart items, you need to run ONE query that gets all of them at the same time (putting a query inside of a loop is a resource killer.) For the definition of the cart that I have suggested, you can use array_keys to get all the item id's. You would then implode those into a comma separated list and put them into an IN() comparison in the WHERE clause in a query to get all the matching rows at once.

<?php $root = 'products'; // the root folder containing the category/product folder tree // list categories - $categories = glob("$root/*",GLOB_ONLYDIR); if(empty($categories)){ echo "No product categories found."; } else { echo "Choose a category -<br />"; foreach($categories as $category){ $category = basename($category); echo "<a href='?cat=$category'>$category</a><br />"; } } // if a category is selected, list the products $cat = isset($_GET['cat']) ? trim($_GET['cat']) : ''; if($cat != ''){ echo "Choose a product under - $cat<br />"; $products = glob("$root/$cat/*",GLOB_ONLYDIR); if(empty($products)){ echo "No products found."; } else { foreach($products as $product){ // code to use the $product folder name here... } } }

The biggest issue with this thread and the last one is we don't know, and I don't think you have defined, what output you want after you click on a category? For example, your latest posted code in this thread is trying to put an &pdf=$file on the end of the 'folder'/category links. Why would you do that? The categories don't have any information about any pdf files. When you click on a category, what do you want to see in front of you? A) Just a list of products, as links to a details page and the details page is where the images/pdf links would be at, or B) A list of products, with the images and pdf links next/under each product name?

Echoing output inside of a function will output that content at the point in the code where the function is called. In general, functions should return the result they produce, so that the function call is essentially replaced by the result the function produced.