Jump to content

mac_gyver

Staff Alumni
  • Content Count

    4,271
  • Joined

  • Last visited

  • Days Won

    109

Everything posted by mac_gyver

  1. mac_gyver

    Query Statement Help

    and did you reload the page in your browser so that the change would take effect? i just tried your form page and it displayed the value that i entered in the form in the sql query statement. next, you should NOT put external/unknown data directly into an sql query statement. you should use a prepared query, with a place-holder in the sql query, then supply the actual data when the query gets executed.
  2. mac_gyver

    Query Statement Help

    your form is using method='get'. your php code is trying to use post data. if your code had checked the value in $refcode before using it, you would have already known this (it should be a null since the input variable is not set.)
  3. mac_gyver

    login form not working

    password_hash() is used when you store the hashed password, during registration. to test if the entered password corresponds to the hashed value, you must retrieve the hashed value from the database table and use password_verify() also, the only thing you should store in the session variable is the user's id, from an auto-increment column in your users table. to get any other user information, query for and retrieve it based on the user id.
  4. mac_gyver

    Update record via form, then go to next record

    this sounds like a typical CRUD assignment and literally 'go to the next record' isn't exactly what you want because you would not be frequently entering/editing all the records in turn. don't you really want to be able to enter/edit the email address for specific/selected record(s) and you want to be able to easily go to or select the records where an email address needs to be entered/edited? if so, what you need to do is come up with a User Interface (UI) that supports what you are doing. you can do this at least four different ways - 1) display a page of the records inside a single form, where you would enter/edit any amount of email addresses at one time, then submit the form and UPDATE all the records. an enhancement to this would be to either have a check-box or use javascript to detect a change in the email field and set a value in a hidden field, for each record that indicates that the record has been changed. the form processing code in this case would use the check-box/hidden field and only UPDATE the records that have been changed. 2) display a page of the records with each as a separate form. you would enter/edit an email address and click the submit button for that record. the page would re-display after updating that record and you can enter/edit more email addresses. 3) display a page of the records with an edit link next to each one, containing the record id. when the edit link is clicked, you would retrieve the data for that record and populate a form with the existing data. when the form is submitted, you would UPDATE just the record for that id. 4) a mix of method #1 and #3. display a page of the records with an edit check-box next to each one, inside of a single form. check the boxes for the records you want to edit and submit the form. the next page would retrieve the data for all the records that were checked and dynamically output a single form with a field for each record. the single form would be submitted and processed as in method #1. the method you choose depends on how many email addresses would typically be entered/edited at one time, to provide the simplest user interface (fewest number of clicks with the smallest chance of putting data into the wrong record), and per what your assignment is to use. method #2 is probably the best from a user standpoint - identify and click on a record you want to edit, enter/edit just one email address at a time, click the submit button next to the email form field, deal with any errors from that submission, repeat for the next email address to be entered/edited.
  5. mac_gyver

    apply money_format to multiple values

    your 'set' of prices should be in an array (arrays are for sets of things.) you can then write a call-back function containing the money_format() statement and apply it to every element in the array by calling array_map().
  6. mac_gyver

    fetch_assoc Select Option value filter column

    i recommend that you review the replies you have received in the thread, particularly this one - https://forums.phpfreaks.com/topic/307650-fetch_assoc-select-option-value-filter-column/?tab=comments#comment-1560580 it lists two security holes with the way you are doing this now and suggests a simple and secure method of doing this so that it works.
  7. mac_gyver

    PDO Update

    there's no need to be editing your code when you switch the environment it runs in. if you remove the try/catch logic you have now, and let php catch the exception, it will use its error_reporting, display_errors, and log_errors settings to control what happens with the actual error information. when learning, developing, and debugging you would display all errors. when on a live/public server, you would log all errors. the only time your code should catch and handle a database exception is if your code needs to detect and handle the insertion/update of duplicate data, which is a recoverable application error, not a fatal database error.
  8. mac_gyver

    PHP Update Prepared Statement Script Help

    you have a php syntax error. the try/catch syntax is incomplete. you are not seeing any errors since your code never runs when there is a php syntax error. you should set the error_reporting/display_errors setting in the php.ini on your system so that php will report and display ALL the errors it detects. in most cases, you should not catch exceptions in your code (only when detecting duplicate data being inserted/updated.) you should normally let php catch and handle any exception. next, the variables being used in the connection don't appear to exist, the PDO extension doesn't have a bind_param() method (it does have a bindParam() method), the two variables you are binding don't appear to exist, and instead of binding input data,you should just supply it as an array in the execute() method call. also, if there are no affected rows, that's not a query error and using $conn->error, which isn't a PDO property anyway, won't contain any useful information. if there is a query error, an exception will be thrown and the exception handler will be executed.
  9. mac_gyver

    Using Post variables in SQL Query for Azure SQL db

    the biggest issues with your code (some of which have already been mentioned) are - 1) all the form processing code isn't inside the conditional statement detecting if a form has been submitted, so the part where the sql query is at can be executed when there is no post data to use. all the form processing code needs to be inside the conditional statement and if this is the only form processing code, you should instead detect if $_SERVER['REQUEST_METHOD'] == 'POST' 2) sqlsrv_errors() returns an array. you cannot echo an array. to dump the errors for debugging purposes, either use var_dump() or print_r(). also, your code needs only execute the rest of the database code if $getResults is a true value. the rest of the errors are 'follow on' errors because the query failed. you should also have some error handling for the database connection so that you only execute the query if the connection worked. 3) after you have detected that the form has been submitted, you must validate all input data before using it. this is doubly important if the form data specifies column/table names for an sql query statement, since no amount of escaping of the values (it's not string data and it's not being used in a string context) or using a prepared query (you can only supply data values, not column/table names via prepared query place-holders) will protect against sql injection. for column/table names, you must either validate that each value is only and exactly a permitted column or table name or you must use some sort of id mapping, where you submit id values instead that get mapped to column/table names internally in the code so that only id values that have a valid mapping can be used.
  10. mac_gyver

    fetch_assoc Select Option value filter column

    your code should pass a minimum of information through the form, because you must validate ALL form/external data before using it. your current method also exposes all the users email addresses and probably allows someone to submit any email address to your form processing code and it will get used as the email address to send to. you should only pass the user_id through the form, then query for the corresponding email address in the form processing code. also, any data you store or update based on the form data only needs the user_id.
  11. mac_gyver

    PHP Insert code not working

    that's because you are unconditionally assigning that string to $result and it comes after the assignment of the success message. remove the An error occurred ... line of code. the exception error handling takes care of producing a query error message.
  12. mac_gyver

    PHP Insert code not working

    not for the case of a query error. you have an exit; statement in your code and the rest of the code on the page, where you are echoing it, is never executed. you need to remove all the try/catch logic you currently have and let php catch the exceptions, where it will use its error_reporting, display_errors, and log_errors settings to control what happens with the actual error information. when learning, developing, and debugging, you should display all php errors. when on a live/public server, you should log all php errors. the only useful time you should catch and handle a pdo exception in your code is if you are detecting duplicated data being inserted/updated.
  13. mac_gyver

    Uninitialized string offset

    you can zip up your files and attach them to a post in this forum. because this is an execution/data problem, it will take having all the code that is needed to reproduce the problem. the issue is the forum software probably won't let you post 6000+ lines of code in a reply.
  14. mac_gyver

    Uninitialized string offset

    because it's an indication that the code isn't correctly handling input and it's taking up unnecessary resources detecting and handling execution errors, which a hacker can then learn information from since they are being output to the client. the OP should actually be logging all php errors when on a live/public server.
  15. mac_gyver

    Uninitialized string offset

    browsers and other http clients can/do make extra requests to pages for different reasons and your code must deal with them. it's likely that your post method form processing code is receiving a get request that it should ignore. is your code detecting that a post request was made before running any of the form processing code? as to the error you are getting, for a likely extra get request, it sounds like the variable is being initialized to an empty string or perhaps being assigned an empty string rather than having an array element added to the variable.
  16. separation of concerns. if you use his programming practice, converting the database specific code from using a non-prepared query to a prepared one, or even converting it to use the php PDO extension, is easy, because all the database specific code, that knows how to query for and retrieve data, would be groped together and be located before the start of the html document. the way to implement this separation of concerns, after you rearrange the code to get the database specific code out of the html document, is to simply fetch the data from any data retrieval query into an appropriately named php variable(s), then simply use the variables(s) (test if it's empty or not or loop over it) in the html document. once you do this, all you have to do when converting and testing the database specific code is make sure you produce the same data in the php variable(s). you won't have to touch any of the code in the html document.
  17. mac_gyver

    PDO to prevent sql injections

    the OP is also executing the prepared query, fetching all the data from it, but not using that data, then executing the query again as a non-prepared query (in the foreach ... statement). also, there's no JOIN condition in the query, so every row between the two tables (withrunontablenames) are being cross joined together, and there are no integers in php/mysql that are 100 digits in length. you are also apparently (based on the query and the code after the end of the loop) using a loop to fetch what you expect to be a single row of data. if you came up with this code from a tutorial it wasn't from ONE working tutorial. you need to make use of the php.net documentation when learning the basics. you should also disable emulated prepared queries, set the character set, and set the default fetch most to assoc when you make the connection.
  18. this is a common symptom when a redirect changes either the http vs https protocol, the www. vs no www. host-name in the url, or the path after the domain in the url and the session id cookie parameters are not set up to match variations in those values. you need to insure that the the return URL you have set up in the payment gateway matches where the session was created and/or set the session id cookie parameters to match all variations in the url, rather than just the one where the session was created. these settings are covered in the php.net documentation.
  19. mac_gyver

    5.4 to 5.6 depreciation

    there's no code posted in this thread to examine and as requinix stated, these error don't have anything to do with something not being saved.
  20. before you go beating on a keyboard adding bespoke code to handle each form field, there are some functional/user things you need to fix first. then, since you have a number form fields to process, you should be dynamically processing them, not writing out lines and lines of code that have to be changed any time you need to fix a common problem or make a change to how the code works. some problems - 1) the name of each form field must be unique (you will only receive the data from the last same-named field) and since there are selectable sections, the name should also uniquely identify the section and field within that section. 2) all the <label></label> tags need a corresponding id='...' attribute in the form field they correspond to. there's only one form field with an id attribute now and it doesn't match the for='...' attribute in its label. 3) if they are not already on the same page, both the form processing code and the form should be on the same page. this will let you display any validation errors when you re-display the form and you also need to repopulate the form field values with any previously submitted data so that the visitor doesn't need to keep selecting/reentering data, which will increase the possibility of typo mistakes. 4) except perhaps during testing when you are entering your own email address, these emails are NOT being sent from the email address that someone enters in the form. they are being sent from the mail server at your web host (even if the receiving mail server is the same one.) the From: email address must either have a domain name the directly corresponds to the sending mail server or there must be an SPF DNS zone record at the domain name being put into the From: email address that indicates your sending mail server is authorized to send email for that domain name. short-answer: the From: email address should be the same as the To: email address and you only put the entered email address into a Reply-to: mail header, after validating that it is only and exactly one correctly formatted email address. 5) all submitted values that get put into the email message need to have htmlentities() applied to them to prevent any injected css/javascript from being operated on when the message is read. even though you are not intentionally creating a html email (now), email clients can be configured to treat all emails as html. also apply htmlentities() to any data values that you output on the web page to the visitor. 6) you also need to test for errors from the mail() (or even better, one of the php mailer classes) and report success or failure of the attempt to send the email. 7) you should use an array to hold the validation errors. this will let you store each error with the corresponding field as a key. this will let you test at any point of there is or is not an error with any field and it will also let you display the errors next to the corresponding field. as to the php code you have now, one of the points of programming is to NOT develop carpal tunnel syndrome. if you find yourself writing out discrete variables, copying variables to other variables, and writing/repeating lines of code that only differ in the piece of input data they operate on, you need to find a different way of processing the data. btw - the clean_string() function in the code now is pointless, ridiculous copy/pasted code from the web. get rid if it. the way to process a set of data like this is to create a data structure (array) that defines the expected form fields, what validation tests to preform on each one, and if they are required or not. you would then loop over this defining data structure and validate each input in turn. at the end of the validation logic, you would just test if the array holding the validation errors is empty or not. if it is empty, you know all the data is valid and you can use it as input to the email logic. this kind of dynamic processing will also help simplify or eliminate logic for the different sections/subject. you can just have a field in the defining data structure with the corresponding subject value, then use the selected subject value to only operate on fields having the corresponding value. the form processing code will then just end up needing to do - 1) detect that a post method form was submitted 2) validate the input data 3) if there are no validation errors, use the input data 4) if there are validation errors, display then when you re-display the form and also repopulate the form field values.
  21. mac_gyver

    Why Mysqli_stmt_bind_result Fails ?

    the reason for the previous ban here was due to having multiple accounts. this is the UI man/unique idea man user that has gotten himself banned on several forums. which reminds me, the explanation posted above for the two queries needed to do this was already explained to you, which you acknowledged reading. if you are not going to learn from or follow the advice being given in the replies, just stop. you are wasting the forum member's time.
  22. mac_gyver

    Why Mysqli_stmt_bind_result Fails ?

    buried somewhere in that mess of mysqli code is a SELECT COUNT(*) ... query that has ORDER BY and LIMIT terms in it. this is incorrect. to do pagination, you need two similar queries. both queries need the same FROM/JOIN/WHERE/GROUP BY/HAVING terms. the query to get the count of matching rows needs to SELECT COUNT(*). the query to get the data needs to SELECT a list of column names AND have the ORDER BY and LIMIT terms. the common FROM/JOIN/WHERE/GROUP BY/HAVING syntax and corresponding data values for the queries should be built in a php variables, a string for the sql syntax and an array for the data, so that you are not repeating logic in your code, then simply use the resulting variables in both queries. you should also get the total number of pages first, then use it to test/limit the requested page number, so that you are not running the data retrieval query for a set of rows that don't exist. lastly, if you switch to the much simpler and more consistent php PDO extension, about half of the database statements will go-a-way and it will be easier to use the common sql syntax and corresponding data in the two queries needed for pagination.
  23. mac_gyver

    mysql output lost without a "word"

    do you know that for a FACT, by actually displaying the current value that php is using? the symptom of your code not producing output past a point, is usually due to a fatal runtime error or an exception that isn't being reported. depending on the context where the code is at, the error message could be inside of some html where it won't be rendered and displayed in the browser. if so, check what the 'view source' of the page shows. also, your code setting the mysqli driver error mode is using both procedural and oop notation. while it is unlikely that this is preventing those statements from actually setting the error mode, just use one set of statements. the procedural is the simpler of the two.
  24. mac_gyver

    mysql output lost without a "word"

    1) set php's error_reporting to E_ALL. it is not set to report exceptions and fatal runtime errors, you won't see anything for these type of errors. 2) on the old machine, what 'engine' were the tables using, InnoDB or MyISAM? if they were using MyISAM, then the various commit statements where having no affect and the queries were being executed in the order they are in the php code. 3) the usage of the various commit statements are causing the INSERT and UPDATE queries to not actually be executed until you call the ->commit() method. for prepared queries, i don't know what value the ->execute() calls return for INSERT/UPDATE queries since they are actually being executed later. 4) for the SELECT/INSERT/UPDATE queries for the vis_mistakes table. you can use one INSERT ... ON DUPLICATE KEY UPDATE ... query. if this is the reason you think you need to use the various commit statements, eliminate them and use this one query. 5) the 'output' you have posted doesn't seem to exactly match the posted code and it includes the UPDATE mysessda ... sql which should not be output if the code is really stopping, skipping conditional logic, or transferring execution to any exception handler/php. 6) speaking of an exception handler, since your code is throwing its own exceptions, do you have a custom exception handler and if so, what does it do for exception types that it does not handle, such as mysqli exceptions?
  25. ^^^ that's because it is a non-specific post just to get the link to show up on this site, to increase the google ad back-links.
×

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.