Psycho

You are not getting an error - you are getting a "Notice". In a production environment (i.e. live site you would have error reporting set such that notices are not displayed.. But, in a development environment you want error reporting set to ALL. In this specific instance your condition statement is trying to reference an array value where no such index exists (i.e. it is not defined) if ($row_rsCoffee['image'] == "") So the array $row_rsCoffee does exists, but there is no value defined for the index 'image'. The notices are there to let you know that you may have made a mistake (e.g. used the wrong index name). If error reporting was set to not report notices, that condition would try to compare a nonexistent variable to a null string. Using the loose comparison operator that would result in true. Assuming that is the outcome you want, it would work, but it is sloppy IMO. You would want to use isset() but not like floridaflatlander suggested. Assuming you want the condition to be true if the variable is not set OR if the variable is set and an empty string, I would use this if (!isset($row_rsCoffee['image']) || $row_rsCoffee['image'] == "")

Well, it is entirely up to you as to what is acceptable and what is not. Since you posted this question we attempted to help you with what you are trying to do. But, I'll give you my opinion on this subject. When accepting user input I think it is generally a bad idea to ever modify the user input without their knowledge. There are some minor exceptions such as when the user enters a data - as long as I can interpret the value of the date I'm not concerned with the format. But, you should make a conscious decision as to what is not allowed for a particular input. If the input contains anything that is not allowed I believe you should reject the input instead of modifying it. In your current process someone might enter some text that has meaning to what they entered but which would be stripped out. I have sometime put faux <sarcasm> tags around text in a post to give context to the text. If that was removed it could be interpreted incorrectly. So, my advice is that if you do not want tags in the input simply reject the post and make the suer reject it. But, there is no reason you can't accept the post. Because if you run the text through htmlspecialchars() it will be safe to display in the page. Lastly, I would advise you store the input in its original format and use any modifications when outputting the content. Otherwise, it can be come difficult to add any functions for modifying the content or to output it for different uses.

Sanitizing input for the purpose of saving in the database does not make that content "safe" to display in a web page. That code is only escaping the content for the purposes of the "stikiness" of your form. That has no bearing on how you might use the saved value in other places (as you proposed above). As kicken already stated, (you know, I use the phrase "as already stated" a LOT with you) if the data came from the user you need to treat it as "untrusted" and always escape it based upon the method you are using it. This include in DB queries, HTML output, etc. Even if you were outputting content to a CSV file you need to properly escape it so that a rogue comma in the data doesn't corrupt the file. I'll also add that even if you are, currently, restricting usernames to certain characters that wouldn't cause a problem being output to HTML, it is still a good practice to escape it anyway. If you were to decide later that you were too restrictive in your rules for usernames you wouldn't want to hunt through your code to find all the places that it is used in output.

There are many simple debugging processes that will help you verify/find the errors quite easily. In this situation you know a record was returned. You could have simply done a print_r($row) to verify all the data that was contained in the array.

The problem has nothing to do with the query. If the field did not exist the query would fail. Here is your problem echo '<b>' .$row['$username']. ':</b> '.$row['post'].'<br />At: '.$row['post_date'].'<br /><br />'; Look at the index name that you are using to reference the value ==> $row['$username'] I have no idea what the value of the $username VARIABLE is, but I doubt it is the STRING 'username'. Try echo "<b>{$row['username']}:</b> {$row['post']}<br />At: {$row['post_date']}<br /><br />";

Where is the code in question that is causing this error. The only thing that jumps out at me is that there may be some paths that are dynamically set based upon data from the client PC that would cause the path to be different on your home PC vs. the work PCs. Also, I assume you are running the page on a server that is not on your home network.

Are you sure that mammoth function is really worthwhile? I would think just using strip_tags() and htmlspecialchars() would be enough. It would leave any JS code that was between the opening/closing tags and perhaps some other content you are currently stripping. But, that content would be rendered safe. Besides, someone trying to inject JavaScript in a submission is probably not submitting a legitimate post anyways. So, if that code is displayed that was their fault anyways. Just seems like a lot of work for not much value. Especially since the more complex the code the more likely there is a bug you are not aware of.

Well, think about it for a moment. Why would it be a good practice to copy data for the same records into multiple tables and then have to try and keep them in sync. As I stated above there are plenty of tutorials out there about database design that would do a much better job explaining than I could in a forum post. But, I'll try and provide a generalized example. So, let's say you are using a Word Press framework and you want to add some functionality that requires you to capture more data about users. You can wither add those fields to the existing table or you can create a new table with ONLY the new fields as well as a foreign key for the record in the original table. So, I would suggest you try and add the new columns to the existing table to see if it breaks any functionality in WP. If built correctly it shouldn't create any problems. But, if you do see any problems then simply delete those fields and create a new table with a field for a reference to the ID from the original table and ONLY the new fields. Ok, so let's say you need to create the new table (we'll call is "user2") and you want to capture data for "banned", "rank" and "sig". The table should have those three fields and a field called "user_id" which will hold the "id" value from the existing "usersgnet". Then, when you let the user enter their information for "banned", "rank" and "sig" you would simply add a record to the new table with those value and the user's id. All the WP functionality will still use the original table as it currently does. Now, you can use both that WP table and your new table for the new functionality you want to build. Let's say you need some data from the original table and the new table. You simply need to use a JOIN. Example SELECT name, user_email, banned, rank FROM usersgnet JOIN user2 ON usersgnet.id = user2.user_id The above query would get the data specified for all users from the two tables. That is just a rough example. Plus, as I was stating before you should also not be doing these queries using the "name" of the user. You should be using the ID. The only time you would normally be using a "name" as part of the WHERE clause is if you were doing a search. I could, but mark it solved yourself. I'm not your bitch.

Not to be rude, but no. If you already have a table that has user info and you want to extend the data you want to collect for users you should either expand the existing table OR, if you can't do that, you create another table with ONLY the new information. If you do create a new table you can associate the data between the two tables using a JOIN in your query. If you want CONSISTENT data the absolute worst thing to do would be to copy data into two tables. I really can't explain all the ins and outs about database design and how you do JOINs but there are tons of tutorials out there.

Your database structure is flawed. You should not be storing the same data for records in different tables. I see some of the exact same data in the two tables. I think you may need to do some research on how to properly create a database (see database normalization). This is not a trivial task, but one you need to understand. I am not going to even attempt to provide code to work with what you have as it needs a complete overhaul.

Not really understanding your request. If it is updated by the server, then the server is doing the work. The solution is to simply make your calls as efficient as possible. There are a few things you can do to that end. Let's assume that the user is on a specific auction page for an item and you want to update the current status of the auction for that item to the user in as near real-time as possible. First of all, you can never guarantee that a call to the server will complete within 1 second. So, you should make the AJAX call synchronous - i.e. let one call complete before another is called. Otherwise, if there is is a delay in the user's internet connection or a server lag it could cause all the requests to pile up. Second, you should send/retrieve only the minimal information needed. For an auction page the AJAX request should only need the auction ID (however, I'll discuss another parameter later). The return value should only need to return a "false" value if there were no changes or, if there were changes, just the minimal information of what changed (new bid, current high bidder). Plus, do not format large section of HTML on the server and return it to be updated. Instead, just return the necessary values (or only do minimal formatting) and use the JavaScript to update the content on the page. Third, use a timestamp to prevent unnecessary processing. The first time the page is loaded (or the AJAX call is made) generate a timestamp on the server and include it in the response. The AJAX call will include the timestamp on every subsequent call to the server. In the server logic you would use that timestamp when querying the data for the status of the item using something such as SELECT bid_price, bid_user FROM auctions WHERE auction_id = $id AND last_updated > $timestamp So, if the status of that auction item has not changed you will get no results and you can simply return a false to the AJAX call. This cuts down on the processing that would be needed when there have been no changes. Those are just a few ideas off the top of my head.

The "No match found" has nothing to do with the "banned" field. That response means there is no record in the table that matches the WHERE clause WHERE name = '$userword' Echo the query to the page and verify that the value of $userword is what you expect. If so, check the actual database to verify there is a matching record (which there isn't - thus the error).

OR mysql_result() which is my preference when getting a single value from a single record. Also, I would advise not building your queries inside the mysql_query() function - it's easier to debug query errors when you can echo the query to the page. $query = "SELECT banned FROM usersgnet WHERE name = '$userword'"; $result = mysql_query($query) or die(mysql_error()); if(!mysql_num_rows($result)) { echo "No match found."; } else { $banned_status = (mysql_result($result, 0)=='1') ? 'BANNED' : 'NOT BANNED'; echo $banned_status; }

That depends completely on the specific requirements of the specific data field you are working with. Generally, IMO, it is a bad idea to ever change a users data. If you are referring to a persons "real" name, there are people with legitimate names that have capital letters within them and some that don't have a capital as the first letter. If you do not want to allow users to submit values if the first character is not an uppercase letter you can reject the input and force them to make the correction. In addition, you can make the correction for them in the input field, but make them submit the change. But, if you have a field that would not be "changed" by modifying the case of the letters then you could either change the case when saving to the database or do it on-the-fly when presenting the data. The decision would likely be based upon whether you would EVER need the input in its original format. An example of this might be an email address. It would not change the meaning/usage of an email address if you wanted to set them all to lowercase letter. If that was a requirement of the application, I'd set them to lowercase when saving. Again, there is no ONE answer. This thread is pointless in the fact that it can only be answered by the person responsible for the application. It all depends on the context of the values you are working with and the specific requirements of the application. However, based upon what characters will be supported there are other considerations (e.g. escaping characters based upon the output). But, if you are following good programming practices, you should do this on ALL data regardless of whether it can contain certain characters or not. Obnoxious to who? If YOU don't like it, restrict it. That's your choice. Some sites restrict such characters and others do not. For example, this site allows many, if not all, special characters. It even allows, gasp, PHP code as a username such as: <?=$humour?>

Rule #12: This forum is for people wanting help with code they have written. Please show what you have tried and state what problems you have encountered.

After some further thought, you should completely redo this process. I assume you already have a process for adding items to your cart. You do not need a completely new process for editing quantities. Instead, create ONE process that will add or update quantities. It makes you code much more clean. //This process will ADD or UPDATE an item in the cart $update = false; foreach ($_SESSION['cart_array'] as &$item) //<==make $item a reference { //Check if item already exists in cart if(isset($item['item_id']) && $item['item_id']==$item_to_adjust) { //Item already in cart, update quantity $item['quantity'] = $quantity; $update = true; break; //Exit loop since we already found the match } } // close foreach loop if(!$update) { $_SESSION['cart_array'][] = array('item_id' => $item_to_adjust, 'quantity' => $quantity); } However, if you were to modify the cart array like I suggest above, this becomes a much, much easier process - just one line $_SESSION['cart_array'][$item_to_adjust]['quantity'] = $quantity; If the item is already in the cart it gets updated, if not it gets added!

OK, looking a bit more at your code, you are making this way more complicated than it needs to be. 1. Instead of all those lines to validate the quantity value, you can use the min() and max() functions to do the same thing with one line. Replace this $quantity = $_POST['quantity']; $quantity = preg_replace('#[^0-9]#i', '', $quantity); // filter everything but numbers if ($quantity >= 100) { $quantity = 99; } if ($quantity < 1) { $quantity = 1; } if ($quantity == "") { $quantity = 1; } With this $quantity = min(max($_POST['quantity'], 1), 99); //Ensure qty is between 1 and 99 2. I think your array structure for the cart_array is inefficient. I think it looks something like this 0 => array ('item_id' => 2, 'quantity'=>5), 1 => array ('item_id' => 5, 'quantity'=>10), 2 => array ('item_id' => 19, 'quantity'=>3) Instead of including the item_id as part of the sub-array the item_id should be the index and the quantity the value 2 => 5, 5 => 10, 19 => 3 Even with what you have the while() loop is completely unnecessary to find the 'item_id' element. Each record in the array should have one element by that name, so just reference it. I would post some code, but I really need to see an example of your current array (although I would personally use a different structure)/

I think it would help if you show an example of the values you might expect for the input data. The condition you provided would never be true. Here is your original condition but but with some emphasis added to a few 'key' parts (pun intended) If you take the $value variable out of that condition you are left with $key can never be equal to "item_id" AND also be equal to ("custom_txt" OR "img")

There is no problem with using PHP to dynamically set ANY values in the HTML code - even the href for the style sheet. So, not sure what your problem is, but you don't need to set the value that way. As you found, when using "template/css/skySpirit.css" it will not find the style sheet with opening pages in sub folders. There is a very simple solution. Just put a slash at the beginning of the path and that will search from the root of the site rather than the root fo the current page location. <link rel="stylesheet" type="text/css" href="/template/css/skySpirit.css" />

Well, you wouldn't have a table with only one field. You would want to provide *something* to identify the round - even if it is only the timestamp of when the round was created. As for your second table it would likely need to be separated out into other tables. You state the fields would be something like this: nr, name, points, games played, wins, losses, etc. and the foreign key (FK) round_id But, if you have people (i.e. the names) that would be associated with different rounds you would want a separate table to store the people and their name. Then use a foreign key (FK) to associates the rounds with the people. And, you would probably have separate tables for the rounds and the games. I am not going to create your DB structure for you, but I'll give an example. I would have to go through all the requirements of your application to really provide the correct approach and that's beyond the time I can invest. Again, you need to do some reading on teh subject of database normalization. Anyway, here goes (PK = primary key, FK = foreign key): Table: Users Fields user_id (PK), name Table: rounds Fields: round_id (PK), round_description Tables: Games Fields: game_id (PK), round_id (FK), player_1 (FK), player_2 (FK), player_1_score, player_2_score, winner_id (FK) I would actually consider breaking out the player details from the Games table.

Your problem is that you are getting the extension by explod()ing on the period. That means the period will not be part of the value, but all your validation values include periods. But the approach is overly-complicated and has another flaw. When comparing strings they will be compared on a case-sensitive manner. So, 'jpg' != 'JPG'. Plus, you don't need to make it so complicated. Simply make an array of acceptable extensions and do an in_array() check.

The answer to your question is yes, you can allow the user to select different databases and tables. But, that is NOT what you should be doing. You should not create new tables or databases for different rounds or seasons. Your tables should be built based on the logical associations of data. For example, lets say you need to store the results of a match and each match is associated with a tournament. Then you would want one table for the tournament info and another for the match info. In the tournament table you would have a record for each tournament and each record would have a unique "primary" key. Then in the matches table each match record would include a field to store the value of the tournament id (this would be referred to as as a foreign key reference because it is a key that refers to another table). You can then store all your matches in the same table but each record can be associated with different tournaments. I suggest you do a little reading on designing a relational database before you try and build the wrong solution.

This topic has been moved to Other. http://www.phpfreaks.com/forums/index.php?topic=354424.0

Regarding "best practices" you should not be echo'ing content within functions/methods. They should "return" content to where they were called and echo'd there. I would also suggest that you use a class instead of defining the style attributes in the links. It will make your code a lot simpler. But, I don't see the problem. You have a for() loop where $n runs from 1 to $pageCnt. The output shows three links that go from 1 to 3. You do have a link that precedes those, but it must have been generated outside this method since it isn't preceded with a "|" Also, the way the code is built is really illogical. Making the $stylePg variable contain the style, closing of the A tag and the label of the tag is confusing. Anyway, it looks like you are creating pagination links and that you are trying to pass the value to be used in the LIMIT clause. That's not how it's done. Simply pass a page number and calculate the LIMIT start value in the code that generates the page.

This topic has been moved to MySQL Help. http://www.phpfreaks.com/forums/index.php?topic=354422.0