Jump to content


Staff Alumni
  • Content Count

  • Joined

  • Days Won


mac_gyver last won the day on June 17

mac_gyver had the most liked content!

Community Reputation

474 Excellent


About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

148,198 profile views
  1. what does var_dump($row); show? btw - you should INSERT a new row for every transaction that affects a user's account balance, not update the value in a column. you currently don't have an 'audit trail' to detect if a programming mistake, duplicate form submission, or nefarious activity has altered the value. your current code will also update the value to the wrong amount if there are concurrent instances of your script being executed since the 'last' update query to get executed will replace any previously updated value.
  2. code that unconditionally (always) outputs the raw database statement errors for the connection, query, prepare, and execute statements, only helps hackers when they intentionally trigger errors, since these errors contain things like the database hostname/ip address, database username, if a password is being used or not, part of the sql syntax, and web server path information. the only time you should output the raw database statement errors is when learning, developing, or debugging code/query(ies) and you are viewing the site as the developer/programmer. at all other times, you should log these errors. the simple way of doing this is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any discrete error handling logic, since it doesn't add any value for a legitimate visitor to your site, and it will no longer get executed when there is an error (execution transfers to the nearest exception handler for the type of exception or to php if there is none.) the line that Barand posted enables exceptions for errors for the mysqli extension.
  3. the main reason requinix stated that is because you are not validating input data before using it (which i have mentioned doing multiple times in this thread.) someone can cause your code to execute any php function, like phpinfo(), by simply setting $_GET['form_type'] to phpinfo when they request your page. do you really want someone to be able to see the phpinfo output from your site or execute any php function? your code needs to have direct, positive control over what gets executed on any page request.
  4. that's not what i posted. php's short opening php tag may not be enabled and shouldn't be used anyway. what does the 'view source' in your browser of the main page show?
  5. you still have not done the most important thing that has been suggested, repeatedly. validating all inputs that your page expects and setting up/displaying user error messages for each validation error. this will get your code to either work or it will tell you why it isn't working. no. your queries also expect $_POST["first_name"] and $_POST["marital_status"] as inputs, all this extra code using session variables, repeated database connections, function definitions around parts of your main code, function definitions inside of other function definitions, ... is unnecessary clutter. i recommend that you start over, adding and testing one feature at a time. 1. produce a get method search form, that's 'sticky' (repopulate the field values with any existing submitted values), that sets up/displays user error messages for each required input that doesn't exist. 2. once you get that to work, add the two queries and the logic needed for pagination, that use those required inputs. another recommend to add to the list is to use an array to hold user/validation error messages, using the input/field name as the array index. this array is also an error flag. if the array is empty, there are no errors and you can use the input data. if the array is not empty, there are errors. you can test/display the content of this array at the appropriate point in the html document.
  6. use 'require' for things your code must have for it to work. this will stop code execution if the required file could not be found and prevent follow-on errors in code trying to use things that don't exist. do you have an opening <?php tag in the file? use a .php extension for this file. by using .inc for the extension, anyone can browse to the file and get the raw php code in it, exposing your database connection credentials. by using a .php extension, the php code would instead be executed if someone browsed to it and they cannot see the raw php code.
  7. if you layout the code on your page in the following general order, it will be much easier to design, write, test, and debug your code/query(ies) - initialization - define, require, create, ... things your page needs, such as the session_start() statement, a database connection, configuration values, ... post method form processing code - a post method form should be used for things that create/update data on the server or perform an action such as sending an email. get method business logic - get/create data needed to display the dynamic content on the web page. html document/template - using simple php code or an actual template system, produce the actual html document, using the data produced from the above sections of code. you would have validation logic in both items #2 and #3. next, you don't need to understand OOP in order to use existing OOP classes. if you switch to the much simpler and more consistent PDO database extension, over half of the database related statements will go away.
  8. i just realized why you are not getting any helpful php errors at the point of the problem. it's because you are using the ridiculous mysqli extension. the following is using a reference to the variables and if they don't exist, there's no php undefined variable/index error when the variables are evaluated. so, i'll repeat this - your search form should use method='get' and if your code was validating the inputs before using them, you would know why your code is not working,
  9. the most immediate problem is you have a logic 'hole' in the username/password check, where not all possibilities are addressed. when you use negative logic, you must complement both the conditional comparison in each term and the logic combining the terms. the complement of - if(a == b && c == d) is if(a != b || c != d). it is not if(a != b && c != d), in general, you should avoid using negative logic. you also need to use php's password_hash() when registering/storing the initial submitted password and use password_verify() when testing if a submitted password matches the saved hashed value. also, don't use a loop to fetch the data from a query that will at most match one row. just directly fetch/test the result from the query. lastly, the recommendations given in your last thread, less the ones that were specific to an INSERT query, apply to what you are currently doing. using those recommendations will result in the least amount of code/variables.
  10. how about the display_errors setting? any of php's error related settings should be in the php.ini on your system, so that they can be changed at a single point and don't clutter up your code.
  11. the pagination after page 1 is not working because you are not propagating the get parameters that your code expects, nor are you validating those inputs, so your code is not telling you what is wrong (you are probably getting php errors though.) you must validate all inputs to a page before using them and any 'required' inputs should cause some type of user error message to be displayed if they are not present. when you get to the point of producing pagination links, you should include any existing get parameters by starting with a copy of the $_GET array, modify the page element in that array, then use http_build_query() to produce the query string part of the url. you should also be passing any search term/filters as get parameters.
  12. the mistake is probably at the binding/execution for the insert query. i won't mention what i saw because it is more important that you develop simple coding that will either work or it will tell you (display/log) why it isn't working. because you have no useful error handling for all the database statements that can fail (connection, query, prepare, and execute) and probably don't have php's error related settings set up to get php to help you, you are not getting any feedback that would allow you to solve the problem yourself. start by doing what was written here - https://forums.phpfreaks.com/topic/310992-mysqli-count-query-prepared-statements/?tab=comments#comment-1579137 next, this code is full of unnecessary things that don't add any value to what you are trying to accomplish (a form and form processing code that inserts data into a database table.) some recommendations that will result in simple code - put the form and the form processing code on the same page, with the form processing code above the start of the html document. this will allow you to directly display any validation errors and re-populate the form field values with the submitted data so that the user doesn't need to keep reentering the same things over and over. forget about that dumb test_input() function you found or were given. the only thing it is doing that's appropriate is trimming the data. everything else is either wrong for the context or needs to be conditionally applied. you should not test if the submit button isset. there are cases where it won't be. you should instead test if a post method form was submitted. don't write out line after line of code for each form field. just keep the set of form data as an array, then operate on elements in the array in the rest of the code. this will lead to dynamically validating and processing the submitted form data, further simplifying the code. validate all inputs separately, setting up a unique and helpful error message for each validation error, storing the validation errors in an array, using the form field name as the array index. this array is also an error flag. if there are no errors, it will be empty, and you can use the submitted form data. you can also test/display the contents of this array at the appropriate location in the html document. as has already been stated, your database definition must enforce unique entries. since it must do this to prevent duplicates, there's no good reason for the extra code/query to try to select the data first. just attempt to insert it, then detect if a duplicate key error occurred. this is also mentioned at the linked to forum reply. if you switch to the much simpler and more consistent PDO extension, over half of the database related statements will go away, which will eliminate the mistake i saw, because you don't have to produce multiple statements with things in them for each column in a query. in most cases, you don't need to close prepared statements or close database connections, since php will automatically do this for you when you script ends.
  13. there are two main points for using a prepared query - to prevent sql special character in external, unknown, dynamic data values from breaking the sql query syntax. to speed up the overall process when executing the same query more than once within an instance of your script, since the communication and execution planning phase for the sql query statement is performed only once. if you are not doing either of these, don't use a papered query. when learning, developing, and debugging code/queries, you should display all php errors (when on a live/public server, you should log all php errors.) set php's error_reporting to E_ALL and display_errors to ON, in the php.ini on your system. if you put these settings into your code, parse/syntax errors wont be reported (the case of the missing } ) since your code never runs to change the settings for this type of error. putting these settings into your code also means more work for you later when you must find and change/remove them when moving the code to a live/public server. you also need error handling for all statements that can fail. for database statements, the easiest way of adding error handling, without adding logic at each statement that can fail (connection, query, prepare, and execute) is to use exceptions and in most cases let php catch the exception where it will use its error related settings (see above) to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) the exception to this rule is when inserting/updating duplicate or out of range user submitted values. in this case your code should catch the exception, detect if the error number is for something that your code is designed to handle, then setup a message for the user telling them what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it. to enable exceptions for errors for the mysqli extension, add the following line of code before the point where you make the database connection, then remove any existing error handling logic, since it will no longer be executed if there is an error - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
  14. for this part of your question, it depends on the operating system. for a case-insensitive operating system, such as Windows, Hello.php and hello.php are the same. for a case-sensitive operating system, such as lunix, those are two different file names.
  15. the warnings and notices are from php. they have nothing to do with with any framework the site is using for the presentation of information. the glob() is not matching any files and your code should test ( !empty($var) would work) before trying to access any of the results and output an appropriate message if no matching file was found. as to why the glob calls are failing, it would either be due to a problem with the spelling, capitalization, actual path being used, or there are no matching files inside the folders.
  • 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.