Jacques1

This thread is from 2011. Most of the people aren't even active any longer, and they won't come back just to give you personal support. Create your own threads with your own code. The glob() function will help you.

Calling this is a “solution” is somewhat overly optimistic. As long as your database layout is fundamentally broken, you'll run into problems over and over and over again. This was a friggin' data lookup, one of the most trivial operations possible. Yet you needed two communities, dozens of lines of code and probably many hours or even days to get it done. Now imagine having to solve a real problem. I don't know where you got your “plugin” from, but I suggest you either fix it or throw it away altogether. It also helps a lot to use proper English names, because that's the de-facto standard in programming and makes sure everybody can understand you. I'm not going to run each line of your code through Google Translate, especially when the translation results are utter nonsense (I can't tell if that's your fault or Google's). With a correctly designed database, the entire lookup is just one trivial query: $stmt = $databaseConnection->query(' SELECT somecomplex, someplace FROM idontknow WHERE somenumber = ? '); $stmt->execute([$_GET['somenumber']]); $result = $stmt->fetch(); // if you expect more than one match, use fetchAll() if ($result) { echo 'Somecomplex '.html_escape($result['somecomplex']).', someplace '.html_escape($result['someplace']); } else { echo 'Invalid number.'; } No loops, no flags, no filtering. Just plain old SQL.

I suggest you finish your work and then show us the real script, not some fantasy code. Like I said, the default parameter stuff is completely unnecessary if you write proper code, so the undefined index problem should actually go away as soon you add the missing parts.

No need to apologize. I'm simply pointing out that efficiency isn't the issue here. Choose the most readable solution. If it makes sense to only fetch the title, that's perfectly valid. It doesn't matter if you need a few extra queries, because there won't be any performance difference at all.

More importantly, you need to start thinking about security and robustness. Websites are public, which means you'll get all kinds of requests from all kinds of sources. Not all of them are valid and friendly. There will be invalid requests, malformed input, automated attacks and maybe even targeted attacks. Your application has to survive those. Right now, the script has no security or robustness whatsoever. Anybody can write arbitrary data to arbitrary files without any validation. They can upload malware, overwrite existing files and even leave the document root to screw up your server (nothing prevents them from using “../” in the filename). On top of that, the code is wide open to cross-site scripting attacks. Programming is a lot more than making error messages go away. You need to actually think about what you're doing (yes, even as a newbie). In your specific case, I recommend you forget about creating files on your server. It's simply too dangerous as long as you don't understand the implications. You should store the text in a database instead. I'm sure you have one installed already.

This discussion is silly. Every nontrivial web application makes dozens or hundreds of queries per request, and modern database systems can easily handle this. That's what they're made for. Even complex queries involving millions of rows (not just some title lookup) are no problem at all as long as you use proper indexes. Query results are also cached, so the query isn't actually executed “for every visitor”. Stop trying to solve problems that aren't there.

No, this is not a good approach. First off, your code is wide open to cross-site scripting attacks. You can't just insert user input straight into your HTML document, because this allows anybody to inject malicious scripts, manipulate the page content or do anything they like with your markup. All dynamic HTML data must be HTML-escaped. Secondly, if the client hasn't sent you the required parameters, that's a fundamental problem (possibly even a bug). Trying to cover this up with fantasy defaults makes no sense. The proper reaction is to show an error message, set the appropriate HTTP status code (e. g. 400) and terminate the script. If you want to use the $_post array solely for your form defaults, well, that's at least possible. But it's still confusing and not really worth it. Just write proper code with checks, then you won't run into undefined indexes. <input type="text" name="username" value="<?= isset($_POST['username']) ? html_escape($_POST['username']): '' ?>"> If you don't like to write down the same stuff over and over again, use a proper template engine like Twig. This will also help you with your XSS vulnerabilities.

The POST parameter is called course, but you're trying to fetch course_id. Whenever you have trouble with form parameters, it's a good idea to actually inspect them: var_dump($_POST); This quickly reveals all misunderstandings, typos etc. But more importantly, your code is full of security vulnerabilities. You sometimes apply SQL-escaping (based on your current mood rather than technical criteria, I guess), but most of the time, you just dump the user input straight into your queries and HTML markup. This leaves you wide open to SQL injection attacks, cross-site scripting, cross-site request forgery and whatnot. Learning how to use mysqli properly is unrealistic in my experience, so I suggest you switch to PDO. Then you'll need to learn the basics of safe programming (as opposed to: let's write some code and hope nobody will bother to break it).

Let's try that again, this time with code tags so that we might actually be able to read what you've written. See the blue “<>” button in the editor? Click on it, paste your code, click “OK”. Then preview the post to make sure it's readable. Finally submit the post.

The string returned by KeyCAPTCHA_CLASS::render_js() must be inserted into the form at the exact location where you want the CAPTCHA. This would be a lot easier if you (or the code author) had properly separated the HTML markup from the PHP code. Now you need to split your HTML string to inject the CAPTCHA snippet: $content = '<other elements><form><prior input elements>'.$kc_o->render_js().'<next input elements></form><other elements>'; In the long run, however, you'll need an actual programmer to fix the mess.

Big corporations don't necessarily make smart decisions. The financial industry in particular is full of absurd policies, crazy rituals, legacy garbage and plain incompetence. For example, some banks have blacklisted words like “select” and “drop”, because they believe this is how to deal with SQL injection vulnerabilities. A lot of big websites don't let the user copy and paste the password into the log-in form, which makes it very difficult to use strong passwords stored in a password manager. And then there's the password policy madness. The rules and restrictions make no sense whatsoever from a technical standpoint. They're arbitrary and counter-productive. For example, I'm used to generating long, purely random passwords, and many amateur sites can handle those just fine. But several big “professional” websites force me to reduce the length, reduce the character space or introduce patterns, which means I have to sabotage my own security just to make some fucking validation procedure happy. Learning from others makes a lot of sense, but learn from smart programmers, not big companies.

Never remove any characters from a password. This is extremely dangerous, because it weakens the input. For example, running the strong password <(MX/aw9O(DK through strip_tags yields an empty string, which means you've literally removed the password from the account. In fact, you shouldn't manipulate any user input. You're free to validate and reject data, but silently changing it can have bad consequences ranging from total confusion to serious security vulnerabilities (as you just saw). If a website doesn't accept “special characters”, there's something wrong. Either they're trying to cover up bugs or vulnerabilities. Or they simply have no idea what they're doing and make up arbitrary rules. In both cases, I'd be worried. Passwords should generally have no restrictions at all. There are only two exceptions: technical limitations of the password hash algorithm and usability issues. For example, the bcrypt algorithm chokes on null bytes and very long strings, so it's OK to reject those (there are smarter solutions, though). And it makes sense to only allow printable characters, because anything else was probably sent accidentally. Note that SHA-1 is completely unsuitable for password hashing, because it can easily be attacked with brute force. Current GPUs are able to calculate billions of SHA-1 hashes per second. You need an actual password hash algorithm like bcrypt. This is available through the Password Hash API.

You should actually combine the data extraction with validation. Always expect to get wrong input. Regular expressions can help you: '/\\A(?<gender>3|4)(?<dob>\\d{6})\\d{4}\\z/' Read: A 3 or 4 followed by 6 digits for the date of birth followed by another 4 digits. You can then easily extract the ID parts: <?php const ID_PATTERN = '/\\A(?<gender>3|4)(?<dob>\\d{6})\\d{4}\\z/'; $input = '39310121111'; // validate the input and simultaneously extract the parts $idParts = null; if (!preg_match(ID_PATTERN, $input, $idParts)) { die('Invalid input. Please enter a valid 11-digit ID.'); } // the individual parts var_dump($idParts['gender'], $idParts['dob']); Storing the year of birth as two digits isn't very smart, because now you need extra logic to distinguish between 19xx and 20xx. Let's not repeat the 2K problem.

I think I've answered this question at least three times now. No, Twig is not just PHP. It's far, far more powerful than PHP when it comes to templating (see #9 for a detailed description), simply because it's a dedicated template engine. Yes, both PHP and Twig can assemble HTML from files, just like both a Porsche and your old bicycle have wheels. We care about the extra features which make one tool more useful than the other. Does PHP have template inheritance? No. Does PHP have auto-escaping? No. Does PHP have sandboxing? No. It has nothing but a bunch of low-level insertion routines. If you want to stick with PHP, that's OK. But if you're open to learning, I suggest you stop the silly comparisons and simply try Twig. I think the benefits are very obvious when you actually have to generate a non-trivial HTML document.

The form builders of frameworks have been carefully written by professional developers, and they've done it on top of an entire framework infrastructure. This is very different from an inexperienced programmer (I don't mean that as an insult) who outputs a bunch of HTML fragments and hopes this will work. As we've said multiple times, this is about best practices and realistic solutions rather than technical possibilities. Sure, from a purely technical standpoint, you can assemble your HTML markup from lots of different functions. This is what many PHP people did in the late 90s, and it's still popular among beginners who have never heard of template engines. The problem is that you will likely end up with an entire zoo of security vulnerabilities and an unmaintainable mess of PHPHTML spaghetti code. So maybe not everything that can be done should be done. Maybe it's a good idea to choose the right tool rather than any tool. By the way, form builders only make sense when you have highly dynamic forms which require a lot of code. If you just want to output a simple form with some parameters and maybe a few control structures (loops, conditionals), this can easily be done within Twig. There's no need for any form building magic.

If you want to learn, you need to actually start programming. You know, writing your own code with your own hands. As the others have already said, your task cannot be solved with PHP. It's a JavaScript problem (of course you could combine the two, but this makes no sense in your case). So do you want us to move this to the JavaScript section, or do you want to rephrase the question? For example, you can do it with PHP if the calculation happens after you've submitted the form. In any case, start writing code and solving your own problems. Of course we can help you with specific(!) questions, but don't just ask us to do the work for you.

Sure. I was just trying to get more information from the OP in case the problem is legitimate but poorly described.

For the record: You can hide file paths behind a separate PHP script which acts as a proxy. <img src="img.php?id=c8aa0b77cb24a866e1987bae07955e69" alt="..."> However, this only makes sense if the script actually provides a benefit (access control, security, ...). If you merely map one file path to another file path, why not just rename the file?

Why do you think you need this? What is the “masking” supposed to do?

I've already told you what to do: Put the array initialization before the loops, so that they only happen once and aren't repeated in every iteration. You want to keep the same array throughout all iterations.

This code snippet doesn't tell me anything. I need to see the context. It doesn't matter if you have three arrays or one. If you overwrite them, you overwrite them. I'm not sure why this is so hard to understand.

You still keep overwriting your arrays, except that you now overwrite three arrays instead of one. This doesn't help. You need to actually understand the code and put the initialization where it belongs (probably before all the loops). By the way, your PHP syntax is very strange. This endif stuff is only meant for templates, not code. PHP code looks like this: if (...) { ... } else { ... } You know, like in C or Java.

You realize that you overwrite $active_banner with an empty array within your loop, right? Are you sure this is what you want?

How about we start worrying about the real issues? If the OP walks away with that code and tells everybody that kicken from PHP Freaks has OK'd it, that would be pretty embarassing, don't you think?

The whole code has no security whatsoever, which is particularly disastrous when you're writing an abstraction layer like this form builder. As soon as you (or worse: somebody else) use the builder with dynamic parameters, you end up with bugs and XSS vulnerabilities all over the place, and it's not even clear where on earth they come from, because all the markup is hidden within the class. The class design isn't very good either. Long switch statements are in warning sign in OOP, and indeed your class is just one monolithic block of procedural code. The only realistic way to modify or extend the functionalities is to edit the source code – which is the opposite of OOP. Even worse, you have hard-coded design elements (<p>, <br>, <div>) everywhere, and they depend on each other, which means the class really isn't a form builder, at best it's a shortcut for your own (rather quirky) form fragments. It's not useful for anything or anybody else. Besides that, I still haven't figured out why PHP people love to create their own “form builders” so much. This piece of code $regform->newLabel('password', 'Enter password:'); $regform->newInput('password', 'password', '', 'Enter Password', 'form-control', 'password'); could simply be written as <label>Enter password: <input id="password" class="form-control" type="password" name="password" placeholder="Enter Password"></label> This has less characters and is arguebly a lot more readable, so how exactly is the form builder useful? Personally, I would drop the class and use good(!) old HTML instead. Note that Twig has macros, so you can always define shortcuts for HTML fragments. If you absolutely must use a form builder, you should either use a proper library or actually spend a lot of time on the class design (and security). A good class has to do more than barely “work”.