mac_gyver

to get php to show fatal parse errors in your main file, you must set the error_reporting and display_errors settings in the php.ini on your development system. you would find the php.ini that php is using (see the Loaded Configuration File value in the output from a phpinfo() statement), then find and change the error_reporting and display_errors lines in it, to be error_reporting = E_ALL and display_errors = On stop and start your web server to get any changes made to the master php.ini to take effect. once you put these settings in the php.ini, you don't need to put them into your .php files.

only checked check-boxes are submitted and you have no relationship between the check-box and the text input field holding the updated date. you can see this is you examine the submitted post data. add the following debugging line of code to see what is actually being submitted - echo '<pre>',print_r($_POST,true),'</pre>'; your database table should have an autoincrement id (identifier) column. i recommend that you use the id as the form field array index for both the check-box and the text input field. this will serve to tie the check-box to it's corresponding text input field.

if the html of the form is actually present (have you checked the 'view source' of the page in the browser type where it doesn't work), browser problems like this are usually due to invalid markup/css that some browsers ignore the problems in, but other's don't. your page has 70 makeup errors and 67 warnings - http://validator.w3.org/check?uri=compareandchoose.com.au%2Fhome_loans&charset=%28detect+automatically%29&doctype=Inline&group=0 most of the errors are because the html comments are broken, which means that some browsers will see part of the html as being part of the comment. if you are dynamically producing these pages, why do you even have html comments in it? you should have php comments in the php code.

similar to my reply in your other thread, if you are at the point of trying to make an installer script, you should be dynamically producing any form and dynamically processing the form data, rather than writing out the specific html/php code for each value for each step. you would do this by having the form fields and validation steps for each field/type defined in a data structure somewhere (a database table or an array.) the data structure would contain the dynamic information for each field in each step, such as the form field name, the label for the form field, the type of form field, any lists of choices (select/checkbox/radio), and what validation step(s) to 'call' (using variable functions) for each field.

if you are at the point of trying to make an install script, all your code manipulating the values should be general purpose, rather than hard-coded with specific variable/defined constant names. if you are using variables, use an array ($config['db_host']). if you are using defined constants, use a prefix on the names (CONFIG_DB_HOST) so that you can distinguish them from any other defined constants you have in your code. the only thing in your config file should be the settings. there should be no functional code, such as the database connection. then, at the point of saving the values, why not just loop over the array/prefixed named defined constants and write out the php code containing the current values?

we actually know what you are trying to do, what we need to know is where you are stuck at when you tried to do it, because the purpose of programming help forums are not to write complete working code for you or to think out the details of each step that you need to do, we are here to help when you get stuck on something, after you have made an attempt at doing it. have you defined the user steps for the confirm-order process? what information do you have and what will be displayed at each step, and what new information do you need from each step? seems that if the visitor is viewing the contents of the cart and are ready to finalize the order, wouldn't the next step be to collect any new customer information or confirm existing customer information, such as ship/deliver address (it could be different for each order), billing name/address (if they use a different payment method, this can be different for each order), ... then create a record in an 'orders' table for this customer on the date and time in question that would assign an order_id, that you would then use to relate and store the contents of the cart in an 'order_items' table? once you have done this, you would have a 'pay' form/button that would submit/take them to the paypal site for the actual payment process. the code for the particular step of inserting the data into the 'order_items' table, would in its simplest form, be to just loop over the contents of the cart, form and run the INSERT query with the order_id, the dish id, quantity, and if the price can vary, the price at the time of the order. for bonus points, you can form and run one efficient multi-value insert query, rather than running a query in a loop. the code you have for your session based cart needs to be simplified. you should create a $_SESSION['cart'] variable that is an array of the cart contents - $_SESSION['cart'][dish id] = quantity. this will eliminate all the substr() statements in the code. also, if the quantity of an item in the cart is/reaches zero, you should remove it from the cart. since the value stored in the cart is the quantity, you can just use php's array_filter() function to remove empty items from the cart.

the program logic that you are showing us makes no sense. the $event->nodeValue you are testing to come up with a color is the last value from the loop that's building the $events array. unless there's only one event or all the events are the same type, this won't result in the color matching the event type. regardless of your intent to loop or not, the value you test to come up with the color needs to be the $message value you are actually displaying. as to your current question, it's not clear if you want the first event or the first event of each type to be displayed. if you show an example of what the $events array looks like (and is the data from the rss feed in any particular order?) and what result you want based on that data, someone can tell you how to proceed. btw - your big long switch statement can be changed to a single program statement, assuming you switch (pun intended) to using a data driven design. see the following - // define the event type/name to color association (this would typically be stored in an included config file or in a database table) $color_mapper['Tornado Warning'] = 'rgba(255, 0, 0, 0.4)'; $color_mapper['Severe Thunderstorm Warning'] = 'rgba(255, 165, 0, 0.4)'; $color_mapper['Tornado Watch'] = 'rgba(255, 255, 0, 0.4)'; $color_mapper['Severe Thunderstorm Watch'] = 'rgba(219, 112, 147, 0.4)'; $color_mapper['Flash Flood Warning'] = 'rgba(139, 0, 0, 0.4)'; $color_mapper['Flood Warning'] = 'rgba(46, 139, 87, 0.4)'; $color_mapper['Flash Flood Watch'] = 'rgba(0, 255, 0, 0.4)'; $color_mapper['Flood Watch'] = 'rgba(46, 139, 87, 0.4)'; $color_mapper['Flood Advisory'] = 'rgba(0, 255, 127, 0.4)'; $color_mapper['Winter Storm Warning'] = 'rgba(255, 105, 180, 0.4)'; $color_mapper['Winter Storm Watch'] = 'rgba(70, 130, 180, 0.4)'; $color_mapper['Winter Weather Advisory'] = 'rgba(123, 104, 238, 0.4)'; $color_mapper['Special Weather Statement'] = 'rgba(255, 228, 181, 0.4)'; // at the point of mapping the event type/name to the color $alertColor = isset($color_mapper[$message]) ? $color_mapper[$message] : 'default value goes here...';

how many different databases? 5, 10, 100? there are no wild-card ALL database commands. to do this under program control would require that you get (from the schema data) or manually make a list of the databases with the tables you want to use as the source, then run a query for each source database that inserts into the destination database using an INSERT ... SELECT query. the mysql documentation for the INSERT ... SELECT query states it can be used to insert from multiple tables, which should include (untested) the ability to specify the database.table. assuming this will work for a UNION query, you could build the SELECT part of the INSERT ... SELECT to be a UNION query between all the database.tables that you need. to do this manually, the most efficient way i can think of would be to do .sql backups of all the source databases/tables that you need. then edit them so that the USE database commend points to the destination database. then simply import the data using the .sql files.

here is the sample code i posted above, with more details showing how it would control the building of the sections - // the business logic retrieves and stores the query results in an array $data. this serves as the input to this section of ocde if(empty($data)){ // there's no matching data, output an appropriate message here... } else { // there is data, start producing the output... $last_type = ''; // initialize this before the start of your loop that's display the data foreach($data as $row){ $strPrefix = substr($row["Prod_Type"], 0, 2); // output the product type heading each time it changes if($last_type != $strPrefix){ // the type changed if($last_type !=''){ // not the first section, close out any previous section here... // close the </div> for example } // start a new section here.... start the <div>, output any type image, .... $img = $types[$strPrefix]['img']; $alt = $types[$strPrefix]['alt']; echo "<img border='0' src='$img' alt='$alt'>"; $last_type = $strPrefix; // remember the new value } // output the data in each recored here.... } // you would close the last section here. whatever logic you have in the if($last_type !=''){ ... } above would be repeated or in a user written function that you call }

i recommend to just rewrite the presentation portion of the code to produce the output you want. the example code i posted above is actually more relevant to this than just the switch/case statement. by detecting the change in the RB, BH, RA type, the code can finish off any html for the previous section and start a new section. the code that displays the data just goes right after the if(){} logic i posted. i do have another general suggestion. separate the business logic from the presentation logic. the business logic contains the php code that figures out what to do on the page and retrieves any data that's need to display the page. the result of the business logic should just be php variables. all the database specific statements should be in the business logic (you would pre-retrieve database data and store it in an array) and there should be no html markup in the business logic. the presentation logic should contain no database specific code, since it will receive any data it needs in php variables. the presentation logic should contain all the html/css/javascript.

lol, spam in the spam filter thread ^^^. the GD based captcha works and should be use in the meantime. the complaint posts about the gd based captcha (from a member that had already written a couple of posts and never replied when asked a question about it and another member that never posted after the complaining post) were most likely from (the same) spammer(s) that just wanted an easier captcha.

we don't really know what you want to do different. can you specifically show an example of what part of the data and exactly how you want it to be done differently? also, this code has several problems that you should fix or change first. the two biggest ones are you should be using css to style everything, not inline styling, and your two nested while(){} loops, that are looping over the same data. by having these two nested loops, the first one is really only acting like an if() conditional statement to run the rest of the code. however, by having these nested loops, the first row of your result set is not being displayed, because the nested loop that's actually displaying the data, is fetching and starting at the second row in the result set. here's a general suggestion that will help reduce that huge switch/case statement, by eliminating the repeated logic and converting the design into a data driven one, rather than a hard-code logic one, and make it easier to change or fix the html markup, because any particular piece of markup will only exist once in the code. define the type information - // define the type information (typically this would be stored in a 'config.php' include file or retrieved from a database table) $types['BH'] = array('img'=>'bulkheads.jpg','alt'=>'Bulkheads'); $types['RB'] = array('img'=>'roofracks.jpg','alt'=>'Roof-Bars'); // ... repeat for all product types initialization, before the start of the while(){} loop - $last_type = ''; // initialize this before the start of your ONE while(){} loop that's display the data at the point where you want to output the product type image inside the loop - // output the product type image each time it changes while displaying the products if($last_type != $strPrefix){ // the type changed, output the image $img = $types[$strPrefix]['img']; $alt = $types[$strPrefix]['alt']; echo "<img border='0' src='$img' alt='$alt'></td></tr>"; // since this markup and code only exists once, if you are changing something about this section of code, you only have to make the change in one place echo $title; $last_type = $strPrefix; // remember the new value }

you actually need separate if() statements, for the if(!$skin)... tests. the value you are testing is dependent on the previous if() statement, not exclusive of it. an if/elseif/else string of test are exclusive of each other.

my supposition about different databases/connections was just one of the many possible things that could be causing the problem. i/we could probably list a dozen different possible things, but won't, because your setup could be doing something different than what i/we have in mind, and the actual problem could be the 13th item that no one thought of. you need to 'close the loop' by providing some investigation and feedback in order to narrow down the possibilities. solving this will require that you actually add the things that i mentioned to the code in order to pin down where and what is actually happening.

the following lines from that code are the relevant ones that you would need to call with the three different sets of $iWidth and $iHeight values, along with the appropriate path where you want the imagejpeg() to save the file - $vDstImg = @imagecreatetruecolor( $iWidth, $iHeight ); // copy and resize part of an image with resampling imagecopyresampled($vDstImg, $vImg, 0, 0, (int)$_POST['x1'], (int)$_POST['y1'], $iWidth, $iHeight, (int)$_POST['w'], (int)$_POST['h']); // define a result image filename $sResultFileName = $sTempFileName . $sExt; // output image to file imagejpeg($vDstImg, $sResultFileName, $iJpgQuality);

you would dynamically build the WHERE part of the $sql = " ... "; string using php code. for something like (no pun intended) a repeated like term, it is easiest to build each term as entries in an array, then just implode the array with the OR keyword. you should have an array with the possible choices that you are using to both build the form and to build the WHERE part of the query (blindly looping over the submitted form data is not a good idea as hackers can submit hundreds of form fields.) as you loop over the defining array, if that particular form input isset(), to indicate the checkbox was checked, add the `manufacturer` LIKE '%abc' portion of the query into an array. when you get done looping over the choices, if the array is not empty, just implode it to form that part of the query (note: implode will produce the correct result even if there is only one entry in the array.) edit: for the example you posted, the code would look like this - $cars[] = 'BMW'; $cars[] = 'Audi'; $terms = array(); if(!empty($_POST['check_list'])) { foreach($cars as $choice){ if(isset($_POST['check_list'][$choice])){ $terms[] = "`manufacturer` LIKE '%$choice'"; } } } $where_clause = ''; if(!empty($terms)){ $where_clause = "WHERE ".implode(' OR ',$terms); } $sql = "SELECT * FROM `Cars` $where_clause ORDER BY `tier` ASC";

sorry to jump in here, but this example code you found is poorly written. it's only claim to fame is it shows up on the first page of web search results or it's being suggested by php programming courses. using it, assuming you can even get it to work, isn't going to help you create web pages or learn how to program. you should just learn to use the underlying framework and write you own code. in short, if you don't have the programming skills to troubleshoot why this example code doesn't work and it doesn't have code already in it to tell you why it isn't working, you need to contact the author of the code to have him/her troubleshoot and fix the problems in it.

in the non-working case, you need to actually pin down what the code and data is doing, before you can even locate what needs to be fixed. you could for example have some broken html on the page for the id = 4 case that's causing the form to be invalid markup and it does not submit any data. the data itself may be invalid (or empty) and is resulting in query errors or a query that's not matching anything. your code could even be running twice for some reason and updating the data correctly, but is also updating it again back to the original values. you need to determine exactly what code is running, what values are being used by the code, and what is being returned from statements. 1. make sure that the code where the update queries are at is actually running. you should be forming the sql statements in a php variable (always), then just use that variable as input to the function that's running the query. you can then echo/log the contents of that variable for debugging purposes so that you will know that the queries are being ran and what data they actually contain. 2. make sure that all the queries are running without any errors. you should (always) test the returned value from a query for errors. an UPDATE query will return a false value when there is a query error. you can echo/log the mysql_error() information to let you know what the error is. and as a side note: you are using both the tep_db_query() and mysql_query() statements to perform queries. you could have a case where there are multiple database connections (even a default one set up by the php installation) and each of those methods of running a query could be operating on different databases. perhaps the database connections for one id = value are all using the same database and the code works, whereas for the other id = value, there are errors or missing data due to multiple database connections being used in the code.

that may be WHAT doesn't work, but exactly what about it doesn't work. are the values not displayed for picking, does the page just 'refresh' without apparently doing anything when the form is submitted, is the form data not present in the form processing code after the form was submitted, are there php errors, query errors, is the data just not updated in the database table, or is the data actually present in the database table but it is not having an affect when it's being used? in short, what symptom do you see in front of you, since we're are sitting there with you to see it, that leads you to believe 'it doesn't work'? there's very little backwardly incompatible differences between most of the php versions, and these things are generally obscure things that most code doesn't use (they are documented in the php.net documentation, appendix.) most problems like this are due to php configuration differences. in fact, only in the php5.4 version were a number of obsolete things finally removed (your use of $HTTP_GET_VARS for example aren't present as of php5.4+). edit: you also mentioned that the problem is associated with - vendors2_id = 16 works, vendors2_id = 4 does not work. the posted code only has vendors2_id hard coded as a 16. is the posted code the actual code that doesn't work and if not, why do you have different code that only differs in a value that's has hard coded that value rather than using one instance of the code and using a variable for the, well, variable value in it? if the code with a vendors2_id = 4 in it doesn't work, perhaps that's the code you need to post.

you should store the raw data for each week/game/player as a separate row in a 'result' table, similar to what you do with a bank account statement. then simply do a sum() in a query to produce a score for any player(s) when needed. this will do two things - 1) keep a specific record of who, what, when, and where something occurred 2) prevent duplicate entries/processing from corrupting the data.

sorry, but no you haven't. look at and compare the second line of code in both of the pieces of code in my reply #8 and in your reply #11. you should be able to notice what's logically different about those lines. in the line that's from your previous thread, you are assigning the result form the ->prepare() method call to a variable, $stmt, that then gets used in the bindParam() and the execute() method calls. programming is an exact science. the computer only does exactly what your code tells it to do. if a statement returns a value that you must then use in the following dependent statements, you must be able to 'get' that kind of information when you read the documentation and examples.

user preferences (and privileges) are usually stored in a database table and retrieved on each page request. this allows them to be easily modifiable by site moderators/admins and they take effect immediately (on the next page request.) storing them in session variables means that only the visitor that the session belongs to can easily modify them or you must add a lot of unneeded complexity to make the session data find-able and editable by site moderators/admins. a 'remember me' login is usually accomplished by generating a unique and hard to guess token, that's not a fixed value tied to any user information, storing that token in a cookie and storing it in the user row in a database table. in this case, the logged in/logged out state is also stored in the user row in the database table so that the only way that someone who's logged out can become logged in is for them to submit their username/password.

your program logic will default to the catch{...} block for all database errors, so even though the message being output says, "Connection failed: ..., you actually have an error at one of the query statements. i recommend that you change your code to consistently use one variable name to hold the sql query statements, something like $sql. then, in the catch{...} block, if $sql is empty, you know you reached that point due to a connection error. if $sql is not empty, you know you reached that point due to a query error. this logic will let you echo the $sql query statement as part of the error so that you can look to see what might be wrong with it. change your catch{...} block to something like the following - } catch(PDOException $e) { $status = empty($sql) ? 'Connection failed':" Query failed: $sql"; echo "$status, Error: {$e->getMessage()}, File: {$e->getFile()}, Line: {$e->getLine()}"; }

There's probably 20,000 examples of what you are asking posted on the web. in fact that's what the web was created for, publishing and sharing information. your first stop should be to do a web search and try to accomplish this assignment yourself. programming help forums are for helping those that already have code and have tried.

here's another hint. the following is your SELECT ... query from the previous thread, with the correct bind usage - $sql = "SELECT ...."; $stmt = $handler->prepare($sql); $stmt->bindParam(':username', $username); $stmt->bindParam(':password', $hash); $stmt->execute();these are the corresponding lines of code from this thread - $sql_string = "INSERT INTO users SET username = :a, password = :b"; $sql->prepare($sql_string); $sql->bindParam(':a', $username); $sql->bindParam(':b', $hash); $sql->execute();lines 2-5 of both of these pieces of code should be logically the same and in fact should be identical for consistency reasons (why keep writing/changing code that's performing the same actions.)