Psycho

Why would you start with a system designed for a different purpose than the one you need? There are shopping solutions available as well. Start with one of those. It is not as simple as changing an option in the database to change how the application functions. You would have to find all the relevant places in the code to make changes too. A library app is specifically built to have a certain quantity of items that can come and go. A shopping app needs to have an inventory that is reduced as people buy (i.e. check out). but, there will never be a check-in - at least not in the way it would work for a library app. Plus, you will need the ability to add to the inventory and possibly allow back orders, etc. etc. You are only going to find one problem after another. Either find a shopping app that has the right framework to begin with that you can modify or build from scratch.

Are the ratings supposed to be unique for each question? For example, for the items A1, A2, A3, & A4 can a user set three of them to a rank of "1" or should one item be 1, another item 2 and a third item 3?

Well, I am of the opinion that a project that only requires one developer must not be that significant since it doesn't need experts in various roles (UI development, vs core code development, vs DB design, etc.). So, while it may be hoped that this will be used by millions of users, it doesn't seem like it is being funded as such. If it becomes wildly successful, then the company can hire new people with the right skill-sets to rebuild it correctly. If the current implementation isn't going to be fixed, then I would suggest using the UNION work around.

Agreed Jacques1. They are putting the cart before the horse. Only a competent database engineer and appropriate load testing would be able to determine if such an extreme approach is needed. My reasoning for providing the workarounds is that it is not unheard of that those responsible for making decisions don't make the best decisions. E.g. the manager may not have enough technical knowledge and bases the decisions on the developer's opinion or decides that the cost in dollars and time cannot be consumed right now and it isn't work fixing if it "works" right now. So, the OP may be required to find a way to work with what he has been given.

That may be, but have you done load testing to know at what point failures will occur and,just as important, where those failures occur? You may be bottle-necked by your storage infrastructure as opposed to the database. My point was there are some instances where having separate databases makes sense, but trying to fix a problem that hasn't been defined/validated is foolhardy. As to your issue, it is difficult to provide a best approach without really understanding the specific problems to solve. But, I can provide some general ideas that may help. Here is the example of one specific problem you posed You state you plan to have millions of users, yet you want to populate a drop-down of all the users in CA. You may want to rethink that - perhaps a search field. Regardless, a more elegant solution would be to only work against a single database at a time. If the DBs for area1, area2, etc. have more meaningful usage for you, then a solution would be to have a "master" database to list out all of the application databases with meaningful names (San Bernadino County, Central CA, etc.). Then, in your admin utility, select the meaningful name which will then set the DB to use. But, if there is no rhyme or reason to the California "areas" you would be stuck with having to run multiple queries and patching the data together or running a complex (potentially performance impacting) query. You should still probably create a master database that has each of the application databases along with a field for the "group" (i.e. California). Then you can have it programatically query all the relevant databases. You can query the same table from multilple databases in one go using the UNION clause: SELECT * FROM db_CA_Area1.users UNION SELECT * FROM db_CA_Area2.users UNION SELECT * FROM db_CA_Area3.users UNION SELECT * FROM db_CA_Area4.users . . . etc. However, I give no promises that the performance of this with ~10 databases would be acceptable.

I see. I was expecting to see the placeholders as well.

The following are my opinions based on working on a large scale application used to "run the business" for thousands of firms worldwide. I am not a SQL engineer, but in my role I am involved in the discussions/processes regarding the database supporting the application and have some insight into what we have done and why. There are some legitimate reasons for having multiple databases such as scalability and separation of customer data (typically for contractual requirements). But, those decisions (aside from contractual reasons) should only be made after thorough analysis by highly competent SQL engineers to ensure that the DB schema is proper, that there are no inefficient queries, etc. Because, having separate databases creates other challenges. If separate databases are necessary, then there shouldn't be any "co-mingling" of data as you describe in the admin page which required running the same query against all the databases. In our case, the account is determined at login and that is used to "know" what database to use. Our support tools also require the support person to provide the account number for any functions so there is no need to run multiple queries. So, I wouldn't take the developer's word on this. If separate DBs are necessary it should have been something that was legitimately analyzed and should be common knowledge as to why that decision was made. On a separate note: We are looking to move to separate Azure DBs for each account for scalability and greater flexibility. For example, our application requires frequent updates due to the industry and the nature of the application requires several hours to do the updates. With firms that have presence world-wide those outages can be impactful even when we do it in the middle of the night on weekends. By separating the data for each firm, we will have the ability to delay updates for some firms if needed.

Well, when I go to this page which appears to be the main page for the JQuery mask plug-in none of the fields appear to be working (at least for one at the bottom). I tried both Chrome and IE. When did you last see this work somewhere?

You need to give your form fields meaningful names. "checkbox" is not a good name for a form field. One glaring problem is that you have multiple fields with the same name

So, what would you expect to happen when you have two or more concurrent users with the same IP address? But, with what you have, this should work SELECT c.ip_add, SUM(p.product_price * c.qty) as cart_total FROM cart c JOIN product p ON c.p_id = p.product_id WHERE c.ip_add = '$ip'

I did say that code was not tested. I don't have your database or other required files to run that code. I expect you to check for any typos I made and fix them or provide the errors and I can assist. Well, your current query is sorting by p.id. If you want things to be grouped by category then you need to put logic in place to do that. The logic in the code I provided previously would do that. But, even once we get that working, you have another issue. If you want all the categories to be returned with only 10 products per category, you are going to need a somewhat more complex query. Give me some time. If you can provide a dump of the relevant tables, then I could actually test the code I provide.

Another observation. LEFT JOINs are slow, you should not use them unless you know you need them and in this case you don't since yu depend on the data in those joined tables. This should get you the same results more efficiently. $lng = $this->config->config['language']; $query = "SELECT p.id, p.title_{$lng} as Title, p.text_{$lng} as Text, p.price, p.package, p.discount, img.id as FileID, img.ext c.title_{$lng} as CatTitle, b.title_{$lng} as BrandTitle, FROM products as p JOIN products_pictures as img ON(img.object_id = p.id AND p.promo_page = 1 AND p.is_active = 1) JOIN categories as c ON( c.id = p.category_id AND c.is_active = 1) JOIN brands as b ON( p.brand_id = b.id AND b.is_active = 1) WHERE (p.best_price = 1 OR c.best_price = 1 OR b.best_price = 1) ORDER BY p.id LIMIT 10";

Pro tip: Don't mix your PHP code within the HTML. Put your PHP logic at the top of the script and generate the dynamic output into variable. Then output the variables within the HTML. It will make management of your code much, much easier. Ideally yuo will separate the logic (PHP) and presentation (HTML) in different files, but separating them in the same file is a good first step. Pro tip #2: Use comment in your code! It may make sense to you as you write it, but when you have to go back to the code after a few days, weeks, months the comments will save you a ton of time. plus, it makes it much easier when you are asking people for help with your code If you are ONLY going to output records from one category, you can just have a flag/counter to determine the first record being processed and only output the category on the first record. But, I would recommend building the functionality to be more flexible. For example, what if you want to show the output for multiple categories and only show the category header at the start of each section. This ensure you do not program yourself into a corner. But, your query doesn't have any condition to limit by one category. So, I'm not sure if you only want one category in the results (in which case there should be a WHERE condition) or if you want the output to contain all categories with only 10 products each. There are different approaches. Typically you can just "test" the category value to see if it is the same as the previous value. If it is different, output the category. If it is the same as the last record, do not output the category. But, since you need to wrap the multiple products for the category within a div, an easier approach is to pre-process the query results into a multi-dimensional array - then use that array to create the output. FYI: I can think of no legitimate reason why you should be using strip_slashes() in your code. If you "need" it,it is because of some other problem that you should resolve. The following would work for output for multiple categories. Not tested <?php $this->view("common/header"); //Run query to get results $query = "SELECT p.id, p.title_".$this->config->config['language']." as Title, p.text_".$this->config->config['language']." as Text, c.title_".$this->config->config['language']." as CatTitle, b.title_".$this->config->config['language']." as BrandTitle, p.price, p.package, p.discount, img.id as FileID, img.ext FROM products as p LEFT JOIN products_pictures as img ON(img.object_id = p.id ) LEFT JOIN categories as c ON( c.id = p.category_id ) LEFT JOIN brands as b ON( p.brand_id = b.id) WHERE (p.best_price = 1 OR c.best_price = 1 OR b.best_price = 1) AND p.promo_page = 1 AND p.is_active = 1 AND b.is_active = 1 AND c.is_active = 1 ORDER BY p.id LIMIT 10"; $result = $this->db->query($query); //Loop over result set and put into structured array $resultsAry = array(); foreach($result->result() as $row) { $resultsAry[stripslashes($row->CatTitle)] = $row; } //Store current site url in variable (no need to call it multiple times) $siteUrl = site_url(); //Define the valid image formats (do not do in loop) $img_formats = array('jpg', 'jpeg', 'png', 'gif'); //Create variable to store the output $outputHtml = ''; //Iterate over results to create html output foreach($resultsAry as $category => $products) { //Start new category section $outputHtml .= "<div class="prod-sec">\n"; $outputHtml .= " <div class="prod-head">\n"; $outputHtml .= " <h2>{$title_cat}</h2>\n"; $outputHtml .= " </div>\n"; //Create output for each product foreach($products as $product) { //Determine the image source if(in_array($row->ext, $img_formats)) { $img_src = "{$siteUrl}files/products/{$row->id}/{$row->FileID}_1.{$row->ext}"; } elseif($row->ext=="flv") { $img_src = "{$siteUrl}images/video.png"; } else { $img_src = "{$siteUrl}files/default.jpg"; } //Determine other needed values $title = character_limiter(stripslashes($row->Title), 55); $title_url = getLinkTitle($title); $link = "{$siteUrl}products/product/{$row->id}/{$title_url}"; $price = product_price($row, array('show_discount' => false, 'show_label' => false)); //Create the product html output $outputHtml .= " <div class='gall-products'>\n"; $outputHtml .= " <div>\n"; $outputHtml .= " <h2 itemprop='name'><a target='_blank' itemprop='url' href='{$link}' title='{$title}' rel='overdiv_hidden_1_{$row->id}'>{$title}</a></h2>\n"; $outputHtml .= " </div>\n"; $outputHtml .= " <div class='gall-img'>\n"; $outputHtml .= " <a target='_blank' href='{$link}' title='{$title}' rel='overdiv_hidden_1_{$row->id}'><img itemprop='image' src='{$img_src}' alt='Съдържание » Цена » Прием » {$title}' title='{$title}' width='100%' /></a>\n"; $outputHtml .= " </div>\n"; $outputHtml .= " <div class='price'>{$price}</div>\n"; $outputHtml .= " <div class='view-product'>\n"; $outputHtml .= " <div><a href='javascript:to_basket({$row->id});' class='btn-cart'>Добави в количка</a></div>\n"; $outputHtml .= " <div><button class='backcolr' onclick='parent.location='{$link}';'>Разгледай</button></div>\n"; $outputHtml .= " №:<span itemprop='productID'>{$row->id}</span>\n"; $outputHtml .= " </div>\n"; $outputHtml .= " </div>\n"; } //Close category section $outputHtml .= "</div>\n"; } ?> <link rel="canonical" href="<?=$siteUrl?>" /> <!-- <link rel="stylesheet" href="/css/bx_styles/bx_styles.css" type="text/css" /> --> <!-- <script type="text/javascript" src="/js/jquery.bxSlider.js"></script> --> <!-- <script type="text/javascript" src="/js/jquery.bxslider.min.js"></script> --> <div class="inner"> <div class="inner shadow"> <?=$outputHtml?> </div> <div class="clear"></div> <?php $this->view("common/footer"); ?>

I think your current schema has problems. For example every owner can be also a breeder, if I breed a dog and you buy it there are two rows in owner If a "person" can have multiple "entity" types you should not create multiple records like that. Instead you should have one record for each "person" and then have separate tables for the data associated with those different entities. For example, you could have a person table (or whatever you want to name it) with an id, name, etc. that applies to all owners and breeders. Then, if you need additional data for people that are breeders, have a breeder table with the personID, kennel name, etc. I assume you can determine owners based on the fact that there are dogs and/or puppies associated. Also, you didn't really answer my questions. Based on these statements There is no reason why you are selecting data from the JOINed tables. I specifically asked that because your current design will necessarily return duplicative records which would make using the data difficult. When you retrieve the list of owners that meet the two conditions above, what additional data do you need from the associated tables?

Have you tried displaying BOTH the original image and the resized images? My guess is that the original image will display with the correct orientation, but the resized image will not because the original image has the required EXIF data that the browser is applying while the resized image does not. The user manual for imagecreatefromjpeg() has the following user contributed note: Even though an image displays correctly on the iPhone does not mean it is really saved that way. The camera has a specific orientation and I suspect all images are saved with that default orientation. All the rotation implementation is likely just software based. For a PHP application, I would not rely upon EXIF information to determine how an image is displayed. I would instead convert the image (as the example with that note would do) so it does not depend on rotation. The reason is if you need to do any logic on the size of the image it would be more complicated. For example, if you will create the output differently based on the width of an image you would have to first check the EXIF data to determine if you should check the "width" or the "height" of the image based on what is the real width when displayed Since you already have a process to resize the original image go ahead and rotate the new image accordingly. If you also save the original image, then you should replace it with one that is not rotated as well.

OK, I'm not completely following your description, so let me ask a few questions: 1. First, provide a layman's description of what you want to report on. Your last response has some of that, but not all of it.: I think you want something along the lines of "I want a list of owners that meet the following conditions along with any associated puppies that meet these conditions". 2. I still see a problem with how the dog and puppy tables are being used. If there are multiple corresponding records in the dog table and the puppy table, you will get duplicate data. E.g. if on owner has 3 matching records in the dog table and 5 matching records in the puppy table - there will be 15 records (3 x 5) returned in the query. I'm curious why the puppies are not joined on the dogs. If there is a relations ship between dogs and puppies - it would make more sense with what you are doing currently. If not (puppies and dogs are separate entities) then, as I stated before, you probably want to do a sub-query using those two tables with a UNION 3. The original query was getting a lot of duplicate data (e.g. the owner id was getting returned in four(!) different fields - one for each table. It will be the same value in all four fields, so just pull the one from the owner table. When dealing with complex queries, I suggest starting with a query from just the first table to get that data. Then add additional tables one at a time with appropriate conditions/filters with the additional data from those tables that you need. Validate the results at each step before going on.

I agree with Barand regarding the LEFT JOINs. Unless you need records from the owner table that have no associated records from the other tables, just a normal JOIN will work. Looking a little closer, I'm not sure you need these TWO joins with the additional WHERE conditions LEFT JOIN dog d ON d.owner_id = owner.id LEFT JOIN dog h ON h.breeder_id = owner.id WHERE ( d.date_of_birth >= DATE_SUB(CURDATE(), INTERVAL 8 YEAR) AND d.breeding_approval_since !='0000' AND owner.kennelname !='' AND owner.kennel_note ='' AND owner.country_short='de' ) or ( h.date_of_birth >= DATE_SUB(CURDATE(), INTERVAL 8 YEAR) AND owner.kennelname !='' AND owner.kennel_note ='' AND h.breeder_id = owner.id AND owner.country_short='de' ) Instead you could do just one JOIN on that table using the two join conditions. Then, looking at the two sets of WHERE conditions there are only some minor differences 1. AND d.breeding_approval_since !='0000' So, you only care about the approval_since IF the record is joined on the owner_id 2. AND h.breeder_id = owner.id That is a duplicate of the condition used to perform the JOIN and is superfluous. This should work a little better (not tested) SELECT o.id, o.kennelname, o.country, o.country_short, o.kennel_note, d.id AS dogid, d.breeder_id, d.date_of_birth, d.gender, d.owner_id, d.breeder_id, d.breeding_approval_since, MAX(YEAR(d.date_of_birth)) AS lastlitter, p.breeder_id, MAX(p.sollgeboren) AS birthday, DATE_ADD(MAX(p.sollgeboren), INTERVAL 84 DAY) AS database_dateadd, DATE_SUB(MAX(p.sollgeboren), INTERVAL 60 DAY) AS database_datesub, p.active AS showing FROM owner o LEFT JOIN dog d ON d.owner_id = o.id OR (d.breeder_id = o.id AND d.breeding_approval_since !='0000') LEFT JOIN puppy ON (o.id = p.breeder_id AND p.active='1') WHERE d.date_of_birth >= DATE_SUB(CURDATE(), INTERVAL 8 YEAR) AND o.kennelname !='' AND o.kennel_note ='' AND o.country_short='de' GROUP BY o.country_short, o.kennelname ORDER BY o.kennelname ASC But, I'm not sure why you have the join from the dog table and the puppy table. If there are three records in the dog table to join on an owner and three records in the puppy table to join on the same owner record - you will end up with a total of nine records returned for that owner: 3 x 3 = 9. All three puppy records are joined on all three dog records. I can't imagine that this is correct since it would return a lot of duplicative data. Without knowing what you are really needing, it's hard to give any advise. Perhaps you need to do a subquery of the dog and puppy tables using a UNION and then joining that result on the owner table.

But, it didn't include the "secret sauce" that made mine work for what you needed. If you need additional data returned, I would start with the one I provided. however, if what you need is substantially different than what you asked, I'm not sure what to tell you. I already took my own time to review the data independently and devise a solution - albeit a hack due to the structure of the data. So, if what you really need will require a rewrite I doubt I will be able to help.

I'm not sure what that last query is that you provided. It certainly isn't the one I provided. SELECT i.id as incident, i.title, i.date_ocurred, w.id as wid, w.field_id, w.type, CONVERT(COALESCE(v_boolean,v_integer,v_float,v_string,v_text,''), CHAR(50)) as value FROM incidents i JOIN ( SELECT object_id, MAX(id)-2 as filter_id FROM wf_data WHERE type = 4 GROUP BY object_id ) filter ON i.id = filter.object_id JOIN wf_data w ON w.object_id = i.id AND w.id >= filter.filter_id WHERE w.type IN (4, 5) ORDER BY i.id, w.field_id; When analyzing the raw data. it appeared to me that the three records associated with an incident ID that you needed always had the type of 5, 4, 4. Further, I saw that some incidents had multiple instances of three records with those types. So, my approach was to find the last three records (sorted by field_id) with the type 5 or 4. The "filter" is a dynamic table which will return the MAX(id)-2 from the wf_data table for each unique object_id (i.e. incident id). Then using that dynamic data, I query the incidents table and the wf_data table only selecting the data from the wf_data table that are of the type 4 or 5 AND where the wf_data.id is greater than or equal to the filter id value from the sub-query.

Did you look at the results returned by the query I provided? I'm pretty sure it works even if the form is reset.

If I am understanding you and the data correctly, this should work. It is a hack, but I don't see a really elegant solution with what you have to work with. SELECT i.id as incident, i.title, i.date_ocurred, w.id as wid, w.field_id, w.type, CONVERT(COALESCE(v_boolean,v_integer,v_float,v_string,v_text,''), CHAR(50)) as value FROM incidents i JOIN ( SELECT object_id, MAX(id)-2 as filter_id FROM wf_data WHERE type = 4 GROUP BY object_id ) filter ON i.id = filter.object_id JOIN wf_data w ON w.object_id = i.id AND w.id >= filter.filter_id WHERE w.type IN (4, 5) ORDER BY i.id, w.field_id; This will return three records for each incident as follows: incide|title |date_ocurre|wid |field_|typ|value 206|Root Cause Analysis | 1481719620|1603| 2665| 5|<p>Warehouse internet circuit down</p> 206|Root Cause Analysis | 1481719620|1604| 2666| 4|umm 206|Root Cause Analysis | 1481719620|1605| 2667| 4|resolved 231|Lacey warehouse primary circuits down - Tit| 1482241980|1675| 2665| 5|<p>Lacey warehouse primary circuits down</p> 231|Lacey warehouse primary circuits down - Tit| 1482241980|1676| 2666| 4|SBM/SSM entry 231|Lacey warehouse primary circuits down - Tit| 1482241980|1677| 2667| 4|RCA Status Entry 232|Testing RCA Workflow | 1482245760|1693| 2673| 5|<p>Testing RCA workflow - this is updated</p> 232|Testing RCA Workflow | 1482245760|1694| 2674| 4|I dont know SBM/SSM - still dont know 232|Testing RCA Workflow | 1482245760|1695| 2675| 4|Resolved 233|Root Cause Analysis | 1482252180|1700| 2695| 5|<p>new RCA</p> 233|Root Cause Analysis | 1482252180|1701| 2696| 4|SSM 233|Root Cause Analysis | 1482252180|1702| 2697| 4|Confirmed 234|Root Cause Analysis | 1482323640|1709| 2695| 5|<p>test description</p> 234|Root Cause Analysis | 1482323640|1710| 2696| 4|test ssm 234|Root Cause Analysis | 1482323640|1711| 2697| 4|test status 259|This is the title | 1483468620|1718| 2695| 5|<p>this is a description</p> 259|This is the title | 1483468620|1719| 2696| 4|ssm 259|This is the title | 1483468620|1720| 2697| 4|status The value of the first record is the description, the second is the SSM, and the third is the status. you can then handle those in the code like this (not tested): $data = array(); while ($row = mysqli_fetch_array($result, MYSQLI_BOTH)) { if(!isset($data[$row['incident']])) { $data[$row[incident]] = array( 'title' = $row['title'], 'date' = $row['date_ocurred'], 'description' = $row['value']); } elseif(!isset($data[$row['incident']['ssm']])) { $data[$row[incident]]['ssm'] = $row['value']); } else { $data[$row[incident]]['status'] = $row['value']); } } That should create an array in this format array( '206' => array ( 'title' => 'Root Cause Analysis', 'date' => '1481719620', 'description' => '<p>Warehouse internet circuit down</p>', 'ssm' => 'umm', 'status' => 'resolved', ), '231' => array ( 'title' => 'Lacey warehouse primary circuits down - Title', 'date' => '1482241980', 'description' => '<p>Lacey warehouse primary circuits down</p>', 'ssm' => 'SBM/SSM entry', 'status' => 'RCA Status Entry', ) . . . etc. )

I suspect there are more places than just this that may need to be edited, but the following should "fix" that bit of code above. However, I would add a much better validation to ensure a proper URL was submitted function ParseURL($url) { //Trim the value $url = trim($url); //if (strpos($url, '.')<1) { return false; } // check if empty/too short if (strlen($url)<3) { return false; } //Test is string begins with "http://" OR "https://" if (strncasecmp($url, "http://", 7)!==0 && strncasecmp($url, "https://", !==0) { //If neither protocol found, use default $url = "http://" . $url; } $url_stuff = parse_url($url); if (!isset($url_stuff["path"])) { $url = $url . "/"; } return $url; }

Well, it depends. If you can come up with specific rules on how the tables should be processed, then yes. These types of problems should first be analyzed without any thought to how it would be coded. Start by trying to create instructions on how you would explain to person to process the data. If you can do that - THEN proceed to writing code to adhere to those instructions. Looking at the example above, I can *guess* at some possible rules. For example, the first table row (TR) contains the name of the table. Or, does that only apply when there is only one TD in the row? The second row contains the headers for the table. Rows three to the end contain the data associated with those headers. If those are accurate rules, then it is a simple task to read the data and correlate the data to the header names. I could write some sample code, but I;m not going to do that based on a guess of what the rules should be. Now, assuming you can define the rules for getting the data - storing it in the database is another matter. Since the HTML tables are different lengths and have different fields I have no way of knowing how it should be stored. I would have to have some idea on how the data is to be used in order to make an intelligent decision. Do the tables of data have any relationship to one another?

There could be a couple causes for you receiving blank emails: 1. There is a logic problem that legitimate user activity is calling the action to send the email. E.g. the script is run on page load without checking that the form was submitted, duplicate code hiding somewhere that you are not aware, etc. 2. A bot is making the action to submit the request causing the empty emails. There are several solutions needed. I will cover some of them. 1. Do NOT implement JavaScript as a validation technique. I'm not even going to try to understand that garbled mess. A user with JavaScript disabled or a bot will not invoke the JavaScript, so that validation is useless in those scenarios. It's fine to put some client-side validation in to enhance the user experience (i.e. give the user an error for a required field w/o having to submit the form), but you must absolutely have validation for all business logic on the server-side. I would first enclose the logic in a condition to ensure the form was submitted. You are currenlty using $_GET, but $_POST is more appropriate (and could also be the root of your problem, see below). if($_SERVER['REQUEST_METHOD'] !="POST") { //Form not posted, do something - e.g. error condition } else { //Form was posted, continue validation } Then you should have validation that any required fields have values and that any values received are "correct". E.g. if one field is a select list, ensure the received value is in the list of valid values. If an email is required, make sure it is validly configured. 2. Don't use $_GET. When a user submits a form using the GET method it puts all that data into the URL and redirects them to the action parameter. If a user was to refresh the page or bookmark it, it will continue to process the "submission". A POST will resubmit on a page refresh, but you can avoid that much easier by using a header() call at the end of the processing to a different page (e.g. "Thank you for your submission"). Or, even better, implement a PRG process (google for more info). 3. The above two suggestions should solve your problem since the submissions are apparently empty and server-side validation should be written to prevent the email if there is no valid data. But, if you have a problem where a bot is continually submitting a form with valid data, then you would have to implement some sort of "bot check" such as a CAPTCHA image where the user has to enter the characters in the image or the checkbox stating "I am not a bot" (NOte, it is not a normal checkbox, but there are pre-built solutions out there. But, I don't think you have to worry about #3 at this time. Start by switching to $_POST and ensure it still works. Then move on to implementing server-side validation logic to prevent the email if there are errors/invalid data/no data. EDIT: OK, I see now that you have both $_POST & $_GET variables in your code. Not sure why. Are you expecting data to come in from either/or method? the logic is kind of "hokey". Plus, you should never use something like this: while (list($key,$val)=each($_POST)) It is a trivial thing for a user to pass any name/value pairs they wish to your page. If you had a hard-coded variable that determines a folder path, logic like that could cause your system to be compromised. Your specific usage doesn't appear to have a security problem, but it is a bad practice.

Adding additional logic to existing triggers is a pretty simple process. You could add the logic in the current function that is called or create an additional function. However, you have provided no code as to what is currently occurring. So, it's kind of hard to provide any suggestions. We'd need to see how the onchange trigger is implemented (in line, onload, etc.) and what is currently getting passed. For example, if the function that is called has the "value" of the clicked option, then you could simply call another function from within that one to do the additional work //Existing function function registrationPrice(registrationType) { //Call new function to show appropriate fields showField(registrationType); //... rest of code for registration price } //new function function showFields(registrationType) { switch(registrationType) { case 1: //Show hide relevant fields break; case 2: //Show hide relevant fields break; case 3: //Show hide relevant fields break; default: //Fail-safe condition. Hide all fields break; } } However, you may have a bigger issue based on the above. Any price calculation on the client side should be strictly cosmetic and not used to send to the server. Any important calculations should always be calculated on the server based on the parameters that are received by the user. It is a trivial task for a user to change any values submitted by a form whether they are select lists, hidden fields, etc. So, it is fine to have client-side logic to provide the user additional information and usability, but never rely upon JavaScript to enforce business logic. E.g. If option B is disabled when option A is selected. A user could very easily pass a form with both options selected. Even though it is a good idea to disable options based on other input from a usability stand point, the server-side logic should check for ALL error conditions and reject invalid data (with appropriate messaging to the user).