mrMarcus

Yes, but please hurry 'cause the suspense is killing me.

Pseudo: $sql = "SELECT `first_name`, `last_name` FROM `users_table` WHERE `user_id` = 5 LIMIT 1"; // obviously change query for your needs if ($result = mysql_query($sql)) { if (mysql_num_rows($result) == 1) { $row = mysql_fetch_assoc($result); // being your cURL block $ch = curl_init(); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, array('first_name' => $row['first_name'], 'last_name' => $row['last_name'])); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_exec($ch); curl_close($ch); } else { echo 'No record found.'; } } else { trigger_error(mysql_error()); } There are more curl_setopt() you might want to look into; I just used the basic to get you going.

Yes, use curl.

$sql = "SELECT * FROM table WHERE productdbase = '$ID'"; You will obviously have to ensure 'table' is your table name and 'productdbase' is the field name that stores your ID's. And, of course, there will have to be a matching record in the table to that of $ID for it to return any results. Use mysql_real_escape_string with your variables before inserting them into your queries, ie: $sql = "SELECT * FROM table WHERE productdbase = '". mysql_real_escape_string($ID) ."'";

Not that it's "undone", just that there is no sure way of that same user ever retrieving his/her data ever again with all the said variables. They could spend 6 hours saving all kinds of data one day, wake up the next morning and their IP address has changed. Now, you're system would be verifying a user based on their IP address, and all of a sudden, Tommy down the street now has access to your data because his IP is associated with the user data you saved the day prior.

This is why error handling is crucial. Use it always on development systems.

So this is just a matter of preserving the login status and not about saving personal data to the site, correct? E.g., storing my name, address, phone number.

Going back to your initial goal. Are you looking to achieve long-term personalization and storage of data related to any one specific user?

I just wanted to see if OP had a basic understanding of how $_GET worked. And yes, all you have to do is simply pass the ID of the product in question, and query your products table with that ID, like the script posted above.

The method that you're referring to here would only provide temporary personalization, at best. Let's not get confused into thinking that a method such as this would provide any sort of legitimate method of storing any specific user-based information for the long-term, such as a site like PHPFreaks.com. With that clear, if you're looking to validate a user against an IP address (as well as browser, etc.), and that IP address changes on their PC at home (as they often do), then their data would be no longer available to them. Cookies are not used for validation against a database, or at least they shouldn't be. Cookies might be used for simple personal preferences such as "don't show me that popup again" or by changing the background colour of a site (amonsgt a bunch of other simple tweaks [saving ones username for easier login]). You just answered your own question right there ^

Edit: misread code. Tip: only pull from a table what you will be using in your script. For example: $sql = "SELECT * FROM users"; is overkill when you only need to access `name`. Revise, and subsequently keep in mind for future queries, to the following: $sql = "SELECT `name` FROM users";

Hi, I tried this and it echoed the price only, not the ID So, it echo'd 123 as the price, but nothing as the id? That can't be.

No security in that plan whatsoever. What about shared computers? IP address changes? Multiple browsers? The user will never be able to retain any information/data with a site using that method as there is no indefinite way of relating any data to any specific user as there are too many variables. Is good that you're trying to think outside the box, but in this case, it's best to just stick with the norm unless an application truly needs something different.

http://www.example.com/index.php?price=123&id=321 Take that URL, swap out 'example' with your domain, and 'index.php' with whatever the path is to your file. Put: echo 'Price: '. $_GET['price'] .'<br/>ID: '. $_GET['id']; in that file, and have a look at the results.

Please post your updated code.

You're looking for an alternate to using cookies?

You mean the same values are inserting into the database when you hit refresh on the browser? That's expected. If not, please elaborate.

Could be a number of things. The IP of the server you're sending email from might be blacklisted on receiving servers. You might have wording in your subject line and/or body that are typically flagged as spam-like, ie. "Free iPods!!! Click here!!" is the idea. (Spam Words to Avoid in Emails - a list of words that can trigger spam detectors) You might not be sending proper email headers. And the list goes on... nobody truly knows how to be 100% effective in getting your email into inbox's, and if you do, you stand to make lot's of $$$ selling the technology. Post some relevant code of your email script... we can start there.

empty() will return true if there is a value of 0. So, if you want to allow the value "0" you can't rely on empty(). Although since there is no strict comparison to 0, it is still flawed... since empty == 0. It should be: empty($_POST[$requried_fields]) && $_POST[$requried_fields] !== 0) Ya, I know all that I don't see why a username or password would have a value of 0 though, which is why I don't believe his/her intentions were to allow a value of 0. Wouldn't make any sense, anyways. Feel like I'm talking myself into a circle lol. Assuming zero(0) is not an option, that statement should only be checking the isset() and empty() on $_POST[$required_fields]. Without proper parenthesis to give distinction on which conditions should fire when, you're left with the natural order of precedence (&& before ||). Having " .. && $_POST[$required_fields] != 0 .. " in conjunction with the isset() and empty(), and having && take precedence over the || you're left with, basically (rewritten): if ((empty($_POST[$required_fields]) && ($_POST[$required_fields] != 0)) || !isset($_POST[$required_fields])) { Which, in Layman's terms, is like saying: $_POST[$required_fields] must be empty AND must contain a value. I'm basing my thoughts off of the code as I see it, not how I try and decode it in my head. Had they used a strict comparison on the final condition, it would have been easier to see what was going on and their intentions of that condition. Don't take this as a pissing contest, I just like a little back-and-forth problem solving from time-to-time

target="paypal" should just open the link in a new window called paypal. The target attribute in HTML has set values: _blank, _self, _parent, _top, as well as to reference a <frame> within the same document. "paypal" is not one of them. Chrome must just be insanely picky. Regardless, target="paypal" is not valid. It is also a field to assign the name of a blank target window. So target="paypal" will open a blank window with target name of paypal. Lets say you were to click another link with target paypal after opening the first one. Instead of opening that second link in a new window it would load in the _blank window created by the first link. target is used to direct content to a frame/window that has already been assigned that specific target name. It does not assign the new window/page/tab, etc., with the given attribute value (name). There might have been more code that came with that PayPal button that worked in conjunction with the button, for example, a frame/iframe that when the button was clicked, a(n) (i)frame with the name "paypal" would receive data and do something. But without any said (i)frame, Safari must have spazzed out.

I'm trying to understand what this set of conditions does: if (!isset($_POST[$requried_fields]) || (empty($_POST[$requried_fields]) && $_POST[$requried_fields] != 0)) Check if it's not set OR is empty && does not equal 0. The last 2 cancel eachother out. You're checking to see if it's empty and also if it's not empty. And nowhere in that function is $fieldname set, yet you're using it in your second condition block.

if (!isset($_SESSION)){ session_start(); } This is redundant. Remove the condition and just place session_start(); in its place.

This will work, yes. I like to use strict comparisons on $_SESSION values as sessions can be hijacked in a similar fashion to cookies. That meaning, if you set your $_SESSION['LoggedIn'] variable to (bool)TRUE during a successful login, then you might as well check it to ensure it still contains that bool type. If you lazy out and do something like the following: if ($_SESSION['LoggedIn']) { // this has no comparison checks other than whether $_SESSION['LoggedIn'] has a value; is widely used by developers (unfortunately) Then that $_SESSION['LoggedIn'] variable could be anything and still return true, executing your code and allowing the user to get in. Summary: == has a purpose, as does ===. Just know when to use them, and when not to.

If that's your base.php file, then yes, I would suggest placing it in there as it seems all your scripts are accessing $_SESSION. Instead of having to include it in each file since you're already including base.php anyways. PHP Comparison Operators Comparison operators are situational. == vs === are quite different. == is not as strict as === as: $foo = true; if ($foo == 'true') // success // and if ($foo == true) // success are both valid and will return TRUE/success. However, this is where things can get tricky if you don't have a firm grasp of what each comparison operator does: <?php // http://www.example.com/?id=12345 $id = $_GET['id']; if ($id === 12345) // fail; $id is a string and 12345 is an integer; they are of same value, but NOT type if ($id == 12345) // success if ($id == '12345') // success if ($id === '12345') // success ^ not applicable to your application, but just a quick tutorial on these 2 operators. There are times when this comes in handy as you can probably see why. Whenever you can check a variable type, go for it. However, this can lead to a lot of noobie problems if you don't fully understand their differences. Flip side: <?php $id = 12345; if ($id === 12345) // success; same value and type if ($id == 12345) // success if ($id == '12345') // success if ($id === '12345') // fail $id is a set integer, so the last comparison will fail as it's a check against $id having a value of 12345 and a string.

Make up your mind. Downloaded by whom? Something like what? Please include more details.