mrMarcus

Proper communication goes a long way. I have know idea what you're talking about. We have now just wasted time while I wait for proper reply from you.

Your form is a mess. You're querying the database many times to simply get a name or whatever for each table row. Query the database one time: <?php $query = "SELECT * FROM users WHERE id = " . intval($_SESSION['userID']) . " LIMIT 1"; if ($result = mysql_query($query)) { if (mysql_num_rows($result) == 1) { $row = mysql_fetch_array($result); ?> <div class="updateinputcell"> <li class="li_1" > <div class="forminputleft"> About Your Company: <?php echo $row['category']; ?> </div> <div class="forminputright"> <textarea class="element_2" name="aboutcompany" class="element textarea medium" value="<?php echo (!empty($row['aboutcompany'])) ? $row['aboutcompany'] : ''; ?>"><textarea> </div> </li> </div> <!-- CONTINUE WITH REST OF FORM --> <?php } } This simply pre-populates the form based on the user data from the db. However, depending on whether an application has proper error-handling, and let's assume it does, you will want to check if any $_POST data exists which will trump the user table data. Imagine editing numerous parts of a form only to have all your changes reset back to how it was when you started all because you accidentally put an integer in a string-only field. In a case like that, you would want to check if $_POST data is available to retain the user's current form state. However, that's another thread altogether, I'm sure.

At the end of the day you need to figure out if development is the path you wish to pursue as a career. If not, then feel free to continue with your coding style and logic. If you do wish to continue, you must start following proper logical design practices, especially when numerous pro's are advising you. Currently, you're taking the path of least resistance as you see it. However, what *might* be a little extra work (in your head) will allow you to build applications for use in large scale environments. With your current design, there is not a single developer who would be willing to work on that project (that I know of, anyway). One day, hopefully sooner than later, you will come around and start taking the advice of people who have "been there, done that". It's in your best interest.

Auto-populate your forms when editing. That way, if a user wants something deleted (if allowed), all they have to do if clear the field themselves. Pseudo: <form> <input type="text" name="last_name" value="<?php echo (!empty($last_name)) ? $last_name : ''; ?>"/> </form> Now, when they are at the edit stage, all their info will be pre-populated into the form and they can update whichever fields they wish.

When the user clicks the "Go to cart" button, you should then swap out the current form with the payment form: <form action="http://ww7.aitsafe.com/cf/add.cfm" method="post"> <input name="userid" type="hidden" value="94285118" /> <input name="product" type="hidden" value="Standard Edition" /> <input name="productID" type="hidden" value="2" /> <input name="qty" type="hidden" value="1" /> <input name="price" type="hidden" value="5.99" /> </form> And replace the "Go to cart" button with something like "Checkout »" with details of their pending purchase in place of the Quantity/Promo boxes. This is just a quick, easy fix. I don't like the process design of your cart IMO. I would also recommend auto-populating the Quantity input box with 1 as the customer will always purchase at least 1 of something.

Do you know how HTML forms work? You have that form stuck up at the top of the page (above the DOCTYPE), and without a button to call the form to action.

But your 'storing of images' logic is wrong. Finishing this code, unless it's being specifically requested by a client, is a waste of time. Create an `images` table and store all images in there. Then, join the table when necessary.

http://antibang.com/...ID=2#ad-image-0 I do not see where you have the following form on that page: <form action="http://ww7.aitsafe.com/cf/add.cfm" method="post"> <input name="userid" type="hidden" value="94285118" /> <input name="product" type="hidden" value="'.$productNAME.'" /> <input name="productID" type="hidden" value="'. $_GET['productID'].'" /> <input name="qty" type="hidden" value="'.$qty.'" /> <input name="price" type="hidden" value="'.$value.'" /> </form>

When I submit the form on your site I receive the following on the next page: Price = Promo = SANTA101 Product ID = 2

Radio box or dropdown select box. User selects what area they would like to login to.

And for the record, I have created websites similar/identical to your needs. One site in particular which housed real estate listings, rental listings, vacation rental listings, foreclosure listings, and the like. Each category has different data (rentals differ greatly from for sale listings; vacation rentals differ drastically from them all, and so on), but I created only one single `users` table. Then, within the rest of your site, if a person is dealing in vacation rentals, when they login that is noted and they will then be JOIN'ed to the available `vacation_rental` tables. Same of the other categories.

But going back on your initial post: And using your example of a "games website", it's as simple as having a single `users` table with a single column `user_type` where `user_type` can be a number of things, ie. xbox, playstation, wii. Upon login, check the `user_type` and have the system act accordingly. The argument of 3 tables being easier to manage than 1 will not fly with me. Let's up that to 100 user tables vs 1. Would that be easier to manage? What if you have 500 different user types? 5,000? The logic in which you are implementing will not allow for scaling, whatsoever.

As I stated, you're registration and login procedures need to match in terms of how the password is hashed. // register $registerPassword = md5($registerPassword); $query = "INSERT INTO users (firstname, surname, email, password, date_registered) VALUES ('" . $firstname . "', '" . $surname . "', '" . mysql_real_escape_string($registerEmail) . "', '". $registerPassword ."', NOW())"; // login $loginPassword = md5($loginPassword); $query = 'SELECT * FROM users, users1, users2 WHERE email = "' . mysql_real_escape_string($loginEmail) . '" AND password = "' . $loginPassword . '" LIMIT 1'; As for why you cannot login, I'm not sure at this point. Going through your thread regarding the storage of users within multiple tables made me sick to me light-headed. I agree with the consensus in that keeping a single `users` table is the only way to go, so I went off-topic to point out an issue with potential disaster with your usage of md5 and mysql_real_escape_string as it pains me to assist further in a poor database design.

I hope you're not referring to cycling through the table 3 separate times for every one search. Full-text search has Stop Words to handle words like "in" and "the". It also allows for Boolean search.

Consider full-text search. Depending on the size of your table now, or in the future, using wildcards can be terrible on performance. And while full-text searching is not the creme de la creme of table search, it does a better job, hands down.

That was just pseudo code to show how the hash can/will change when using mysql_real_escape_string() before using md5() on the password in question. Of course, if there are no characters to be escaped, then, the hash will go unchanged. I applied the change directly to your code as you can see in my last post. In your table you already have the passwords hashed. You are simply comparing the hash in the table (`password` column) with the incoming form data ($loginPassword) which is why you must first hash $loginPassword to do the compare. MySQL has a built-in MD5() function as you were using, which is fine to use; however, by placing an 'unscrubbed/unsanitized' variable directly into your query leaves you open for malicious behaviour/injection. Which is why, personally, I prefer to hash the password before applying it to the query and removing the MySQL MD5() function so you do not re-hash the already hashed password. Applying mysql_real_escape_string() on any data that is to be hashed is redundant. It adds no extra security, but can, as I displayed, cause some login issues. You must be sure to apply the same measures on all your login scripts, as well as your registration scripts, to ensure integrity. For example, if you keep similar code in your registration code (md5(mysql_real_escape_string($password))), and somebody registers with a quote in their password, then when they try and login at a later date, if you are using the code I provided, their hashes will not match and they will not be able to login.

MD5("' . mysql_real_escape_string($loginPassword) . '") This is no good. If a user enters a quote (single or double), it will be escaped by mysql_real_escape_string(), then hashed. Unless you have this exact code everywhere the user logs in, and also when they register, it will continue to work. What might happen is the following: (note the differences in the hashes) $pass = "fb7s6df9s'fdsa"; echo mysql_real_escape_string($pass) .'<br/>'; // fb7s6df9s\'fdsa echo md5(mysql_real_escape_string($pass)) .'<br/>'; // 38a827e687af1b3bbdaec53c751cf153 echo md5($pass); // 0ec74de5dd867e1fb027d0e73001af53 I would recommend hashing the password before the query: $loginPassword = md5($loginPassword); $query = 'SELECT * FROM users, users1, users2 WHERE email = "' . mysql_real_escape_string($loginEmail) . '" AND password = "' . $loginPassword . '" LIMIT 1'; EDIT: Please note, if you change your code to the above, you might very well need to change your registration code, too, to reflect the same practice. Otherwise, you will lock everybody out who uses quotes in their passwords.

You should already know the answer to that question. Yes.

If 170 is the limit before truncation, then skip the words check and just do a character count: $count = strlen($desc); $max = 170; if ($count > $max) { $desc = substr($desc, 0, $max); $desc .= '......'; } echo $desc;

Because, as @PFMaBiSmAd said, you are creating your query by looping through your $_POST data. What that is doing is creating a `column` update for every form input you have. Note the ", submit='submit'. 'submit' is the name of your button in your form, and not a column in your table. This is the area in which your problems are being generated, and is also a disaster: foreach ($_POST as $key => $val) { if (isset($_POST['form_id'])) unset($_POST['form_id']); { $values .= "{$key} = '" . mysql_real_escape_string(trim($val)) . "', "; } }

25 words does not guarantee there will be 170 characters. strpos is returning false; therefore, $offset is not an acceptable argument for substr().

Typo in my code. Replace: echo ($i < $num_rows) ? ((($i % $col) == 0) ? '</tr><tr>' : '') : ''; with: echo ($i < $num_rows) ? ((($i % $cols) == 0) ? '</tr><tr>' : '') : '';

You are correct. However, I was referring to OP's current usage.

Untested: <?php $fquery = "SELECT state, city, count(city) as num FROM needs WHERE status='posted' GROUP BY state, city ORDER BY state, city"; if ($result = mysql_query($fquery)) { $num_rows = mysql_num_rows($result); echo "<table><tr>"; $i = 1; $cols = 3; while ($frows = mysql_fetch_array($result)) { $fcity = $frows['city']; $fstate = $frows['state']; $fcitycount = $frows['num']; // num is holding your count by city echo "<td><a href='node/browseresults.php?city=$fcity&state=$fstate'>$fcity, $fstate ($fcitycount)</a> $i</td>"; echo ($i < $num_rows) ? ((($i % $col) == 0) ? '</tr><tr>' : '') : ''; $i++; } echo "</tr></table>"; }

Adding additional, useless code to be on the "safe side" is no good. You cannot use more than a single Content-type. You could add 50 Content-type's but only one (the first one) will be used. Does $company_email match the domain name? Or is it a @gmail.com address or something of the like? Try the following: mail($to, $subject, $message, $headers, "-f $company_name");