Jacques1

And the third is to not use any prefixes or suffixes at all. What do you expect to gain from those hints? All IDEs I use tell me that it's an interface, so the naming standard doesn't provide any useful information.

Because OAuth distinguishes between the client (application) and the resource owner (e. g. a human user). The client credentials authenticate the client, the username/password authenticate the human user. Client authentication is not always required as per protocol, but the specific variant you've chosen or the implementation may still enforce it. But then again: It's entirely unclear what you're event trying to achieve. In your previous threads, you wanted to more or less get rid of the password entirely. Now you appearently want only password authentication, which would make the whole OAuth protocol rather useless. Forget about the technical stuff for now. What is your goal? What are the parties, how do they interact, and how is your application supposed to work?

Can you not understand, or do you not want to understand? I do not “discount abstract classes”. I don't. Wherever you got this idea from, it only exist in your head. Get rid of it, so that we can have a reasonable discussion. I'm saying that abstract classes are one of the less important OOP features and shouldn't be the focus of somebody who is just beginning to learn OOP. Less important. Shouldn't be the focus. Got it? We've discussed a concrete problem, and despite trying hard to justify the use of an abstract class in this scenario, you haven't convinved anybody. To the contrary. Now it's time you draw some conclusions from that. As to interfaces: I understand from your topics and posts in this forum that you have a – how do I say this nicely – rather relaxed attitude towards code quality. OK. This neither surprises nor troubles me. But the topic is about learning proper OOP, and that's definitely not the right place for your hacks.

Nothing prevents you from creating custom headers, as long as they don't collide with existing ones. Whether it's sensible to invent your own protocol is a different story. You misunderstand. The client credentials are exchanged for the access token. You send the credentials, you get a token. Passing the access token in the “POST body” doesn't even make sense, because it implies that every single request must be a POST request (what about GET?). Anyway, I think we've already discussed this in great detail, but there doesn't seem to be much progress. Maybe it makes more sense if you sit down, define your goals and then choose the appropriate implementation. If you randomly go through different protocols and variants, that only leads to more confusion.

So is the field required or not? If it is required, then it should actually say that. You need three checks: If the parameter is present at all. isset() does this. If the date is formally valid. The DateTime::createFromFormat() method does this, but you must check the return value. Don't assume that your jQuery stuff will prevent all input errors. If the date is plausible. In any case, I strongly recommend you use a date picker instead of making the user enter a bunch of digits. It will greatly increase usability und reduce the amount of garbage input.

You've just proven my point. Everything bad about Person stems from the fact that it's an abstract class. And the one potential benefit (reusing a single line of code) is so utterly trivial that it shows how hard you're trying to come up with a legitimate example. Which is exactly what I'm saying: Abstract classes are rarely useful and often abused. That does not mean abstract classes are somehow inherently bad. I'm using them myself in edge cases where there's a significant amount of common code and a trait wouldn't be appropriate. But again, this is rare.

Not really. I don't think this metaphor is particularly helpful. You can think of an interface as a specification, a class as a concrete blueprint and an instance as a product manufactured according to the blueprint. An abstract class would be half specification, half blueprint. The diagram is actually a great demonstration why skipping the specification part and throwing abstract classes around as suggested by requinix is often a bad idea. As you can see, the Person class makes very special assumptions: The first name and last name are stored in (public) attributes. There's a constructor with no parameters. Your implementation is incompatible with that? You need, for example, lazy loading? Too bad! If you start with a proper specification, this doesn't happen: <?php interface Person { public function getFirstName(); public function getLastName(); public function getSalary(); } This says that a person has a first name, a last name and a salary. How the methods work is completely up to the implementor.

Design-by-popular-vote? Oh my. According to that metric, the top PHP pattern is the SQL injection vulnerability. No wonder the whole world makes fun of us.

What baffles me is that you make it sound like the project is almost done, yet there doesn't seem to be any code which actually uses the databases.

The database layout is the product of plain, old incompetence. It has nothing to do with “large-scale applications” or preventing “crashes” (WTF?). In fact, you should forget about “scale” for now. Realistically, this is an amateur project, and the actual goal is to not fail like so many other projects. You can dream of becoming the next Google later. So there isn't any competent technician on your team whom you can talk to and who has the authority to rectify mistakes? That's worse than I thought. Then I'm afraid it's your job to talk to the developer, tell them that you have serious doubts about the current design, that it's impractical and that you suggest a simpler layout (like, you know, one database). Have some examples ready to demonstrate the problem. If that doesn't help, talk to the person responsible for the developer. That's all you can do. No workaround is big enough to fix this problem on the query level.

I'm not aware of a good resource that covers all PHP topics. However, there are specialized tutorials. For example, there's an excellent tutorial for the PDO interface; PDO is similar to mysqli but much more convenient and powerful.

Abstract classes are partial implementations. You use it when you want multiple implementation which share some common method definitions. This is rare and only relevant for edge cases. As I already said, all classes should implement an interface, either directly or indirectly though an ancestor. You always start with an interface which defines the API. And while you write your implementations, you may in a few rare cases realize that some method definitions are always the same and should be put into an abstract parent class rather than repeated.

As I've already tried to tell you, your task is relatively complex for a beginner. This means you need basic technical skills and the willingness to do some research (have you followed the Ajax link?). If you don't have that and think the graph will magically pop up when you copy and paste some code from the Internet, forget about it.

Good grief. I've seen many “developers” abuse MySQL in many different ways, but this must be the absolutely worst case. How on earth do you even manage this mess? How do you update the layout? How do you make backups? Not at all, I guess. I think your “developer” has no idea what a database even is. If there's anybody in your company who knows what she's doing, ask for her opinion. Because this looks like a massive fuck up which should be fixed immediately.

All interfaces, classes, traits, .... Like I said, the suffix is redundant. It's just clutter. It's an acceptable name for “naive” OOP where a single implementing class is baked into the application. It doesn't work for more advanced OOP where the number of implementations is potentially infinite.

An interface shouldn't be stored in a “.class” file. The “.class” suffix should actually go away entirely, because it's redundant. What else would be stored in such a script? The name “LoginAttemptsLog” is unfortunate, because it implies that the class is very generic and pretty much the only valid implementation. But it's the exact opposite: It's highly specialized and just one of many possible implementations. There could also be a file-based logger, a MongoDB logger and whatnot. How are you going to name those? So something like “SQLLoginAttemptsLog” is more appropriate. Methods must be documented individually. You should also describe the parameters (unless it's absolutely clear what they do). An exception handler only catches exceptions, not classical errors. In PHP 5, the only reliable way to handle all errors is to register a shutdown function.

You cannot update the graph with PHP. You have to use Ajax. Either you request a new graph from the server every n seconds. Or you use a graph library written in JavaScript so that you only need to request the updated data. This is relatively complex for a beginner, so be prepared to do your own research.

You're looking at the wrong line. The error is caused by the mysqli_fetch_array() call, and this typically happens when a query fails and you don't bother to check for that. So there are actually two problems. First, you need to start checking for errors or enable exceptions so that mysqli does this automatically: // make mysqli throw an exception whenever it encounters a problem $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; Secondly, you need to fix the query itself. When you enable exceptions, you'll see the MySQL error in the message. Apart from that, w3schools is a very bad resource and known to spread false information. Don't use it for learning.

cronjob

I think I've already told you this several times: You do not apply HTML-escaping or any other manipulation before you insert the data. This effectively damages the input and makes it unusable. For example, the username “I <3 PHP” would become “I <3 PHP”. Good luck doing a text search on that. Escaping is done when you output data, and it must match the specific context. HTML-escaping only works for HTML contexts, shell-escaping only works for shell contexts etc. The functions you've found in that CMS are braindead. You should generally stop using random code from the Internet. Think for yourself.

This is wrong on multiple levels. First off, a prepared statement has nothing to do with escaping. It's an unrelated mechanism where the data is completely separated from the query. When you create a prepared statement, PHP sends a query template with placeholders to the database system: INSERT INTO members (username, password, email) VALUES (?, ?, ?); The database system parses this template and creates a query structure. When you bind values to the parameters and execute the statement, PHP passes those values to the database system in a separate packet. So the data is not part of the query and cannot affect the query in any way. Escaping is much less secure, because it still involves inserting the (escaped) data into the query string. This can fail. For example, if the escape method and the database system use two different character encodings, an attacker may very well be able to inject special characters and manipulate the query. Unfortunately, PDO does use escaping by default; they call it “emulated prepared statement”. To get actual prepared statements, you must change the PDO configuration: $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Bobby Tables

You can either turn your brain on and use the correct code I gave you in #5. This will take ~5 minutes. Or you can spend the rest of the week on your “quick fix” and then another week fixing the fix. Which option sounds less stupid to you?

Don't hijack akhilkumar332's thread. If you want an extended discussion about PDO, create your own thread.

I've already answered the documentation question in #6. You document the interface and then let the classes inherit this documentation -- unless one of the classes is so special that you want a class-specific documentation, in which case you can just override the parent documentation. The directory structure should correspond to the namespace structure. Don't create random directories. If you want the classes to be in a Debugging subdirectory, they have to actually be in a Debugging namespace.