KevinM1

I don't recall anyone stating that you cannot get sessions to work when cookies are turned off. I thought you and Thorpe recommended I use Sessions that require Cookies, right? Well, if Joe User has "Cookies Off/Blocked", then the Session won't work, right? Debbie Easier to link to some answers than rehash them: http://stackoverflow.com/questions/3740845/php-session-without-cookies But, really, this is 2011. If someone has cookies turned off, they're doing it wrong.

This topic has been moved to PHP Freelancing. http://www.phpfreaks.com/forums/index.php?topic=331336.0

You put everything within that case inside of the body of the if(isset($_POST['update'])) conditional. You then remove that case from your switch as you're not checking whether you have an action which equals 'update'.

You'd put the $_POST check in cart.php. It's replacing action=update. You can do that (and everything else) a lot easier through jQuery. jQuery GET: http://api.jquery.com/jQuery.get/ jQuery POST: http://api.jquery.com/jQuery.post/ As an example, instead of using ajaxpage(), you'd write something like this: $.post("cart.php", { id = 1 }, function(response) { /* this function is a callback function, which is executed after the data is sent to the PHP script, and it contains the response sent back by the PHP script */ });

Have you, you know, tried it?

Here: $name = $_SESSION["username"]; Why yes, apparently it is.... You're drinking earlier than usual Well, if you start from yesterday, then it would be way later than usual.

Here: $name = $_SESSION["username"]; Why yes, apparently it is....

Also, where's $name coming from?

I think you'll need to change your PHP a bit. Right now, you're trying to play with both GET and POST simultaneously with your update code. You don't need to use GET in your case. Simply make your update button a normal submit input, and give it a name. Then, you can check to see if it exists on postback and handle the update from there. Something like: if (isset($_POST['update'])) // we're updating the cart from a normal form submission { // update code } And your form: <form action="cart.php" method="post"> <!-- inputs --> <input name="update" type="submit" value="Update" /> </form> That said, for any submissions that make a change to stored data (like adding an item, or updating an item), you should be using POST. That's how their behavior is defined in the HTTP spec, and it makes things easier overall. GET is for retrieving (getting) data only. POST is for modifying existing data. Is your ajaxpage() code something you wrote or does it come from someone else? I ask because you'd be better off using a bit of jQuery to make the cart additions. You're quickly moving into "round peg in square hole" territory here, both with the ajax and PHP, and I think you're better off in the long run refining your overall design rather than trying to patch things as you go.

Can you show your particular queries? Chances are, you can combine some of them.

If your 'Remove' code is the same as the code you just gave me: $output[] = '<td class="tdcart"><a href="javascript:ajaxpage(\'cart.php?action=delete&id='.$id.'\', \'content\');">Remove</a></td>'; Then the same problem as before is happening. The link, when rendered, becomes: <a href="javascript:ajaxpage('cart.php?action=delete&id=someid, 'content');">Remove</a> The output from cart.php is getting placed in your <div id="content">. The reason why it's not happening when you click "Update" is because that's a plain form submission button. It's not doing anything with ajax. Rather, it's simply posting the form data to the URL in its action attribute, which in this case is cart.php?action=update. Now, when you say you don't get any update, what do you mean, specifically? Is the cart data itself not being updated?

Okay, so it's doing exactly what I thought it was doing. Good to know. Your best bet is to simply remove (or comment out, which would be better if you need to go back to the way it worked some time in the future) all JavaScript that relates to the loadpage() function, since you simply want to pass info to cart.php without loading a new page. If you don't feel like mucking around with the innards of your JavaScript, simply use a bogus value for the second parameter sent to ajaxpage(), like: ajaxpage("cart.php?action=add&id=1", "null")

Can you show your entire script?

Here you go: http://cssfreakie.blogspot.com/ Written and maintained by one of our own Gurus, cssfreakie.

Slow down a second. What are you trying to do? Explain it step-by-step.

The reason why you're not getting any values is because the register_globals ini directive is turned off by default in PHP 5. This is a good thing, as it forces you to retrieve values passed into your scripts from the appropriate superglobal arrays: $_GET and $_POST. Register_globals was a security flaw, as it blindly transformed anything coming into a script into a variable. So, someone could simply write: http://yoursite.com?admin=1 And now there's a variable named $admin in your script containing the value of '1'. Very dangerous if you don't validate your variables. PHP 5, like I said, removes that flaw. It forces you to explicitly grab the values you want. In your case, you'd need to use: if (!empty($_POST['ilText'])) { $Reftext = $_POST['ilText']; } else { // error }

Okay. I'd like you to put your link code back to the way it was when it was redirecting you. Once you do that please click on the link. After that, I'd like you to answer the following questions: Is the browser actually taking you to another page? Or is your <div id="content"> being filled with what's in cart.php? Can you compare the HTML in body.php that exists after you click the link to what's generated by cart.php? Can you see if you're getting any JavaScript errors after you click your link? Here's the reason why I'm asking these questions: like I've said, the ajaxpage() function anticipates the PHP script it talks to will send a response back. It takes this response data and stuffs it in the element of the id given as the second parameter. So, if you have: ajaxpage("cart.php?action=add&id=1", "content") It's going to send the GET data to cart.php, and then capture any response sent back by cart.php and insert it into the element in body.php specified by the second parameter, which in this case is <div id="content">. What do I mean by response? Well, anything outputted by cart.php is a response. This includes raw HTML when you exit PHP-mode in your files. So, I'm betting you weren't being redirected at all. Instead ajaxpage() most likely took all of the output generated by cart.php and placed it within body.php's <div id="content">, which would overwrite everything that was in there prior to the link being clicked. You would still be at body.php, but it would likely look like you were at cart.php. So, why does your modification 'work'? Like I also said above, you were passing ajaxpage() a bogus value for the second parameter. The function was looking for an HTML element within body.php with an id of body.php to put the response data in. Since there is no element with that id, that part of ajaxpage() silently fails. This ultimately results in the first part of the process - sending the GET data asynchronously - working fine, but the second part of the process - putting the response on the page - having no impact.

Okay, so $cart just a comma separated string of IDs.... Where does the actual database insert/update happen? I see the $cart being passed around through sessions, but not a lot more than that. And do you echo/return anything after the entire process is done? Please show code.

Where is the code you use to add an item to the cart? ajaxpage() sends data to cart.php?action=add&id=1. This means you must do something in cart.php with $_GET['action']. That is the code the JavaScript is invoking, and that's what's supposed to be sending a response back. That's the code I need to see.

You're not really understanding me. I need to see what add does. Not a generalized description, but actual code. That way I can see what response, if any, it gives back. Also, I never thought you had an HTML element with that id. That's the entire point - like I said, ajaxpage()'s second parameter is supposed to be the id of an existing element so it can put the response from cart.php's add action in it. Your 'fix' had you supplying body.php for that value. Since no element has that id, the response is being lost, which is likely why you're not being redirected. This is why I need to see what add does. I need to verify my hypothesis.

Wow... okay, this is going to be long, so bear with me. First, never, ever, ever use 'global'. EVER. This goes for both procedural programming and OOP, but especially with OOP. 'global' is the exact opposite of what OOP is all about, as it ties your objects to the environment in which they are created, nullifying their modularity and breaking their encapsulation. Regardless of how you program, you should always have clean, clear, and explicit function/method signatures. 'global' is not explicit. In fact, it creates an unknown (to the rest of the system) implicit requirement. Simply put, if a function/method requires a parameter in order to work, pass that parameter through the argument list. That's why it's there. Second, part of the 'magic' with OOP is that objects can contain permanent references to other objects. This is known as composition, and is what you should be using here. Here's how you do it: class Mysql { // class definition } class Person { private $db; public function __construct($db) { $this->db = $db; } // rest of the definition, which uses $this->db to do work } $db = new Mysql(/* connection args */); $person = new Person($db); echo $person->show_by_id(1); Third, your Mysql errors are never output to the screen. You still need to echo or print them. Finally, there's already an OO variant of MySQL in PHP - the MySQLi extension. There's also an even more abstract, database agnostic option called PDO. Chances are, you already have at least one of these, if not both, available to you. Unless you're doing this for your own learning, I suggest using one of them. mysqli pdo

From what I see, that's not really a work around. ajaxpage() takes two parameters. The first is the filename + query string (if necessary) of the PHP script you want to send the request to. The second is supposed to be the id of the element on the current page that will receive and display the response from the PHP script. What you did is 'working' because there's likely no HTML element on your page with an id of body.php. The response you get back from ajaxpage() is essentially being thrown away. So, again, what does your 'add' action do? It's the response it sends back that's key.

What does your add action in body.php return?

The problem is right there in your render method: $result .= "<form action=\"index.php?page=addID\" method=\"POST\">

Ummm. You wouldn't ever write hundreds of lines of code that only differ in the array index value they use. You would use a loop. Also, the global keyword only has meaning inside a function definition (and even there it should not be used.) Why do you have global $lgsl_config, $lgsl_zone_number; in your code? Good points, all. My eyes glazed over when I looked at the OP's wall of code, so I never noticed.