Jacques1

Are you talking about the modern OOXML format (.docx) or the legacy MS-DOC format (.doc)? If it's OOXML, templating is very easy, and there are libraries like PhpWord which support this out of the box. It's the old binary MS-DOC format, this will be a lot harder.

I think the “troll” accusation is a bit unfair. Maybe benanamen is taking a minority position here, but that doesn't make it wrong. In my own experience, it actually can be more productive to move users towards modern PHP rather than trying to repair their legacy code over and over again. I've introduced quite a lot of PHP beginners to PDO, and while they weren't all happy with it at first, they did eventually recognize the benefits. So a five-minute argument can save hours, days, sometimes years of turd polishing, which is in absolutely everybody's interest. This also goes far beyond the problem of legacy applications. PHP code relying ext/mysql is notorious for SQL injection vulnerabilities, awful error handling or no error handling at all as well as idiotic habits from 90s tutorials. It's not just old, it's truly harmful. I don't think that's “shoving best practices down people's throats”. None of us is afraid to reject the ideas of a user when they're clearly bad, so we shouldn't be afraid to reject bad code either.

It's not the function, it's what comes before that. Your query is also vulnerable to SQL injection attacks. Learn to use prepared statements.

You can actually debug session problems yourself: Open the developer tools of your browser (or the Firebug extension in case you're using Firefox), and you'll get a detailed overview of all HTTP messages and cookies. This allows you to find out where exactly things go wrong. Typical session problems are: There's output before the session_start() call, and output buffering is off (this is a server setting, so it can be different on your local test server and the production server). You're using different domains like yoursite.com and www.yoursite.com. Does the problem occur only in this particular script, or do you have trouble with sessions in general?

As you can see in the var_dump() output (or the manual), $rr is an object, not an array. You need to access the attributes with the attribute syntax: $rr->preference

For those of us who work on any bigger project, that's not an option. So using the WWW means clicking on fancy buttons in web browsers, and anything below that is evil? C'mon. Have you never made a raw HTTP request? Have you never written a user script or browser extension? GUIs are just tools. A well-written application can be accessed in many different ways and lets the user decide. The programmer's preferences are irrelevant. Sure, in your private projects you can try to ban everybody who doesn't speak English or dares to understand HTTP. But how exactly does that help you? This only hurts legitimate users. Even the dumbest script kiddie knows how to send a submit button value, but legitimate clients have to jump through hoops to make your friggin' validator happy. It must be the other way around.

Guys, let IE8 rest in peace. You're missing the point.

If you're only working alone on small projects where you can come up with your own “rules”, do whatever you want. It's pointless to argue about personal convictions. But outside of this special case, your approach doesn't work at all and is actually harmful: On a multilingual site, the label is likely to depend on the language. Are you saying that everybody should maintain a long list of translations in their code only to “validate” the silly submit label? In many projects, the templates are maintained by a separate team of designers. If the whole code breaks whenever somebody merely changes the label text, that's just unacceptable. It's perfectly normal to submit data without clicking on any buttons (e. g. user scripts, cURL, Ajax, ...). If you reject those requests based on arbitrary “rules”, you may actually lose users. Many sites cannot afford this. A submit button and its label is just a trivial GUI element. It should have no effect on the business logic whatsoever. If your entire backend breaks just because the stupid label is missing or “wrong”, that's clearly bad code. How do you even react to a missing label? Do you silently assume that you received a GET request even when that's definitely wrong? Without checking the request method, you have no idea what's going on. It just makes no sense. Even when you need to distinguish between two submit buttons, a much better approach is to have two button where the value is completely independend from the graphical label: <?php if ($_SERVER['REQUEST_METHOD'] == 'POST') { if (isset($_POST['action'])) { echo 'Action: '.htmlspecialchars($_POST['action'], ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8'); } else { echo 'Missing POST parameter: action'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> </head> <body> <form method="post"> <button type="submit" name="action" value="add">A random label for the “add” action</button> <button type="submit" name="action" value="delete">A random label for the “delete” action</button> </form> </body> </html>

The general problem of the filters is that they depend on the technical limitations of the PHP data types. For example: On a 32 bit system, FILTER_VALIDATE_INT is limited to the range −2,147,483,648 … +2,147,483,647. Unfortunately, that's not enough for a MySQL BIGINT which is 64 bit wide and can store much larger and smaller numbers. So once you're dealing with bigger numbers, the filters may stop working and give you nonsense results (which is very hard to debug if you don't know where to look). There's no such problem with ctype_digit(), because it simply checks the input character by character. FILTER_VALIDATE_FLOAT has similar problems. It also supports formats which aren't normally understood by users like “.1e-2” (which is the scientific notation of 0.001). If you're OK with those limitations and quirks, feel free to use the filters. Otherwise ctype_digit() or a regular expression are problably better choices. I'm sure there are also validation libraries which implement this already.

is_numeric() accepts a lot of technical formats which most users don't understand and probably find confusing like “-.4e+1”, “0xaf” and “0b1”. It also behaves differently depending on the PHP version, which is another problem. What exactly do you mean by “numeric”? That it only contains decimal digits? Then you should use ctype_digit(). Also make sure to use an input of type number so that the user input is immediately validated by the browser.

Just like requinix or me. Our opinion on this matter isn't any more relevant than yours. We don't have any secret knowledge about string interpolation. Pretty much, yes. There are dozens of edge cases we can discuss all day long, but that's probably a waste of time. I think the previous answer was very clear: Use curly braces except for very simple cases. Now you can decide what you think is simple. How often do you need to insert raw variables into strings, anway? The last time I did that was when I assembled the message for an exception. Everything else is handled by the template engine or requires some form of escaping or is too complex for the very limited string interpolation in PHP.

Again: I think you can answer that yourself. In your $color example, there are no readability issues, no ambiguity, no complex expression. The curly braces wouldn't add anything, so they're not required. You can still use them for the sake of consistency, but you don't have to. The simple syntax works just fine.

Have you tried answering that yourself? Compare the two in terms of readability and consistency (array index syntax), and I'm sure you'll figure it out.

PHPMailer validates the provided e-mail addresses, so they cannot be used to inject headers. However, a library doesn't magically prevent all possible vulnerabilities. For example, in your above code you print mail errors directly on the screen, which can leak critical information about you server. Another common problem is to insert raw input into an HTML mail, which can lead to cross-site scripting vulnerabilities. So writing secure code is still your responsibility as a programmer. A library can only take care of specific problems.

Do you even need to repeatedly resolve those custom points? In other words, can getCustomPoints() again return points of type “cust” which again have points of type “cust” ...? Because otherwise the whole complexity is just pointless. It's also odd that you keep separate arrays of the IDs when you already have them as array keys. Why not simply extract them from the main data with array_keys()? Last but not least, the whole method is way, way too complex to be a setter. A setter is a primitive method which does nothing but set an attribute. It doesn't execute dozens of lines of business logic. So I strongly recommend you choose a more appropriate name like “load” to stress the heavy lifting done by the method.

You haven't hurt anybody's feelings. I simply do not accept a “Thank you for nothing” comment after having spent quite a lot of time on your questions in multiple threads. But since we've settled this, I have no problem with you. I understand that you'd like to get a solution to every PHP problem within seconds. But we're no mind readers. Before we can jump to solutions, we need to agree on the problem. In your first post, you tried to pass zero arguments to a function with 9 parameters. How are we supposed to “solve” this? This is a conceptual issue. The only solution is to explain how parameters work and find out what you're trying to do. Keep in mind: We don't know your project, we don't know your thoughts, we're not sitting in front of your PC. We only see your posts and a couple of code fragments, and when those don't really make sense, you can't expect a quick solution. By the way: When I post a link to the manual, this is serious advice, not a joke or an insult. I myself look up topics in the manual all the time, simply because it's the definite language reference. This is how I learned (and still learn) PHP.

With that attitude, you won't get anywhere, not here, not in other forums, not in real life. We've literally dragged you through the PHP basics, explaining them over and over again, desparately trying to make sense of your weird ideas and misunderstandings. I kept going even when it was clear that you don't know anything and don't want to learn either. That was clearly a mistake. If you're just stressed out and want to apologize later, feel free to do that. Otherwise you can go find yourself.

The concept doesn't even make sense. If I happen to already be in the checkout process of adidas independent from your site, would you then add new products to my current session without asking me? Would you abort my current session to replace the products I've chosen with the products of your choice? None of this is acceptable, and I'd probably report it as a security vulnerability. Maybe adidas has some kind of wishlist API or an affiliate program where you can suggest products on their site. Otherwise just link to the product.

You mean errors in the sense of the E_* constants? No. Exceptions and classical PHP errors are two unrelated concepts. The reason why they both exist is historical: In the early days, there were no exceptions, just errors. Errors are primitive and difficult to handle (they cannot be caught), so later PHP versions introduced the more modern concept of exceptions known from many other languages. Now we have both. Classical errors are mostly seen in legacy code (as well as the PHP core), exceptions are mostly used in modern applications. Bugs, network problems, database problems, missing files, ... Anything that happens unexpectedly and is worth suspending the normal control flow of the program. Wrong user input does not fall into this category, because it's perfectly normal for the user to make a mistake. This should be handled by the standard processing routine (print a warning and emit an appropriate HTTP code), not by putting PHP into “panic mode”.

When you change the attributes of an object, you only change them for this particular object. And the entire object is destroyed once script execution ends. You seem to assume that a freshly created object somehow has access to the attributes of an entirely different object within an entirely different PHP process that has already been terminated. This doesn't work. This doesn't make sense. And even if I were to ignore all this, the code still doesn't make any sense. In your strange novaAula method, you call the setters within a loop, which means you keep overriding and losing the previous attribute value. I'm out. All I can tell you is that you definitely need to learn the basics, or else you'll spend the next days, weeks, months fighting “strange problems” that only come from not understanding how PHP works.

The places where you use raw bytes and encoded bytes are mixed up. You need to store the raw random bytes in a variable. Then you send the encoded bytes by e-mail (the encoding is just for human readability) and hash the raw(!) bytes with SHA-256 so that you can store the hash in the database. The hash itself should also be encoded, which is the default of hash() when you omit the true argument. <?php $raw_token = random_bytes(16); // send this to the user $encoded_token = bin2hex($raw_token); // store this in the database $token_hash = hash('sha256', $raw_token); Hashing the encoded token doesn't really make sense, because this just bloats the random input. And storing a binary hash makes it more difficult to handle the data in the database. Because otherwise the token is stored as plaintext. If anybody manages to break into the database, they get a large collection of valid tokens and can abuse them. The damage might be relatively low as long as the tokens are only used for e-mail verification, but it's still an unnecessary risk. Only the user is supposed to know the token, so there's no reason to store it as plaintext.

I don't know what you mean by “call the method from outside the function”. What function? You haven't posted any function, just the method defintion.

Abusing exceptions to direct the normal control flow of the program is poor style and very confusing. Exceptions are for exceptional situations. Most of those problems cannot be recovered from, which is why exceptions are fatal by default and make PHP abort the entire program. You, on the other hand, use exceptions even when there's no problem at all, giving a nasty surprise to anybody has hasn't carefully read your documentation (if the exceptions are documented at all). Getting information from a method or function is what the return value is for. Exceptions are for (mostly serious) internal errors.

Sorry, but you don't. I'm not saying this to attack you. It's simply the only valid advice we can give you: You need to learn the basics of variables, functions and object-oriented programming. Right now, you're just writing down random code and confusing yourself. This doesn't work. You need to actually understand how PHP works.

You're so cute.