requinix

A <tr> is a table row. A <td> is a table cell. If you want one row with multiple cells then you need one <tr> and multiple <td>s.

That's floating-point arithmetic: the computer can't calculate 573.06 * 100 exactly so it comes up with something close. Something like 57305.9999999999986. And if you truncate that, like with an int cast, then you'll just get 57305. In other cases it might come up with 57306.00000000000005. The solution is super simple: round the number instead of truncating it. function convertToMoneyInteger($input) { return round($input * 100); } Be careful that your $input is never going to have fractional cents or you'll lose them by rounding to 0 digits. If you're concerned that might be possible, round to an appropriate number of decimal places.

Tip: if you want to use programming to make your work easier, you should try considering yourself a programmer. So, what have you tried to do so far?

1. What have you tried so far? 2. Are you aware that PHP has a variety of DNS functions already?

It's not possible to book a particular seat in the theater. (Most likely.) Instead, one has to book a particular seat in the theater for a particular screening. Thus the status must be associated with something that has both of those pieces of data. You don't have such an entity... basically. You could build one by creating a "screening_seat" table, consisting of a screening_id and seat_id. Rows could be created on-demand, removing the need to pre-populate that table when a screening is created. You would then adapt the booking_details to reference that screening_seat instead. However, if the status is a simple boolean "booked / not booked" then you don't need to store it because it can be inferred from the existence of a booking for a seat. In other words, with the current design, if there is a booking_details with seat_id = $seat and booking.screening_id = $screening then the seat is considered booked, and if not then the seat is considered free.

You've posted bits and pieces. If there's nothing more to it and you've shown us everything then the answer is simple: you can't call PHP functions from Javascript like that. But I suspect you haven't posted everything. Please do.

As mentioned on Discord, if you want wincache because it can cache PHP code, then use opcache instead: it does the same thing, except it's part of the PHP core instead of being some third-party, Windows-only extension.

The main problem is that this $email_to = "email1@website.com", "email2@whatever.com"; isn't going to work. You can't just list multiple email address strings like that. But before that, the other problem is that you're manually trying to send emails. That's almost always bad: emails are hard, and doing it yourself is pretty much always going to go badly. Switch to a library like PHPMailer or SwiftMailer, which will not only be able to do emails properly but also make it easier to do things like add multiple recipients.

Send one of those emails to yourself and check the full source (or whatever your client calls it) of the message to see what the Return-Path is. Was it possibly overwritten by some other value?

Not quite. Yes, it's displaying the confirmation after you click the button, but it's not displaying it because you clicked the button. What's happening is that you clicked the button (event #1) and then the button, having no other behavior imposed on it to override the default, causes the form to submit (event #2), and that shows the confirmation. Additionally, "srcElement" is old, and what you should be using instead of it is "target". And that name communicates the purpose better: it isn't the "source element" of an event, which suggests that it's some element responsible for the event, but rather it's the target of the event - the thing the event is addressing. It's a distinction that matters because of how events work and the fact that you can - and will, if you're not careful - receive events for child elements. So the target (aka srcElement) during the onsubmit is going to be the form. Not whatever thing that you interacted with that set about the chain of events causing the form to be submitted, but the form the event is associated with. Or another way to think about it is, your code is paying attention to the form being submitted when you actually wanted to pay attention to a button being clicked, and that mismatch is your problem. But anyway, that "receive events for child elements" thing I said earlier is useful because it means you have a way to listen for a click event on any button in the form by listening to the form itself. That means you don't have to loop over the form's buttons, and you can use a single event handler. jQuery makes doing this easy because you can tell it to (1) listen to the form (2) for a click event (3) triggered by a button. $("#myform").on("click", "button.form-button", () => { ... }); Native DOM only does the first two parts so you have to handle the third yourself, which isn't hard since .matches exists. document.querySelector("#myform").addEventListener("click", (e) => { if (e.target.matches("button.form-button")) { // e.target is the button, e.currentTarget is the form } });

Object-oriented programming tends to be one of those things that doesn't really make sense until you find the right piece of information, or read something phrased in just the right way, or happen to be in the right frame of mind, at which point it all starts to click together. Which makes it hard to explain or teach. But basically, think of what you're doing - whatever it is - in terms of "Things" and the "Actions" those things can do. For now, forget programming and try applying it to real-world concepts. For example, I'm here sitting at my computer. The computer is a Thing. It has a power button, which also counts as its own Thing if you really want to go that deeply into it. If I perform the Action of "press the power button" on my computer, it'll either turn on (if it's off) or start shutting down nicely (if it's on). Or I can press the power button for a few seconds, in which case it'll either turn on or it will immediately turn off. And if I were to sketch that out in some pseudo-code, it might look like thing Computer { action PressThePowerButton(HowLong) { if PoweredOn { TurnOn // doesn't matter HowLong I pressed the button for... I think } else { if HowLong == Short { TurnOffGracefully } else { TurnOffImmediately } } } } For another example, I'm hungry because I haven't eaten today, so I'm going to go into the kitchen and cook something. I'll be using my stove Thing. It has four burner Things, each wired to one of four corresponding knob Things, and I can turn the knob right/left to turn on/off the associated burner. thing Stove { has Burner1 has Burner2 has Burner3 has Burner4 has Knob1 has Knob2 has Knob3 has Knob4 action Manufacture { Knob1 = create a new Knob connected to Burner1 Knob2 = create a new Knob connected to Burner2 Knob3 = create a new Knob connected to Burner3 Knob4 = create a new Knob connected to Burner4 } } thing Knob { knows about a Burner action TurnKnobRight() { set Burner on } action TurnKnobLeft() { set Burner off } } thing Burner { has Temperature action SetOn() { Temperature = High } action SetOff() { Temperature = Off } } Basically, 95% of OOP is thinking about Things and Actions, and by doing so you can take a complicated concept and reduce it into smaller pieces that are easier to manage. Like how I didn't try to "code" all the burner and knob stuff in one place: the knob knows how to do knob things, the burner knows how to do burner things, and they're hooked up to each other. But now I'm really hungry.

An API is a contract that says "if you give me X then I will give you Y". It has nothing to do with OOP. So it's totally valid to build an API with code that's procedural. In fact, a lot of OOP is just syntactic sugar over a procedural pattern. Take PHP's cURL functions for instance: you create an "instance" of a cURL thing, then call different "methods" using that thing - whether you write "curl_function($instance)" or "$instance->function()" doesn't make much of a difference. So what's your goal here? To build an API and you think you need OOP for it? Or to learn OOP using the idea of an API as a real-world example?

...how else are you accessing it?

Maybe a silly question, but are you sure the data from that first query is being entered? It's not possible that you had identical data in the table and so it seems like it worked?

"A problem"?

I don't see anything in here that would magically stop working just because it's partway through processing the letter "C". Whatever your problem is, it's not going to be apparent from reading the code you've posted.

Commas? You mean the quotes? No, they don't matter, you don't have to remove them. The object is fine. Are you sure the JSON your PHP script is returning was decoded as JSON and isn't being kept as text? Is your script returning the right Content-Type header?

What code have you tried so far and what happened when you ran it?

Casual code doesn't always use types. And there are people who find "array" to be easier to scan and read than brackets.

Your teacher is going to grade you on the quality of someone else's library? What? It doesn't look old. It's not like PHP 8 introduced some incredibly obvious and immensely helpful features that everybody had to stop what they were doing and migrate to using. Like, unless I were to look over it with a fine-toothed comb, I don't think I could tell you whether it was written for PHP 5 or PHP 8. But no, there aren't really any tools to do what you want automatically. Not that I know of. But the project isn't that large - it should only take, like maybe, 15 minutes if you wanted to "spruce it up" or something.

Have you tried running it? Does it work? Are there any errors?

Right now, you will end up with a situation where someone is able to pick a combination of 4 that does not exist in your database. You can avoid that with either: (a) Don't do all 4 at once. Do the first, then when the user makes a choice you update the next, then the third, then the fourth. (b) Do all 4 at once, but you need to add some Javascript that will ensure the only options available for 2, 3, and 4 are the valid options according to the earlier choice(s). What would you rather do?

That doesn't really say a whole lot. I think what you're doing is essentially logging: when a piece of code performs some action, you want to record a log of the fact that it happened, as well as potentially some supplemental information about it. For example, you've got this "new comment" thing. That sounds like a log message. Additional information about that could be the author of the comment, what they were commenting on, and the timestamp of when they made it. If you just want something that lives for the duration of the code - you don't want this going to a file, or saved to a database, or anything persistent like that - then some parts might not be as useful as others (like the timestamp). Consider this simple function: function log_message(string $message, array $data = []) { $output = date("[Y-m-d H:i:s] ") . $message . PHP_EOL; foreach ($data as $key => $value) { $string = is_scalar($value) ? $value : json_encode($value); $output .= "\t{$key} = {$string}" . PHP_EOL; } file_put_contents("/path/to/file.log", $output, FILE_APPEND | LOCK_EX); } used like log_message("New comment", ["author" => $authorId, "page" => $pageId]); Instead of building up some "debug" string living in a class somewhere, you call that function and it will immediately write the message to a file. You can then open that log file (remember to change the path) in any decent editor and watch messages get written to it when you browse your site. There is actually some better stuff that's built-in to PHP you can use, so the above is really more of an example of the concept of logging. Does that make sense? <opinion> PHP is a functional language, meaning it has functions that don't have to live within classes. It makes sense to occasionally use functions for things that don't need to belong in a class - such as that "log_message" above. The one disadvantage is that PHP can't (yet) autoload functions like it can classes, so in order to get them available everywhere you need to make sure the file(s) with the functions are always included; normally a site has a single entrypoint file, like /index.php, through which all requests pass, and that would be a great place to include the necessary files. A similar approach is static methods in a class: it's kinda object-oriented in that there's a class, but really the class is just a container for functions. A container that can be autoloaded by PHP. And with static methods, you don't have to pass around these "util" (or "pass"?) objects everywhere. That's a reasonable compromise, but I'm not thrilled as (a) it's just an end-run around plain functions and (b) it lends itself to organically-grown utility classes. So really, the first step to getting rid of a utility class is to decide whether the functionality you have doesn't actually have an appropriate and specific class for the various methods after all. Consider the log_message function having been added to a Utility class. You might start with it as a regular (non-static) method on a Utility class. Then you realize that you can make it static, as you don't really need an instance of the Utility class in order to write some stuff to a file, however it's still a "utility". The next step is to realize that logging is a concept which can have its own class. Like a class named Log, or Logger. That's better than a utility as you've taken a specific requirement (log a message) and found a specific class (Thing That Logs Messages) for it to belong in. (And there's more to think about after that...) But occasionally you do end up with functions that don't really belong anywhere. For example, I have some code that needs to check if an array contains an item matching some conditions, as determined by an arbitrary function that returns true/false. function is_even_number($number) { return ($number % 2) == 0; } PHP doesn't have a built-in function that can do what I need, so I have my own called "array_contains". function array_contains(array $array, callable $function): bool { foreach ($array as $key => $value) { if ($function($value, $key)) { return true; } } return false; } used like array_contains([1, 2, 3], "is_even_number") // true array_contains([1, 3, 5], "is_even_number") // false I'm not going to create an Array class just so I can put this function into it, and for reasons that are more complicated than I need to get into here. So it's just a plain function. </opinion> Point is, there are two main alternatives to a utility class: (1) go ahead and use a plain function because that's how PHP works and it's totally fine that not every single thing in PHP is an object, or (2) conclude that a particular thing could actually make sense in a separate, dedicated class because there's potentially more to the general concept that you might want to account for in the future.

if( !empty($_POST["adsoyad"]) && !empty($_POST["email"]) && !empty($_POST["telefon"]) && !empty($_POST["konu"]) && !empty($_POST["mesaj"]) && !empty($_POST["eht"]) && !empty($_POST["arac"]) && !empty($_POST["tam"]) ) { Your form does not have a konu or mesaj. The form does have a kyts which you are not using.

Then all I can tell you is you're doing something differently in this third class that you were/weren't doing in the other two classes. Because PHP isn't going to care about how far from the "top" you are: an object is an object. If you can do ->debug on a particular object from one place then* you can do the same ->debug on the same object from a different place. Alright. But one question: Doing what another way? * Technically that's not always the case, but it shouldn't be an issue as far as this is concerned.