requinix

Or do both: put the validation inside a function, and put the function inside a file. <?php function is_valid_name($name) { return preg_match("/^[a-zA-Z\'\-\s]*$/", $name); } if ($_SERVER['REQUEST_METHOD'] === 'POST') { require_once "the other file.php"; if (!is_valid_name($firstname)) { $firstnameErr2 = "Only letters allowed"; } if (!is_valid_name($lastname)) { $lastnameErr = "Only letters allowed"; } Kinda. I'd say that you're going about it the naive and simplistic way. Which is typically the first step towards doing it in a smarter and more flexible way. If you're doing this for a personal project then don't mind it. Unless you specifically want to learn how to do this better...? But I will say one thing: don't validate people's names. Just don't. It's a bad practice because you're always going to end up rejecting the valid name of someone, somewhere. Additionally, separating names by first and last isn't even correct either: there are people with single names. The right way to do names is to use a single full-name input and ensure it has something in it. Nothing more.

BTW the main trio of web servers is IIS, Apache, and nginx. They all work quite differently from each other, and they can get rather complicated if you want to learn them in depth, so I'd suggest your first decision be whether you want to focus on/start with the Windows stack (with IIS) or the 'nix stack (with Apache or nginx).

The world of technology moves too quickly for print books to be up to date: by the time they're published, (a) The information is wrong because the technology has progressed in the time it took them to write, edit, and publish that book. PHP 8.3 is due in the next couple months but most books are only just now starting to talk about 8.0 or maybe 8.1. (b) The information is wrong because, in their haste to publish a book as quickly as possible, they took shortcuts and jumped the gun. You'll find tons of books about PHP 6 out in the world, but guess what: there is no PHP 6. Online resources are going to be the most accurate and most up to date. But none of that matters because there is virtually no difference between PHP+IIS and PHP+Apache and PHP+nginx+fpm. It just doesn't matter that much. What can matter is whether you're using Windows or Linux, but even that makes very little difference in practice either.

This means the remote end of the socket closed its connection while PHP was still trying to write to it. Why? I can't tell you. Could be the remote code bailed and the program quit. Could be it closed the connection normally but your PHP isn't "smart enough" to recognize this happened. You'll have to look into why the Python side stopped. That's a bug in the code: it thinks a value is an array when it's actually null - probably as a result of some other operation failing. Improve the error handling in that area of code, then find out what the underlying problem is and fix it.

As the term would hopefully suggest, ON DUPLICATE KEY requires that you have a unique (or primary) key in your field list. That's how it knows there's a duplicate: you tried to insert something that exists. If you don't include any keys then you're simply going to insert new data. I'm inclined to think that your min_qty, max_qty, and currency fields are not part of a unique key. Put the ID back. None of this helps me to understand why your form, which is clearly designed around editing an existing ID, will ever have to deal with a situation where the data to be edited does not exist yet.

If you know that the form was submitted then you could take the absence of a value as proof that it was unchecked. But yes, there is a simple solution that lets you keep checkboxes: use hidden inputs. <input type="hidden" name="checkbox" value="off"> <input type="checkbox" name="checkbox" value="on"> When checked, the checkbox's "on" overwrites the hidden input's "off".

Checkboxes are only submitted in form data when they are checked.

That's the same thing as Barand posted, except you flipped the condition which then forced you to use that else block.

Have you checked your PHP error log for messages? Perhaps a message occurring on if ($conn->connect_error) this line?

"Simple" string interpolation only allows you to access a single level of an array. If you want multiple levels then use the "complex" syntax with braces: "value='{$rows[0]['itemName']}'>"

"Works" in that it outputs this image: ...

Okay yeah no, you're missing the point. Look at this: <a class="color_black" id="btn" href="?dashboard=user&page=member&tab=viewmember&action=view&member_id=<?php echo esc_attr($retrieved_data->ID)?>"> You know what URL you want the user to go to. After all, it's right there in the link. So if you know what the URL is, why even bother having this page at all? Why give the user some HTML page when all you're going to do is trigger some Javascript that immediately sends them somewhere else? It's wasteful. Instead of giving them this page, do the redirect. In case you weren't aware, you can do it with some PHP code. Maybe that was the missing piece in this puzzle? It looks like this: $url = "?dashboard=user&page=member&tab=viewmember&action=view&member_id=" . esc_attr($retrieved_data->ID); header("Location: $url"); You execute that code before making any output at all. None at all. Then you stop executing after that - so no output after it either. And that's how you do a redirect from within PHP. One that doesn't require any HTML or Javascript.

I mean That page. The one you're talking about "when it loads". I'm saying, don't load that page. Ones before it fine, but instead of "when the page loads I want them to redirect somewhere else" you should do "don't load that page and instead do the redirect at that moment". If that's not making sense, and there's a good chance it doesn't, then please explain more about what "pages" you're talking about.

Why load the first page at all if you're just going to redirect them immediately anyway? Don't send them back to the first page. Send them directly to the second page instead.

If you're using LAMP then everything should be set up for you. You don't need to tinker with any configuration to make PHP work. So undo the changes you made and get yourself back to the original setup that, at least, had Apache up and running. With that addressed, a quick question: what is the URL you see in your browser's address bar when you try to run one of your scripts?

You're right, it is a trivial thing that you're missing. (At least, as far as I understand what's going on...) This is probably a good place for the rubber duck approach: Imagine someone is sitting next to you (or find an actual person you can talk to) and explain to "them", in detail, about your username/email input and about the CSS. Pretend "they" don't know much about CSS or HTML. Tell "them" about how the CSS works and how it knows to resize that input. Point out the relevant code to "them" as you go. It should take you a few minutes to do this exercise - any faster means you're rushing through it.

So you tried doing something more difficult and awkward and it created more problems than it solved, right? Then don't do that.

I don't know what you mean by "change size", but I can't help but notice that you have CSS for type=email and type=password inputs and not for type=text inputs. I'm also going to assume you're already aware that the type=submit rules aren't going to apply to your submit button.

When you use URLs like "sub.png", for images or CSS or basically anything at all, the browser will look them up according to the "directory" in the page's URL. Before the rewriting, your URL was like /profile.php?profile=123 so "sub.png" would mean /sub.png. After the rewriting, your URL is now /profile/123 so "sub.png" means /profile/sub.png. Use absolute URLs for these sorts of things: that's with a leading slash, and starting from the root of your website. As in "/sub.png", which will always mean /sub.png regardless of what page you're on.

I like how the comment says "i" but the code says "s". So you dumped out the value of the ID from the form, and it says like string(3) "123", and then you looked in your "crud" table and found a row with id=123? And your code is running successfully, making it to that echo statement, except it doesn't show a value there - and instead PHP actually gives you a one or more warning messages about $result and/or $r and/or the "name" key?

I think you're misusing inheritance and interfaces, but sure, go ahead and try the RFC process if you want.

You've given basically zero details about what any of this is about, or what the application does, or really even what you mean by "certificate". And no, there is virtually never any documentation on how to build the application you want to build. Because it's your application, and you're the only one who knows what it's supposed to be.

You cannot catch with type intersection - only a type union, which isn't really a union but more like a syntax meaning "or". If you want a type intersection then use a named class. But in your case, kicken's right: all you actually care about is the Err and its getExitCode method anyway.

A password hash will always consist of alphanumeric ASCII characters. You will always be able to save that in your database. The fact that you're saying "if the password has non-alphanumeric ASCII characters then I can't save it in the database" means you're doing something wrong.

No, password_hash handles all the work for you. Including salting. Don't do anything extra.