Jump to content

mac_gyver

Staff Alumni
  • Posts

    5,529
  • Joined

  • Days Won

    189

Everything posted by mac_gyver

  1. each different form processing code needs to test for a unique field name in the form, such as a hidden field, so that only the form processing code that corresponds to the submitted form will run. // post method form processing code if($_SERVER['REQUEST_METHOD'] == 'POST'){ if(isset($_POST['a_field_that_uniquely_identifies_form_1'])){ // all the form processing code for form 1 } if(isset($_POST['a_field_that_uniquely_identifies_form_2'])){ // all the form processing code for form 2 } // any other form processing code // if there are no errors, you should do a header() redirect to the exact same url of this page so that the browser won't try to resubmit the form data // to pass any 'success'/'thank you' message to be displayed when the page gets displayed after this redirect, pass it/them in $_SESSION variables // you should also exit;/die; after any header redirect to prevent the remainder of the code on the page from running // if there are errors, don't redirect and let the code on this page display the error messages and redisplay the form } // end of post method form processing code // any get request - display code starts here... the above code should set error messages in an array - $errors['form1_name'][] = 'some message'; or $errors['form2_name'][] = 'some message'; at any point to detect if there are errors, you can just test if the $errors array is empty or not. to display the errors for any form, just test for and loop over the $errors['form1_name'] array elements.
  2. your pagination links need to include the $_GET['id'] value (and any future possible items you add to links.) if you build the query string part of the pagination links using http_build_query(), this will happen 'automatically'. if you do an advanced search on the forum for http_build_query() and my user name, you will find a page worth of examples showing how to use http_build_query() to combine any existing $_GET variables with your pagination values when you build the links. edit: here's one showing the phpfreaks pagination script, modified to use http_build_query() - http://forums.phpfreaks.com/topic/291074-php-mysli-pagination-with-items-per-page-select-option/?hl=%2Bhttp_build_query&do=findComment&comment=1491152
  3. Lines 120-125 are probably inside of a conditional statement, so that they don't become defined until that conditional statement is true. function definitions should all be grouped together and come near the start of your code or even be in a separate file that gets included near the start of your code.
  4. the WHERE clause would be - WHERE YEAR(LastVisit) = whatever_year_value_you_want i'm pretty sure this would have the same level of performance as your Last 6 months query.
  5. and the multi-value update can be implemented as the following without having to dynamically produce case logic in the query (assuming that id is a unique index) - INSERT INTO tablename (id,col2) VALUES (1,'AAA'),(2,'BBB'),(3,'CCC') ON DUPLICATE KEY UPDATE col2=VALUES(col2)
  6. you shouldn't be trying to put any search/filter functionality into the low level interface/driver. the purpose of that code is to serve as an interface between the application and the api. that's all it should do. it's your application code that knows what the data means and is where any data processing belongs. xpath is used to select nodes from an XML document. you don't need to find the nodes containing the data, you already have them. for bulk data processing, looking for each individual data record in the xml is not efficient. just loop over the bulk xml data and determine for each record if you need to insert a new database row for it (it doesn't exist at all) or update/replace the values in an existing database row.
  7. for a php produced page, your code should be laid out in this general order - initialization, post method form processing, get method processing, and html page/template. (see the following post for more information about these items - http://forums.phpfreaks.com/topic/296602-storing-multipe-session-variables-for-a-cart/?hl=%2Binitialization&do=findComment&comment=1513104 ) the defined constants, $path, and $a[] statements from the code in this thread are configuration information. they would typically be in a config.php file that you include in the initialization section on the page. the $hm, $d and the foreach(){} loop are part of the get method processing code, they produce data, the $img value, to be used in the html page/template section. the final if(){{}else{} statement that displays a message or outputs the <img ...> tag goes in the html page/template section, at the point where you want to display the image. the html page/template section starts with the <!DOCTYPE tag through to the </html> tag.
  8. here's the likely problem that's causing the else {} block of code to take (much) longer than the initial storing of the data in the if(){} block of code. you are storing multiple rows for each FixtureMatch_Id, one for each bookmaker and, i would guess, type combination. so, for any FixtureMatch_Id, you have 20+ rows. when you are updating the information, in the else {} block, your select query is just getting the FixtureMatch_Id and UpdatedDate, and the rows in the result set will be in no particular order. you are getting all the rows from your table, 20+ rows for each FixtureMatch_Id, times the number of different FixtureMatch_Id values. as you are looping over the database rows, you are hitting the XMLSOCCER.COM api for each row. for any particular FixtureMatch_Id value, you are retrieving the same data from the api 20+ times, repeated for each different FixtureMatch_Id value. for what you are doing (as far as i can tell), if you set up the correct unique composite index on your database table, you can use the code in your if(){} block, without the condition around it, with a REPLACE ... query, to INSERT new data and UPDATE/REPLACE existing data. the unique composite index would be over the - fixturematch_id, bookmaker, and type columns. note: this method will REPLACE data in the table that has the same updateddate as the 'new' data, wasting some database processing time. if you want to avoid this extra work on the database side, you would have to select the fixturematch_id, bookmaker, updateddate, and type from the table first, and detect when those four combined values are different from the data being put into the query. the most efficient code for doing this would be to concatenate those four values, with a unique separator character ( a | for example) and store the values in an array. you can then concatenate the data values using that same separator and use an in_array() statement to find if the composite value is already in the database data. if it's not found, run the query. if it is found, don't run the query. lastly, the bindparam() statements don't belong inside the loop. the only thing that goes inside the loop are statements that populate the variables that were bound and the ->execute() statement. edit: if you use an INSERT ... ON DUPLICATE KEY UPDATE ... query, instead of the REPLACE query i mentioned, it may (untested) be more efficient and you won't need to first check if the updateddate has changed, assuming that the UPDATE part of this type of query operates the same as any UPDATE query, which doesn't actually perform the UPDATE (writing the data) if the new data values are the same as the existing data in the record.
  9. are you using the XMLSOCCER.COM api's parameters to get just the data you want, for example GetAllOddsByFixtureMatchId, or are you getting all of the data and trying to parse it yourself?
  10. no. you have to find what''s causing the problem, before you can fix it. the javascript would apply to the client-side rendering time, which isn't much, compared to the time waiting for the server to send the response.
  11. i just checked the http://www.compareandchoose.com.au/adventure_activities page at both http://developers.google.com/speed/pagespeed/insights/ and http://tools.pingdom.com/fpt/ and the large amount of time taken, ~2 seconds, is waiting for the response back from your server, rather than things the browser must do to render the the page. the amount of time is fairly consistent, over about a 5 minute period i checked. you will need to profile what the code is doing in order pin down where it is spending this amount of time.
  12. you need to determine the page generation time, by taking the microtime(true) value at the start of the code on a page and again at the end of the code on the page, and calculate the difference. this will tell you if the problem is with the generation of the page or elsewhere, such as in the web server taking a long time to actually invoke php after the http request was received. if it turns out the problem is in the page generation, you need to calculate the time taken at different points in the code, around database activity, around calls to external api's, ... to narrow down where the time is being consumed.
  13. unfortunately, some versions of browsers (IE/Opera for one) have/had this problem. this can also occur when submitting the form via javascript. the submit button isn't a "successful" form field when the the form is submitted by means other than clicking on the submit button and the submit field isn't included in the form data. in those cases where you need to identify which of multiple possible forms was submitted, using a hidden form field or testing for a field name that is always submitted addresses a type = submit field that may not be sent with the form data. also, unfortunately, the OP's code in this thread was using name='login' in the form, but was testing for isset($_POST['submit']) in the php code.
  14. it's not really possible to program by randomly putting things into your code. you must know what each line of code does, so you will know how it contributes to what you are trying to accomplish, know if it even belongs in the program, and know where it belongs in the flow of the program logic. the code you posted in reply #3, was using the CheckPassword() method in the correct logical location and you were including the PasswordHash class definition in the correct logical location, relative to trying to use it. you were however missing the line that created an instance of the PasswordHash class and you were using the wrong php variable as a parameter when you called the CheckPassword() method. everything you changed after that point, from where you added it, to adding a call to the HashPassword() method (hashing the password is done when the password was stored during registration, not when trying to log in) makes it appear that you are not even looking at what you are doing, similar to trying to put together a jig-saw puzzle without looking at the picture on the box and what portion of the picture is on the piece you are trying to find a location for. so, best advice, slow down, actually learn what each statement does, look at and think about what your code is doing at each step, so that you can put in other statements at the correct place so that they will have meaning for what you are doing.
  15. the correct logic to check the password is to call the CheckPassword() method (after you have created an instance of the PasswordHash class in $hash_obj), with the correct values. in your code that had/has this call, the second parameter you are using was/is $stored_hash. however, there is no variable $stored_hash in your code. your code is using $password_hash. beyond this, due to the number of changes you have made to the code, if you cannot get it to work, post your current code. btw - php has built in password hashing functions - password_hash()/password_verify(), that you can/should use instead.
  16. have you done any debugging to make sure that the $_FILES data is what you expect? also, there are at least three problems with what you are showing use in that code - 1) you should validate that input data exists and is what you expect before using that data. your code should never get to the point of running a query unless you know you should be running that query. 2) isset($_FILES["fileField"]) that $_FILES element will be set, even if there is no valid uploaded file. if a user doesn't select a file and likely for some of the possible upload errors, what you are testing in the isset() statement can be true, but the ['name'] element that you are using can be empty. this is actually related to the above item. you shouldn't be testing for data at the point of using it in a query. by the time you get to the point of forming and running the query, you should have already determined if there's data present. 3) "all other text fields update fine". unless you removed lines of code from what you posted, that implies you are repeating similar code for each field and are running a separate query for each field. that is a database killer. you should update all the fields using one query (note: if none of the values being updated have changed, mysql doesn't actually update the record.)
  17. without knowing where and how this is being produced, where and how you are viewing the incorrect value, and what sort of processing might be occurring between those two points, it's impossible to tell. could be due to a programming problem changing the value or copy/pasting part for that value from somewhere that has some character encoding that looked correct where it was copied from, but isn't actually the charters they appeared to be or some type of character encoding issue with the method you are using to view the value.
  18. since the output, that's causing the problem, is occurring on line 1 of the file and the only php code on that line is the php tag, you either have something in the file before the php tag or your file has been saved with utf-8 encoding and the BOM (Byte Order Mark) characters by your editor. insure that there's no characters before the first php tag and insure that your editor is saving the file without the BOM characters.
  19. this is some confusing code and probably doesn't work because the output being produced is not valid. the markup you are producing, particularly the javascript, is being repeated for each main row you are looping over. you need to separate the concerns/responsibilities in the code. the data retrieval logic should all be together, come before any markup, not contain any html/javascript/css markup, and just store the retrieved data in a php array. the code building the page, starting with the <!DOCTYPE ... tag, should just take the data from the data retrieval logic and loop over it as needed to build the sections/views on the page. the things that only exist ONCE in the markup, such as the jquery javascript <script> ...</script> tags, should not be inside of any loop. next, you should never run database queries inside of loops. the data you are retrieving is related, as in the R in RDBMS. the correct way of retrieving related data is to run one query that JOINs the tables to retrieve all the related information at once. and here's the most confusing part from your code (we only see what you post, so it must clearly tell us the story of what you are doing), you are looping over the result from each of the queries, but i suspect that each query, except for the main one, only matches one row? OR can there be multiple timesheets per workorder, based on what appears to be a variable for totaling the time? you should also be using css instead of inline styling and the msyql_ database functions are obsolete and will be removed from php in the not to distant future. you should be switching to either the msyqli_ or PDO database library of functions (having all your database retrieval logic together, on in your case, where you should only have one query, will make switching to a different set of database functions easier.) in short - run one query that gets the data you want, retrieve and store that data into an array, then, in the code that's producing the page, loop over the data, building the markup needed to display that data. this will reduce all your code, make it easier to debug each concern/responsibility (which makes it easier for us to produce test data if we need to run your code to help with it), and make it clearer to us what you are doing.
  20. in programming, a simple typo in a variable name, can cause your program logic to loop forever, because the code is no longer testing the correct variable. if you cannot find the problem in your code that is causing this, you will need to post the code that reproduces the problem.
  21. any particular web hosting may have restrictions on how to send email through their mail server (and may not even supply a sending mail server, your friend that can send emails may be sending them through some other mail server.) what is your free web host's name and have you checked their FAQ section on sending emails? common problems would be a mail server that's set up to require smtp authentication or problems with the From: address (or lack of) being used in the email headers.
  22. some comments - 1) ALL the form processing code needs to be inside of a logic test that has checked if a form was submitted. if a form was submitted, all the form fields (except for unchecked checkboxes and un-selected radio-buttons) will be set, even if they are empty. 2) you should trim() all inputs before validating them. 3) you should validate all inputs to insure that required fields are not empty and that anything in a field is of an expected format and is not nefarious. 4) any user input that's put into the message body should be passed through htmlentities() (even if you are sending a plain text email, since email clients can be configured to view the email as html even if it is not) so that should you be using a browser as the email client to view the email, any javascript that was in the submitted message won't be rendered. 5) the email address that's being put into the mail header MUST be validated to insure in only contains an email address and nothing else that could be used to inject other headers into the email. 6) you should produce a specific error messages for each input that didn't match the expected format to tell the visitor what they did that was wrong, so that they can correct the problem. validation errors should be added as elements to a php array variable. 7) you should re-populate the form fields with any previously entered data so that the visitor doesn't have to re-type the values. doing this and displaying any validation errors is easiest if you have one page that contains the form and the form processing code. the email is not being sent from the person who submitted the form. it is being sent from a mail server at the web host where the form was submitted to. the From: address in the mail header is either an email address with a domain name that can be matched to the ip address where the sending mail server is at or if the domain doesn't match where the sending mail server is at, that there's an SPF DNS zone record at the domain being used in the from email address that says your sending mail server is authorized to send email for that domain. 9) you must test the value returned by the mail() function to determine if the sending mail server even accepted the email (it still may not be sent and the receiving mail server may not accept it) before displaying any sort of success message. 10) and because getting email to actually be sent is something of a problem due to all the spam abuse, you should log the relevant information about each form submission so that you know what's going on.
  23. you should be using a database, but lacking that, here's an example showing a general purpose/data driven way of doing this common assignment - <?php // define constants for day names to make reading and writing code easier define('SUN',0); define('MON',1); define('TUE',2); define('WED',3); define('THU',4); define('FRI',5); define('SAT',6); // domain root relative path to where images are at $path = '/images/shows/'; // data - days (one or an array), start-time (inclusive), end-time (exclusive), image $a[] = array(SUN,'00:00','01:00','MensHealth'); //1 $a[] = array(SUN,'01:00','02:00','AlanTaylor'); //1 $a[] = array(SUN,'02:00','05:00','HughHewitt'); //1 (this image used later w/different hours) $a[] = array(range(SUN,SAT),'05:00','10:00','RedEyeRadio'); //7 $a[] = array(SUN,'10:00','11:00','MomTalk'); //1 $a[] = array(SUN,'11:00','12:00','GoodParenting'); //1 $a[] = array(SUN,'12:00','14:00','PetShow'); //1 $a[] = array(SUN,'14:00','15:00','GardenRebel'); //1 $a[] = array(SUN,'15:00','16:00','WorkingMother'); //1 $a[] = array(SUN,'16:00','17:00','WhatsCooking'); //1 $a[] = array(SUN,'17:00','18:00','HomeWizards'); //1 $a[] = array(SUN,'18:00','19:00','DougStephan'); //1 $a[] = array(SUN,'19:00','20:00','Finance'); //1 $a[] = array(SUN,'20:00','21:00','PopularScience'); //1 $a[] = array(SUN,'21:00','22:00','ABCRadio'); //1 $a[] = array(SUN,'22:00','24:00','Medicine'); //1 $a[] = array(MON,'00:00','03:00','ArmedAmerica'); //1 $a[] = array(MON,'03:00','05:00','HughHewitt'); //1 $a[] = array(range(MON,FRI),'10:00','13:00','BobRick'); //5 $a[] = array(range(MON,FRI),'13:00','16:00','DougStephan'); //5 $a[] = array(range(MON,FRI),'16:00','19:00','MariluHenner'); //5 $a[] = array(range(MON,FRI),'19:00','20:00','DebbieNigro'); //5 $a[] = array(range(MON,FRI),'20:00','22:00','DaveRamsey'); //5 $a[] = array(range(MON,FRI),'22:00','24:00','JoyBrowne'); //5 $a[] = array(range(TUE,SAT),'00:00','01:00','ShannonJoy'); //5 $a[] = array(range(TUE,SAT),'01:00','02:00','BillNojay'); //5 $a[] = array(range(TUE,SAT),'02:00','05:00','DennisPrager'); //5 $a[] = array(SAT,'10:00','12:00','HaidtReport'); //1 $a[] = array(SAT,'12:00','13:00','ABCNews'); //1 $a[] = array(SAT,'13:00','16:00','GarySullivan'); //1 $a[] = array(SAT,'16:00','18:00','PopularTech'); //1 $a[] = array(SAT,'18:00','19:00','WhatWorks'); //1 $a[] = array(SAT,'19:00','21:00','JillMoney'); //1 $a[] = array(SAT,'21:00','23:00','YouManual'); //1 $a[] = array(SAT,'23:00','24:00','MadeAmerica'); //1 $hm = date('H:i'); //set variable the hour:minute HH:MM of the day. $d = date('w'); //set variable $d to the day of the week. // find the image that matches the day/time $img = ''; foreach($a as $e){ if(((is_array($e[0]) && in_array($d,$e[0])) || (!is_array($e[0]) && $d == $e[0])) && $hm >= $e[1] && $hm < $e[2] ){ $img = $e[3]; break; } } if($img == ''){ echo 'no matching program found'; } else { ?> <img src="<?php echo $path.$img.'.jpg'; ?>"> <?php }
  24. web servers can handle several 100's of requests per minute. just using the timer/ajax-request method will work for a casual chat system. you would want to make each request/response as brief as possible and make the server side code as efficient as possible, off loading as much formatting/processing onto the client as possible. the client side request, which should be a GET request btw, would include the id of the last message that has been displayed for that user. the server would just query for and retrieve any new messages with id's greater than that id. at a minimum, the message id column in the database table would be indexed. if there's no new messages, the server should return a simple status value to tell the client side code it doesn't need to do anything, perhaps just an empty json encoded array. if there are new messages, just return the raw message data, leave any formatting/display to the client side code. make sure that the database server has query caching turned on as well. when data in the database table hasn't changed, the same database query being made from multiple clients will return data from the cache rather than retrieving it from the database table. you can have 100's of clients all waiting for a new message and they will keep getting the result from the cache that there's no new messages until there actually is one that was stored into the database table, altering it, which causes the cache to be cleared so that it will then cache the new message(s) for the next series of update requests.
  25. in the context of a monthly calendar, what do you want to display? displaying every open time slot for even one trainer (what if you have 20 trainers) would not be piratical. your monthly calendar could at best show a clickable 'event' on the days that have available bookings (and a non-clickable, 'full' listing for days that have no open time slots), either just one event total, if any of the selected/filtered trainers have an opening, or one event for each selected/filtered trainer that has an opening on that date, with a hoover/pop-open tool or a link that gives you a view/page that consists of the booking grid with the open time slots for the clicked on date. a monthly calender could be used for the appointment confirmation. you could display an 'event' on any days that have any un-confirmed appointment(s), for the currently logged in trainer. clicking on the 'event' would take that trainer to a grid of un-confirmed appointments that can then be reviewed and approved. assuming that a trainer would have the need to cancel an appointment, you would instead display an 'event' for all days that the trainer is available. clicking on any day would take the trainer to a grid that shows un-approved and approved appointments on that day with choices to approve/cancel each appointment.
×
×
  • 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.