Jump to content

mac_gyver

Staff Alumni
  • Content count

    4,197
  • Joined

  • Last visited

  • Days Won

    101

mac_gyver last won the day on September 27

mac_gyver had the most liked content!

Community Reputation

428 Excellent

About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

146,118 profile views
  1. mac_gyver

    Query Statement Help

    mysqli_fetch_fields() doesn't do what you think. it fetches information about the fields. it doesn't fetch data and you would have been getting php undefined index errors from your code to alert you to the problem. you need to ALWAYS have php's error_reporting set to E_ALL and when learning, developing, and debugging code, have display_errors set to ON and when on a live/public server have display_errors set to OFF and log_errors set to ON. you would want to use mysqli_fetch_assoc() to fetch the data.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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().
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×

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.