Jump to content

mac_gyver

Staff Alumni
  • Posts

    5,367
  • Joined

  • Days Won

    173

Everything posted by mac_gyver

  1. you would make links that contain a get parameter that tells your one page how you want to sort the data, such as ?sort=date&direction=asc you would then test for and validate the get parameters and use the values to determine what sql query statement to build (don't use the values directly in a query without being fully validated to insure they are ONLY one of the permitted values in order to prevent sql injection.) you would also build the pagination links with whatever existing get parameters there (you can use http_build_query to do this) are so that they propagate between the page requests when you click on the pagination links.
  2. your testing on the development system should have found things like query errors. your code should also have logic that tests each query to see if it failed or not and take an appropriate action. if a query does fail, you should output a user message - 'Sorry, an error has prevented this page from completing the requested operation' and log the actual query and the database error message. testing is more than just checking that the code runs. it means testing if the code does what you expect for both expected values and unexpected values and making sure that the code produces the expected result for all the possible execution paths/logic branches.
  3. things which are configuration dependent (and php version dependent) will be producing either php syntax or runtime errors. if the pages all actually run at all, then at least the main pages don't contain php syntax errors and you can set php's error_reporting to E_ALL and display_errors to ON in the code to see what errors are being detected by php. you could also post the code here and someone could directly tell you the most likely things it is doing that would be configuration or version dependent.
  4. using a prepared query with the IN() comparison, will require that you dynamically supply a place-holder in the query for each value in the array - it must look like IN (?,?,?,?,?), you must dynamically build the bind_parm() statement with the correct first parameter with a type character for each place holder, and the hard part, you must dynamically supply a 2nd through nth parameter consisting of a variable (which can be an array element) for each parameter. if you look at the user contributed notes in the php.net documentation, either in the msyqli prepare or mysqli bind_parm section, you can probably find a script/class that helps do this for you. to build the place-holders and the type character string, you can just get a count of the elements in the array and use string functions to build those. to actually supply a dynamic number of parameters to a function, you must use call_user_func_array(). or if you can switch to using the PDO database library/class, all of this becomes very simple, because you can bind each parameter separately.
  5. you could of course write out a ->bind_result() statement that lists a $row['column_name'] variable for each column you have selected in the query, but that wouldn't be general purpose and would require that you do a lot of typing that the computer would be more than happy to save you from doing each time you write out or change a query. fortunately, i have done this before, and when you see how much code this takes, you will see why we recommend using the PDO database library/class. with respect to the code i posted as an example above, the following section - $stmt->execute(); ... // the above php code is the business logic, that knows what to do on the page and how to get data from the database is replaced with this - $stmt->execute(); $meta = $stmt->result_metadata(); $variables = array(); // the 'bind_result' parameters $data = array(); // array to reference to hold the actual fetched data $fields = array(); // just the field names, for building the display header while($field = $meta->fetch_field()){ $variables[] = &$data[$field->name]; // parameters to 'bind_result' are references to the data array elements $fields[] = $field->name; } call_user_func_array(array($stmt, 'bind_result'), $variables); $results = array(); $i=0; while($stmt->fetch()){ $results[$i] = array(); foreach($data as $k=>$v){ $results[$i][$k] = $v; // you must specifically access the key/value (otherwise you get a reference to the element in $data and they are all the last value fetched) } $i++; } $stmt->close(); // the above php code is the business logic, that knows what to do on the page and how to get data from the database
  6. this is covered in point #2 in my post and the php.net documentation for msyqli prepared queries. the portion of the code using ->get_result() will need to be rewritten to use the ->bind_result() and ->fetch() methods. if you continue to use mysqli statements, you will need to use a ->bind_result() statement to bind each column being selected in the query to a php variable (array entries will work), then, in your existing while(){} loop, use the ->fetch() method to get the data from the query into those variables. if you instead switch to using PDO statements, you can avoid all of this mess, because no matter how you run the query (prepared statements or not, regardless of any driver or php version differences), you can use PDOStatement methods to fetch the result form the query.
  7. the parentheses are not part of the require_once statement (it's not a function.) what using them does is cause php to evaluate the term they enclose, similar to using parentheses in a math equation to force operator precedence.
  8. the last code you posted won't even parse, it's missing the closing syntax of two php constructs. i even see a double $$ on a variable and wrong variable names being used. programming is an exact science. every character matters. sometimes, capitalization of those characters matters. every variable name matters. every statement, what it does and what it contributes to your goal, matters. copy/pasting code together isn't how programming is accomplished and isn't how learning a programming language works either. you must actually learn what the basic language syntax is, then what each statement you are using means and does, so that you can write code that uses the language syntax and statements to accomplish the goal you are trying to achieve. next, you need to define the goal you are trying to achieve. besides a statement of what you are trying to accomplish (in this case, process form data to retrieve and display a corresponding piece of information from a database table), you need to define what inputs you have available, what exact processing you want to do based on those inputs, and what exact result or output you want to produce. i'm not going to take the time to list what's wrong with the posted code because, well, you need to start over with the php portion of your code and write it yourself to do what you want it to do. i have one hint, htmlspecialchars() is an OUTPUT function. it is used when you output data onto a web page. it is not used on input data to a script. any code you may have found posted on the internet that showed using it on data going into a database query was an incorrect application of the function.
  9. the most immediate problem is that your <select> tag doesn't have a name='tank' attribute, so there's no value being submitted to the php code. as akphidelt2007 mentioned, you need to have php's error_reporting set to E_ALL and display_errors set to ON (in your php.ini on your development system) so that php will help you by reporting and displaying all the errors it detects. this will save you a ton of time during the learning and debugging process.
  10. with all the changes that have been made, what is the current end result/symptom when this fails? i would still be concerned about the values not being urlencoded (which the http_build_query does for you) when building the links, since any sort of non-url-permitted character could be treated differently by different browsers and would result in the submitted values being different from what was used to build the link and so wouldn't match in a database query.
  11. text textarea, and password form fields will be set, even if they are empty. your form processing logic should first test if your form was submitted, then specifically test the content from each form field. for fields that are required, at a minimum, you would want to test if their character length is greater than an acceptable minimum.
  12. some more advantages of rearranging the code as ginerjm has suggested are - 1) it will be easier to update the existing mysql code to use the mysqli or POD database functions, since the mysql functions are obsolete. all the database code will be close together, near the start of the code file. 2) since the main logic that determines what to do on the page and what data is being produced will be grouped closer together, it will be easier to avoid problems like the $userid variable problem. 3) it will make testing and debugging the code easier, since once you have determined that the main php code is producing the correct result, you can forget about that part of the code and concentrate on getting the correct output on the web page. 4) you will be able to perform a header() redirect back to the same page once you have successfully processed the form data, thereby making the user experience better since the browser won't attempt to resubmit the form data should you refresh the page or navigate back to any page that was the target of a form submission.
  13. @JTM, is this a second account for you? we have another member joemal, that posted code for this same assignment and from the same location you are at.
  14. there are existing resource availability/resource reservation scripts that probably do this in some fashion (likely for reserving/booking rooms, rather than a trainer, but the logic is the same.) you would need a table to hold the resource (trainer) availability schedule, all resources in stored in the same table, using a resource id to identify which rows are for each resource. for reoccurring schedules, you would need to store the definition of the schedule (Mike is available on Mondays-Friday from 8am-5pm) and evaluate it, storing the resulting dates and times in the availability schedule table, as needed (any query displaying data with a date higher than the latest stored date would evaluate the definition to populate dates up to at least the latest display date.) you would have a second table to hold resource reservations, with the resource id, the id of who is requesting the resource, the date, start time, end time, and a status. the status would indicate if the resource has been requested (someone selected a date/time slot, but it has not been confirmed) or booked (if the trainer has reviewed and confirmed the reservation.) any resource reservation with either of those status values would not be available for selection. if there is a preference for a particular resource or type of resource, you would get and apply a filter in the query that determines which resource id(s) you match in the resource schedule table and for just the date(s) you are trying to display. you would then join the rows from that table with the resource reservation table, using the resource id and date columns, to get the row(s) and therefore the start/end times the resource is (is not) available for selection. that should get you the data you need to display a grid of appointment slots that are (are not) available for selection.
  15. that's the binary data of a png image. either your code isn't outputting a content type header for a png image, or it is but the header isn't working, or you are trying to output the image data on a html web page, which isn't how images are displayed. what's the php code that's doing this and do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would report things like header errors?
  16. you would put the sum logic into the existing query (2nd one in the posted code), so that it would produce a total for each row.
  17. it's likely that the actual data you are getting from your database query isn't what it looks like or you have a variable scope problem. when you printed the $start_point value, where exactly in your code did you do that and what does using var_dump($start_point);, right before the code you have shown us, give for the value?
  18. your online test page stops producing output after the <body> tag. that's a sign you are getting a fatal php runtime error prior to any php echo statements. do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would help you by reporting and displaying all the errors it detects? edit: especially since your database table name is not calendar.
  19. in programming, you need to be careful what wording you use. when you mentioned inserting data, that was taken to mean insert data into a database table. what you actually meant is displaying data in the calendar you are outputting on the web page. there's no inserting involved, you are taking data you have at some point in your code and producing html that displays that data the way you want it to be on a web page. using the mysqli code converter to get your code to use the mysqli functions isn't going to get you much sympathy, because it produces messy, lazy, error prone code. learn to actually use the mysqli or PDO statements and rewrite the code yourself. there's a minor problem with the (test) $entries data that's in the code now, in that the data you eventually retrieve from your database table and put into $entries will have leading zero's on the month and day fields and will have - separator characters. by default, unless you do more work to get there, the format will be YYYY-MM-DD. the line of code to build the corresponding $dateKey value will be - $dateKey = sprintf('%04d-%02d-%02d',$currYear,$currMonth,$d); if you change the format of the test data in $entries and the above line of code, this should get your code to display your test data. the next task would be to retrieve the event data from your database table, that matches the $currYear, $currMonth values, and store it into the $entries array in the necessary format.
  20. besides listing what you want, do you have a specific programming question or a problem you need help with?
  21. some points that hopefully will help - 1) you should be development and testing code on a localhost development system, where you can easily set php's error_reporting to E_ALL and display_errors to ON in the php.ini so that ALL the errors php detects will be reported and displayed. the last problem pointed out, about the syntax of using a php array variable inside a string, in your main file, would have been producing php parse/syntax errors, that will only show up if you have php's error_reporting/display_errors set in the php.ini. 2) the ->get_result() method is specific to a certain type of underlying database client driver being used (mysqlnd) and may be producing a php run-time error (which is why, again, you should be developing and debugging code on a system that has php's error_reporting/display_errors set so that php will help you.) the example code i am posting below uses another mysqlnd specific statement, ->fetch_all(), that may not work either. if these two statements produce undefined method php errors, the code using them will need to be rewritten or more simply, if it is an option available to you, use the PDO database statements as they are much easier to use. 3) in general, the code producing or containing any of your your html/css/javascript (client-side) markup should be separate from the portion of your code that knows how to retrieve data from the database. the code producing the html should have no database specific statements in it. this will allow you to more easily change the type of database statements being used or to delegate and divide the work among others. you would retrieve the data from your database and store it in a php array variable, then simply loop over that variable in place of the while(){} loop you have now that's making use of the msyqli fetch statement. 4) your code producing the table output can and should be written to be general purpose as well, so that it can display any amount of columns and rows that the query retrieves. a rearrangement of your code that demonstrates (untested) these points (and while i was doing this i noticed an ->execute() method statement that wasn't, which would have been producing another php run time error) - <?php $mysqli = new mysqli("localhost", "guestuser", "guestuser", "SMQ"); if ($mysqli->connect_errno) { echo "Failed to connect to MySQL: (" . $mysqli->connect_errno . ") " . $mysqli->connect_error; } $validScott = $_GET['scott']; $query = 'SELECT Scott, Den, Color, Cond, 70, 70J, 75, 75J, 80, 80J, 85, 85J, 90, 90J, 95, 95J, P98, 98J, 100 FROM SMQSQL WHERE Scott = ?'; $stmt = $mysqli->prepare($query); $stmt->bind_param('s',$validScott); $stmt->execute(); $result = $stmt->get_result(); $results = $result->fetch_all(MYSQLI_ASSOC); // if the ->get_result() method is present, the ->fetch_all() method is also available, otherwise you will need to bind the result from the query and fetch it or use the more friendly PDO database library $stmt->close(); // get data for table heading $finfo = $result->fetch_fields(); $fields = array(); foreach ($finfo as $val){ $fields[] = $val->name; } // the above php code is the business logic, that knows what to do on the page and how to get data from the database // the following code, is the presentation logic, that knows how to produce the output on the page $heading = "<tr><td>".implode("</td><td>",$fields)."</td></tr>"; $queryResult = ''; foreach($results as $row){ $queryResult .= "<tr><td>".implode("</td><td>",$row)."</td></tr>"; } ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "[url=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd]http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">[/url] <html xmlns="[url=http://www.w3.org/1999/xhtml]http://www.w3.org/1999/xhtml">[/url] <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Online SMQ</title> </head> <body> <form name="searchForm" method="GET" action="#"> <input type="text" name="scott"> <input type="submit" name="submit" value="Search"> </form> <p> <table> <?php echo $heading; ?> <?php echo $queryResult; ?> </table> </body> </html>
  22. @subhomoy, the following paypal link describes the process you will need to use for the IPN information - https://www.paypal.com/in/cgi-bin/webscr?cmd=p/acc/ipn-info-outside as the last step, to finally record the payment as being successful/complete for a user, for a specific order he has made, you need to check the payment_status value, which is something that fastsol included in his post. in fact, since you are not using or storing that value, it's possible that your duplicate data in the payment table has two different statuses. you may want to log each set of data your ipn script receives so that you can detect nefarious activity. next, just because the data your ipn script receives is coming from paypal, doesn't mean it is safe. since you appear to be using the PDO database class, you should be using prepared queries. lastly, your code appears to be making a database connection for each query you are running - $pdo->connect()->query(...). if that is the case, you should only make ONE database connection and use that connection throughout your script.
  23. your page is being requested twice. you would need to do some debugging to find out way. some causes are url rewriting you are doing for your site or even how your web hosting is passing the request to the server where your web site is hosted. however, you cannot prevent duplicate requests in all cases and you need to enforce uniqueness within your application to filter out duplicates. your payment table should be setup with a unique composite key that prevents duplicate transition id/user id combinations. next, when dealing with real money or any sort of data that you need to have the ability to audit the data, you should not simply add the amount to a sum in a column. you should treat this as a deposit/debit account, where you use a query to sum up the transactions to determine the current amount in the account each time you need the current total.
  24. the second thread you started for this in the ajax forum section has been removed. there's no evidence the problem is in any of the client-side ajax code and if debugging this should show that's where the problem is at, this thread can be moved to the appropriate forum section.
  25. this is actually about the same logic as in your last post, but eliminates the extra code at the end to finish the last day of the week - <?php $fd = array(); $fd[0] = array('f'=>"8:00 AM",'t'=>"4:30 PM"); $fd[1] = array('f'=>"8:00 AM",'t'=>"4:30 PM"); $fd[2] = array('f'=>"",'t'=>""); $fd[3] = array('f'=>"9:00 AM",'t'=>"1:00 PM"); $fd[4] = array('f'=>"",'t'=>""); $fd[5] = array('f'=>"9:00 AM",'t'=>"1:00 PM"); $fd[6] = array('f'=>"",'t'=>""); $WeekDays = array("Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun",''); // the extra value on the end processes the last day without repeating any logic $last_from = null; $last_to = null; $output = ''; $last = count($WeekDays)-1; foreach($WeekDays as $key=>$day){ if($key == $last || $last_from !== $fd[$key]['f'] || $last_to !== $fd[$key]['t']){ // it's past the end or the from/to is not-equal to last values if($last_from !== null){ // not the first section, build the section that just ended $end_key = $key-1; $op = ($fd[$end_key]['f'] != '') ? "{$fd[$end_key]['f']} to {$fd[$end_key]['t']}" : 'Closed'; $dy = ($start_day == $WeekDays[$end_key]) ? $start_day : "$start_day - {$WeekDays[$end_key]}"; $output .= "$dy $op<br>"; } // start a new section $last_from = isset($fd[$key]) ? $fd[$key]['f'] : ''; $last_to = isset($fd[$key]) ? $fd[$key]['t'] : ''; // remember the new values $start_day = $day; } } echo $output; the data array is organized differently to make the references clearer. you can change the form field names to submit the data as shown or change the references in the code to match your current form field names.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.