How should I understand these variables?

[Emil_Loenneberg SE]

So the variable $id gets its values from ID in the database right?

[Kilrah]

Not much context, but no that would come from the URL.

As in https://something.com/script.php?id=blah

[Eigenvektor]

Not a direct answer, but

mysqli_query($conn, "update `user` … where userid='$id'");

is a very bad idea, when id is a query parameter taken directly from the URL or any other kind of user input. This is a security vulnerability (SQL injection). For example with some fiddling I can do:

https://something.com/script.php?id=%27%3B+drop+database%3B

which would turn the id into '; drop database;, which would delete your database (provided the database user has permission to do so) [obligatory xkcd].

 

See: https://www.php.net/manual/en/mysqli.query.php (search for "Security warning")

[mariushm]

$_GET holds all the parameters the script receives through the URL 

 

ex script.php?id=1&test=abc  -> you'll have $_GET['id'] = 1  and $_GET['test'] = "abc"

 

$_POST holds all the parameters the script receives when a form is posted

 

ex $_POST['username']  , $_POST['userpass'] , $_POST['loginbutton']

 

<form name="myformname" method="post">
 <input type="text" name="username" value="" />
 <input type="password" name="userpass" value="" />
 <input type="submit" name="loginbutton" value="Login" />
</form>
 
 

The html code above may not be entirely correct, wrote it straight here in the comment.

 

IF you're not sure how the script will receive the parameters, use $_REQUEST which will put both $_GET and $_POST in the same bucket, same array.

 

For example, say you have a search page, where user can type a few letters to search for author names, but the page also lists the previous 20 or so searched authors or previous 20 texts entered.

 

You could have search.php?text=john  for the quick search, the links on the page, and the parameters will go in $_GET and you could have the form on the page more complex, with filters on dates, or genres of books and so on, so you'd prefer to use $_POST for that, because you may not want a mile long URL in the browser.

 

So in your code, you shouldn't mix $_GET and $_POST unless you really know what you're doing... use $_REQUEST, which should be enabled by default in the php configuration.

 

You should also make sure those values are in the array, or use a default value

 

$id = (isset($_REQUEST['id'])==true) ? $_REQUEST['id'] : 0;

 

otherwise you may get errors on the page.

 

The easiest would be to have a function which does it, which you can paste in each page, or put it in a separate php script that you then include in all your php files :

 

function _request($name,$default="") {

   return ( isset($_REQUEST[$name])==true) ? $_REQUEST[$name] : $default;

}

 

then you can simply say  $id = _request('id',0);

and you know for sure your $id variable will always be initialized with some value.

Optionally you could add a parameter to the function to check if the variable holds an integer or only digits (use ctype_digit for example if you want positive round numbers only, because "1e5" can be a valid number - using exponent, scientific notation - but you may not want to send "1e5" to the database as the query would fail) , or a string and return the value in $default if the check fails

 

 

When you create the SQL query, you don't want anything entered by the user to go directly in the query, unfiltered, because a "smart" person could actually enter a fragment of sql query that alters your string.

 

So, use built in functions that escape the input from the user , like mysqli_real_escape_string - scroll down for the procedural style functions : https://www.w3schools.com/php/func_mysqli_real_escape_string.asp

 

Another option is to use parametrized queries, where each parameter is escaped by the mysqli class so you don't have to explicitly escape them.

see mysqli_prepare and mysqli_bind_param  and mysqli_execute 

 

Here's examples, both object style and procedural : https://www.php.net/manual/en/mysqli.prepare.php

 

[Guest]

There's a lot of good information present in the other comments, so read those and take them to heart. But I'll offer some more in-depth information that hasn't been shared yet. GET and POST are HTTP requests. There are lots of them described in the HTTP specification; some other examples include PUT and DELETE. Web Developers generally use these requests for forms and more importantly for REST APIs.

 

In a REST API, the semantic meaning is very important, but for a form all that you need to know is that POST is a little more secure than GET. Below is a form that will deliver all the information using the GET method.

 

<form name="get_login_form" action="login.php" method="GET">
	<label for="username">Username: </label>
    <input type="text" id="username" name="username" placeholder="Username" required>
    
    <label for="password">Password: </label>
    <input type="password" id="password" name="password" placeholder="Password" required>
    
    <input type="submit" value="Login">
</form>

 

Unfortunately, GET presents the information in the URL, so if the user logs into the website using that form the redirect will look like login.php?username=john&password=ada. You generally do not want such sensitive information to be that easily accessible, so prefer POST on login forms. GET is generally used for less sensitive information or information you might want to share (e.g. a search term).
 

So in your case

$id = $_GET["id"];

will come from a form that submits the user ID using the GET method. So it's actually the opposite from what you ask. The id is provided to find the user in the database, rather than coming from the database.

 

Now, on to the SQL query. It will work, but don't use it. Everyone's already mentioned the possible SQL injection vector, but I'd also like to present the case for using PHP Data Objects over mysqli_*. Realistically, there isn't much of a difference between the two in terms of performance, with MySQL specific features being slightly limited in PHP Data Objects. But PDO makes up for it in ease of use and a pretty straightforward way to change database drivers (although you'll still probably run into problems). The diversity in database drivers makes PDO a very useful tool for a beginner to learn, because you can experiment with Microsoft SQL server or PostgreSQL and figure out what you prefer rather than become tied to the chains of MySQL like so many PHP developers seem to be.