As currently testing this, I only validate the field as follows which will be changed:
$input_description = trim($_POST["description"]);
In edit mode, I can see the field content with no problem.
One particular field does not update because of the html tags.
The field contains the following:
<p><img style="float: left; margin-right: 10px; margin-bottom: 5px; border: 1px solid black;" title="The castle of Bruntzi in Nafplio" src="star_thumbnails/nafplio18_20080808203723.jpg" alt="The castle of Bruntzi" width="155" height="116" /> Nafplio is one of my favorite places on the mainland area known as the Peloponnese in Greece.</p>
Doesnât seem to make sense. Where is $description set?
And really I donât see the purpose in that second assignment anyway.
What error handling do you have for this?
SamA74,
So, letâs forget that 7.4 is outdated, this is what I am testing on using wamp. $description is attained from the db table, then displays correctly as the field shown here.
I expected that changes to the field would be saved but they are not.
The following should save the changes but the result is the same as shown above.
$sql = "UPDATE gallery_catg SET description=? WHERE cid=?";
if($stmt = $mysqli->prepare($sql)){
$stmt->bind_param("is", $param_cid, $param_description);
$status = $stmt->execute();
My question is, should I be using htmlspecialchars during the edit input:
The prepared query bound parameter order is incorrect. The first place-holder in the query is for the description, the second place-holder is for the cid. The order in the type string parameter and the bound variables in the bind_param() statement must match the usage in the queryâŚ
No. Htmlentities/htmlspecialchars are output functions. They are used on dynamic values being output in a html context, right before they are output.
No. The browser (should) submit the literal values, not the Htmlentities/htmlspecialchars values.
You should be using exceptions (this is the default setting now in php8+) for errors for database statements that can fail - connection, query, exec, prepare, and execute. With exceptions, you donât need any discrete conditional logic to test if a statement failed or not because execution transfers to the nearest correct type of exception handler, or to php if there is no correct type of exception handler in your code, upon an error. If execution continues past a statement that can throw an exception, you know that there was no error, without needing any conditional logic, simplifying the code.
If youâre using unnamed parameters (?), they have to be specified in the correct order to match the occurrence of the ? in the query string.
PHP has no way of associating a value to a replacement otherwise; it doesnt have a concept for the schema of the table. So it just replaces first ? with first value; second ? with second value, etc. (Thereâs a bit more to it because of parameterization, but⌠essentially.)
You asked this question. I answered this question. Putting the fields in the wrong order wont update them correctly, if at all.
Your original post doesnt show us the value of $sql, so noone can tell you if that query will execute correctly, because you havent shown us that query.
prepare wont catch errors like âYouâre trying to stuff a string into an INT fieldâ, because, again, PHP has no concept of the schema while youâre preparing the query, it can only look at errors returned by the server after execute.
I havenât posted the code because I am still trying to better understand PDO and keep numerous remarks in the code.
I understand what you are saying about the sequence being the same as the sql structure, as well as the bind types.
The problem that occurs is that the update does not actually update that one field. It simply returns it the same as it appears above.
The actual process does not produce any error information and the other fields do update.
If I were doing this using MySql procedure then I would have been finished with it but I still try to learn new methods.
This isnât PDO. You are using the overly complicated mysqli extension statements.
The first reply in this thread questioned/pointed out a variable mismatch, which posting all the relevant code would have answered. The variable you are copying $_POST[âdescriptionâ] into is not what you are using in the bind_param() statement. These additional variables are unnecessary clutter (looks like w3schoolâs bad examples), and by using multiple different names for the same piece of data, you have apparently confused yourself about which one you should be using.
Your code should keep the post method form data as a set, in a php array variable, then use elements in this array variable throughout the rest of the code. Once you do this, you can trim all the data at once, using a single php array function. The way to decide if you need to fetch the initial data being edited, is to initialize a variable to an empty array near the top of your code, then inside the post method form processing code assign it a trimmed copy of the $_POST data. After the post method form processing code, if the variable is empty, it means that the form has never been submitted, and it is here that you would query for and fetch the initial data into the same array variable. You would populate the form fields using elements in this same array variable.
Also, by keeping the data as a set in an array variable, and using an array for the user/validation errors, you can then use more advanced programming that will allow you to dynamically validate and process the data, without writing out bespoke code for every field.
If you try to learn new methods, do learn newer methods like using PDO instead of mysqli.
It is far simpler to use than both mysql or mysqli, once you get ot grips with it.
As pointed out, this is leading to you over-complicating a very simple process, which no doubt is leading to your errors.
This statement is confusing, as nothing you previously posted involves PDO at all.
But it should be needless to say, without seeing the actual code you are trying to use, we can only make âa stab in th darkâ at trying to help.
The primary issue seems to be the handling of HTML tags within the $description variable before itâs inserted into the database. When you directly assign the HTML content to the $param_description variable, the database might interpret the tags as plain text, leading to incorrect updates.
Setting aside that the last copied line is in the wrong order, you are defining $description from a DB result, then using that to set the value for $param_description (which is useless. Donât set variables for no reason), then using $param_description in your update query. So youâve gone through all this just to set the value to the original DB value.
Simpliy trim your post value and use that for your update.
So if $description is coming from the database in the first place, not from the $_POST input, then $param_description comes from $description (not post), how would you expect it to change?
Aside from what everyone in the thread is saying, thereâs one thing no one has mentioned yet. You shouldnât be striping, trimming, and modifying user input. You should be validating to make sure the input has compliance to your standards and if it doesnât then you alert the user. Once you got that then you just insert into the database without any modifications. If you are properly using prepared statements, you shouldnât need to worry about escaping anything. Only when you are outputting from the database or displaying to the user what they inputted, do you actually have to escape HTML characters.