requinix

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.

You've described some stuff that doesn't make sense. Like, you say "$this->debug" but I can't tell which class you're putting that in. Shouldn't it be more like $this->util->debug, or $this->pass->debug? 1. Post more code. Especially the stuff showing what $debug is and where it's being used. 2. Describe what you're trying to do. Because it sounds like you're approaching this in the wrong way - any time you need a class named like "Utility", that's an ominous sign. It kinda sounds like you're reinventing the concept of logging...

What breakpoint? What code?

Get what to work? What are you trying to do, what did you expect to see happen, and what actually happened instead?

Given that the question involves .htaccess, I would certainly hope so.

No, you're doing "this" (URL rewriting) with a .htaccess. "Order" of what, and who is talking about changing it? In some WP plugin? No. In the .htaccess you said you were using, yes - and my post reflects that. Okay. Great. But I don't see how "there is no /category in other places" is a problem? What matters is there is one for the URLs you're trying to redirect from. They have a /category. However, I'm not sure whether "/category" is a literal thing or not: you weren't using it at the start of this thread but you are now. Is "/category" the thing that appears literally in the URL? Or is it another variable value like the two things after it are? If it's a variable then you need to switch back to the /[^/]+ piece that was there before, but then you need to think about whether you have any other place on the site with URLs that look like "/site/thing/thing/thing/" - that is, "/site" (which may or may not be real) followed by three "directories" of navigation.

What's the rest of your .htaccess's URL rewriting rules? Where you put this is going to matter, depending on what other rewriting you might be doing. Meanwhile this RewriteRule ^shop/[^/]+/[^/]+/([^/]+)/?$ /shop/$1 [R=301,L] is kinda close: it has the right number of "directories" in there, but it skips both the /category and the /jeans and only keeps the /mens-jeans. So while it should match, if put in an appropriate place, it wouldn't do what you wanted. ____$0______________________________ | __$1___ | | | | | RewriteRule ^shop /[^/]+ /[^/]+ /([^/]+) /?$ /shop/$1 [R=301,L] /shop /category /jeans /mens-jeans You know the first is "/shop" and the second is "/category", you know there's a third but you don't want to keep it, and you know there's a fourth that you do want, then RewriteRule ^shop/category/[^/]+/([^/]+)/?$ /shop/category/$1/ [R=301,L] (also added a trailing slash in the replacement URL, since it looks like you want those) With that, you need to confirm it isn't conflicting with anything else (hardcoding the "/shop/category" part helps with that) and that it's happening early enough in your URL rewriting process that it can actually do its job.

Want to give that another shot?

Consult with an immigration lawyer.

Autoloading is for classes.

if (!empty($titleElements)) { You didn't define $titleElements. Thus the $title is empty...

Sounds like you're not submitting the data in the format the API requires. Check the documentation for what you should be doing and compare it to what you are actually doing. Also, maybe it's just me, but shouldn't that "Select Date" have, you know, some kind of date field associated with it? It's just empty...

That's not responsive.

Post the row data in those three tables for that customer_id, and include what output you expected to see.

No, because it varies depending on the different CSS and JS frameworks you're using. If you're using a framework then research what it supports in terms of responsive design. If you aren't, and you don't want to start using one, then learn about CSS media queries so you can write your own responsive rules, and also spend some time understanding your target audience so you know what size screens you should be designing for.

Most of the time a responsive design moves horizontal elements gradually vertical. Right now you have Device Info and Network Settings in a left column and the settings themselves in a right column. The first responsive step towards a narrower design is to use one column and make the labels on the left be headings - which they might already be. Device Info ======================================= ... Network Settings ======================================= Ethernet Settings --------------------------------------- DHCP [ ] IP Address [__________] Subnet Mask [__________] Default Gateway [__________] DNS [__________] Side note #1: you really ought to support multiple DNS servers. You could keep the navigation anchors, which I assume exists, by moving the left column into a slide-out menu. To go narrower, you take the two columns of setting name on the left and setting value on the right and merge them into a single column of setting name then setting value. Device Info =================== ... Network Settings =================== Ethernet Settings ------------------- DHCP [ ] Enabled IP Address [_________________] Subnet Mask [_________________] Default Gateway [_________________] DNS [_________________] Side note #2: many interfaces for DHCP present it as a DHCP vs. manual/static option, not just a mere checkbox.

Which API? If you're having trouble making your PHP code work then you'll have to post (the relevant parts of) your PHP code. Because

First guess is that you didn't install correctly everything you needed to install. Because "no such file" (or directory) means the file doesn't exist, and clearly something expects that file to exist, so it probably needs to exist...

That does sound simpler, yes.

To make sure I understand, you have two options: (a) Do three normal INSERT statements, and get the auto-incremented IDs of what you need (b) Do a normal INSERT and then craft a couple INSERT...SELECT queries based on the raw values you want to insert plus a reference or two to the IDs of the new rows you created that hopefully don't have any duplicates I'm thinking you should go for the simpler option.

That's a browser error, not a PHP error. 271k rows of data on a page is ridiculous. Use pagination.