Jump to content

Recommended Posts

Hi, I am using XAMPP and trying to put up a simple form. The index.php is

<form action='connect.php' method="POST">


<label for="user">Name: </label>


<input type='text' name='name' id="name" required/>


<br><br>


<label for="email">Email: </label>


<input type='email' name='email' id="email" required/>

<br><br>


<label for="phone">Phone: </label>


<input type='text' name='phone' id="phone" required/>

<br><br>


<input type='submit' name='submit' id='submit' />


</form>

 

The connect.php is

 

<?php
  if($_SERVER['REQUEST_METHOD'] == 'POST' && isset($_POST['submit'])) {
  
      echo 'submit button clicked';

     $conn= mysqli_connect('localhost', 'root', '', 'my_software') or die("Connection Failed:" .mysqli_connect_error());

     echo 'no connection error';


     if(isset($_POST['name']) && isset($_POST['email']) && isset($_POST['phone'])) {
     
         $name= $_POST['name'];
         $email= $_POST['email'];
         $phone= $_POST['phone'];

         echo 'Upto SQL';
         
         $sql= "INSERT INTO 'user' ('name', 'email', 'phone') VALUES ('$name', '$email', '$phone')";

         echo 'SQL Run';
         
         $query = mysqli_query($conn,$sql);

         echo 'query run';
         
         if($query) {
         
           echo 'Entry Successful';
         
         } else {
         
          
           echo 'Error, Entry Failed';    
     
     }
     
  
  }

}
  
  
  ?>

There was no addition to the database. So I used echo to find what or where it is going wrong. It prints up to " SQL Run ".  But still, no input to the database I created using phpMyAdmin or any error message indicating where I am doing it all wrong. Any help would be great.

Link to comment
https://forums.phpfreaks.com/topic/317588-simple-php-form-but-something-is-wrong/
Share on other sites

Try changing

$sql= "INSERT INTO 'user' ('name', 'email', 'phone') VALUES ('$name', '$email', '$phone')";

to

$sql= "INSERT INTO `user` (`name`, `email`, `phone`) VALUES ('$name', '$email', '$phone')";

Backticks, not single quotes (but unnecessary they are not reserved words)

  • Like 1

P.S.

You should be using a prepared statement to avoid SQL injection

$stmt = $conn->prepare("INSERT INTO user (name, email, phone) VALUES (?, ?, ?);
$stmt->bind_param('sss', $name, $email, $phone);
$stmt->execute();

And, to make life easier for yourself, switch to PDO instead of mysqli.

  • Like 1
2 hours ago, Dilip said:

It prints up to " SQL Run ".

this is because as of php8 the mysqli (and PDO) extension uses exceptions for all database statement errors, by default, and execution transferred to the nearest correct type of exception handling (try/catch logic) in your code or to php's exception handling if there is no correct type of exception handling in your code, and all your code after the point where an exception occurred is not executed.

a great point of using exceptions is that your main/inline code only 'sees' error free execution. if execution continues past a statement that throws an exception, you know that there was no error, without needing logic in your code to test if there was or was not an error. this lets you eliminate all the existing conditional logic in your code testing for connection and query errors, since it won't ever get executed upon an error, simplifying the code.

because you didn't get any error indication at all, that means that php's error related settings are not set up on your system so that php will help you by reporting and displaying all the errors it detects. php's error_reporting should always be set to E_ALL and when learning, developing, and debugging code/query(ies), display_errors should be set to ON. when running code on a live/public server, display_errors should be set to OFF and log_errors should be set to ON. these settings should be in the php.ini on your system so that they can be set or changed at a single point. stop and start your web server to get any changes to the php.ini to take effect and check using a phpinfo() statement in a .php script file that the settings actually go changed to the desired values.

the only time you should catch and handle a database exception in your code is for user recoverable errors, such as when inserting/updating duplicate user submitted data, which is something you are/should be doing. at a minimum, the email database column should be defined as a unique index. you would then have exception try/catch logic in your code around at least the execute() statement, check in the catch block if the error number is for a duplicate index error, and setup a message for the user that the email is already in use. for all other error numbers, just re-throw the exception and let php handle it.

and if that wasn't enough, here's a list of practices, most of which will simplify the code -

  1. the form and form processing code should be on the same page. the code for any page should be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document.
  2. the post method form processing code should only test if the request method == 'POST'. this is because there are cases where the submit button won't be set.
  3. you should keep the form data as a set, in a php array variable, then operate on elements in this array variable throughout the rest of the code, i.e. don't write out line after line of code that copies variables to other variables for nothing.
  4. you should trim all user entered data, mainly so that you can detect if it was all white-space characters, before validating it. after you do item #3 on this list, you can trim all the data using one single line of code.
  5. you should validate all input data, on the server, before using it, storing user/validation errors in an array using the field name as the main array index.
  6. except for unchecked checkbox/radio fields, all form fields will be set once the form has been submitted. there's no good reason to have isset() statements for always-set fields, and in fact doing so hides typo mistakes.
  7. as @Barand has already pointed out, you should be using a prepared query and switch to the much simpler and more modern PDO extension.
  8. after successfully processing the form data, you should execute a redirect to the exact same URL of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data should that page get reloaded or browsed away from and back to.
  9. if you want to display a one-time success message, store it in a session  variable, then test, display, and clear that session variable at the appropriate location in the html document.
  10. to get a form to submit to the same page it is on, leave out the entire action attribute.
  11. if you put the closing </label> tag after the form field it corresponds to, you can leave out the for and matching id attributes, simplifying the code and eliminate a source of typos. in the name form field, your for attribute doesn't match the id attribute.
  12. the closing / in tags is no longer used. you need to validate the resulting web pages at validator.w3.org
  13. the form should be 'sticky' and repopulate the form fields with any existing values/choices so that the user doesn't need to keep reentering data over and over upon an error.
  14. any dynamic value you output in a html context should have htmlentities() applied to it to help prevent cross site scripting.
  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • 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.