Jump to content

KevinM1

Moderators
  • Posts

    5,222
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by KevinM1

  1. $var != keyword var
  2. If you're familiar with C++, there's no reason why PHP should be challenging for you, considering PHP is widely regarded as one of the easiest languages to learn. Moreover, you've been given links which go directly to the number_format (look, another one) documentation, which itself has both the function signature as well as a very clear code example that looks at 3 ways to actually use the function. I'm not sure what else you require. We're not going to write your code for you, and you have been given textbook example code. Finally, jesirose is female, so the proper insult would be "internet tough girl/woman."
  3. KevinM1

    HELP!

    Radio buttons are supposed to represent just one thing - like, say gender, where even though there two options (M/F), there's only one possible choice that can be selected. Having an array for radio buttons doesn't make much sense. Check boxes, on the other hand, require arrays because multiple boxes can be checked. In order to do that, simply make their names reference a PHP array: <input type="checkbox" name="someArrayName[]" value="someValue" /> Note how the name has array notation (the []s), but is not a PHP variable (no $) and does not have any index (anything within the []s).
  4. What are you asking? If it's merely "Is a poker app a good way to learn OOP?" then, well, yeah, it could be. That said, a lot of things are good ways to learn OOP, and there's nothing inherent in poker that would make it superior to another form of game, or another kind of app altogether. If you're asking how to build a poker app, well, we don't write full scripts for people. We help people with code they're in the process of writing. So show us what code you've written so far, and we can go from there.
  5. This. Instead of being a lazy twit, either pay attention in class and do your work, or drop/fail out. This kind of behavior is especially egregious if you're in college/university as it's likely you're filling a spot that could be better used by someone who actually gives a shit.
  6. Since we're back to coding questions, the topic has been split and moved. A place for everything, everything in its place. This topic has been moved to PHP Coding Help. http://forums.phpfreaks.com/index.php?topic=363327.0
  7. Have you seen what we, as a society, can do with modern plumbing equipment?
  8. In the future, when posting code on these forums, please put your code between tags. I took the liberty of doing it for you above.
  9. Isn't this a contradiction?
  10. Not Christian, but no, as that function does not escape the data. There's a difference between validating and sanitizing data, and escaping data. Validation and sanitation are about whether or not the data is the right kind of data. Escaping is of a more mechanical nature - it only transforms (escapes) anything in the incoming data that would otherwise be handled specially by the DB. For example, single quotes and semicolons have a particular functional meaning in SQL, so they need to be escaped to be treated as mere normal text.
  11. You can't use header if you've already sent output through the browser. Just another example showing that jumping back and forth between HTML and PHP is a bad idea. Do all of your data handling/processing first, determine if you need to redirect, and, if so, do it right then and there. If not, only once everything has been stored in variables and ready to be displayed on the screen, should you start writing HTML.
  12. Just kidding Congrats!
  13. This topic has been moved to PHP Applications. http://forums.phpfreaks.com/index.php?topic=363301.0
  14. I like the look, but two complaints: 1. The menus are .pdf files. I hate that. You should never, ever, ever force the user to have an add-on and to open another window in order to view what's primarily textual data. There's no reason why you can't incorporate the menus into the site itself, with a printer friendly version available. 2. The background images have a distracting load time and pop-in.
  15. You're going wrong with trying to echo within an echo in that second line, like I originally said. Get rid of the interior echo. If that still doesn't make sense, then stop and brush up on the basics of PHP. I'm getting the distinct impression that you're trying to run before you can walk.
  16. It should be mentioned that as of now (2012), neither MD5 nor SHA1 are good ideas for security. It's arguable that quick hashes were ever good for security. Your best bet is to use PHP 5.3.7+ with crypt using CRYPT_BLOWFISH. To that end, there are pre-made classes/libraries you can use to make it easier to successfully employ CRYPT_BLOWFISH and other security efforts. phpass: http://www.openwall.com/phpass/ (tutorial: http://www.openwall.com/articles/PHP-Users-Passwords) phpseclib: http://phpseclib.com/ (documentation: http://phpseclib.com/manual) If anyone knows of other legit security packages, send me a PM.
  17. Prepared statements automatically escape. That's one of their key features.
  18. This topic has been moved to Application Design. http://forums.phpfreaks.com/index.php?topic=363149.0
  19. It's a matter of slow AND using a good algorithm. MD5 and SHA1 were never meant to be used for password security. They are used for utilities, like checksums. They are very fast and don't have a lot of entropy. It is relatively easy to brute force or find collisions. So, what you need is something that is meant for storing passwords, and that is bcrypt. If you don't want to use bcrypt, you can also be pretty safe using PBKDF2 with SHA512, and 10k iterations or so. An easy way to do that is to use phpass: http://www.openwall.com/phpass/ And a tutorial (ignore any use of the 'global' keyword in the examples, and instead pass your parameters through the argument list): http://www.openwall.com/articles/PHP-Users-Passwords
  20. I came as quick as I could! +1 for this solution.
  21. Even if you just throw a no-repeat on the background images, you'll get the negative space you don't want on the sides with larger resolutions. Not only that, but you'll still get image cropping at lower resolutions (even at a reasonable 1280). Your best bet is to learn responsive design. This is the best source I've found on the subject: http://www.abookapart.com/products/responsive-web-design/
  22. Why not give that div a fixed width set to the width of the photos?
  23. You can't echo within an echo. --- I think you need to step back and reorganize your code. You're falling into one of the classic blunders (no, not starting a land war in Asia), but rather using PHP to echo out a ton of markup. At it's roots, PHP is a template engine. This means that PHP scripts are best served with all of the processing done first, with the results stored in variables, followed by 90%-95% pure markup (HTML, XML, whatever) with just enough PHP (simple echo statements, conditionals, loops) to output the data in those variables at the right spot. In other words, instead of something like: echo "<b>$title - $description - $tmb <input name=\"delete\" type=\"button\" value=\" \">\n</b><br>";} You have something a hell of a lot cleaner: <strong><?php echo "$title - $description - $tmb"; ?> <input name="delete" type="button" value="" /></strong> As you progress in your coding journey, you'll hear the term Separation of Concerns. What that means is that each component of your script should focus on one thing (it's concern) and be as separate as possible from the rest, interacting only when necessary. Echoing markup blurs the separation between PHP and (in your case) XML, which in turn makes your code harder to debug, edit, and maintain. PHP is best used for processing data. Markup is best used to display things. The only time they should interact is when dynamic data needs to be displayed, and in those cases, you're far better off doing the bulk of the work in the markup, using base PHP logic only where absolutely necessary.
  24. This topic has been moved to Application Design. http://forums.phpfreaks.com/index.php?topic=362987.0
  25. Using die isn't usually a good idea in a production site because of the issue you're experiencing. die() is the nuclear, stop everything now way of dealing with an error, and, as you can see, isn't very graceful. Well-formed PHP scripts do all of their processing upfront, before attempting to output HTML. This allows one to redirect to an error page of some sort immediately, if the error is critical, or otherwise collect the errors for display on the current page. It's odd that a forum would use die() simply because a form field wasn't filled out. That's incredibly overkill. Instead of shutting everything down, merely echo the error. That's what this forum does (try replying without actually writing anything).
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.