Jump to content

mac_gyver

Staff Alumni
  • Content count

    4,179
  • Joined

  • Last visited

  • Days Won

    96

mac_gyver last won the day on July 24

mac_gyver had the most liked content!

Community Reputation

422 Excellent

About mac_gyver

  • Rank
    Staff Alumni

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

145,927 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. ^^^ 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.
  9. mac_gyver

    SQL execute error

    the sqlite query equivalent to SHOW COLUMNS ... is - PRAGMA table_info(table_name_here) the column name for the array_column() statement would be 'name' btw - the array_shifting to remove a column assumes the columns are defined in a particular order, that cannot be guaranteed. the PRAGMA ... query result contains a [pk] element that can be used to identify which column is defined as a primary key, assuming you actually need to remove a column from the list of columns.
  10. here's another recommendation - conditional error handling logic is usually shorter then the success logic. putting the error handling logic first, by inverting the condition being tested, gets it 'out of the way', so that the remaining logic is what deals with the successful execution path. this will eliminate the 'stray'', uncommitted else {...} blocks at the end, that are hard to match up with the corresponding if(){} statement, when the indentation isn't perfect.
  11. this code is not secure and doesn't teach good programming practices . the existence or absence of a $_GET parameter doesn't have anything to do with being logged in. some or all of the following are recommendations that have been posted in your threads on this forum - all input data needs to be separately validated before using it and you need to setup unique and helpful error messages for each validation test that fails. the session variable, that indicates being logged in or not, is one input. a specific, non-empty, integer, $_GET parameter, is another input. you need stop putting data directly into sql query statements. use prepared queries. you need to use exceptions to handle database statement errors. doing the things that are being posted in the replies in your threads will help produce more secure code (there are things beyond what has been written, such as applying htmlentities() to data being output, that we haven't even gotten around to yet), produce code that will either work or it will tell you why it isn't working, and will result in simpler code (you are still copy/pasting cluttered up code that contains unnecessary things and is missing useful features.)
  12. mac_gyver

    Form not sending email??

    your form is not a post method form, so there is no $_POST data. add method='post' to the <form ... > tag.
  13. mac_gyver

    Form not sending email??

    so, does that mean you are getting a blank page after you press the submit button? if so, what is the code for your form?
  14. any sql special characters in the data, either accidentally or intentionally, that's being put directly into the sql query statement can break the sql query syntax. for a stored procedure call, i don't know if you can do anything nefarious by injecting sql, but you can still trigger database errors. a prepared query is the simplest way of preventing sql special characters from breaking the sql query syntax, regardless of using a stored procedure or not.
  15. your code contains an else { return $connection; } statement as part of the connection logic, so, none of the code past that point is being executed. your main code should be responsible for making the database connection. you should use dependency injection to supply the connection to the agmInfo class, when you make an instance of that class. in order to prevent sql injection, you should use a prepared query, with place-holders in the sql query statement for each data value, then supply the actual data when you execute the query.
×

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.