KevinM1

Not to mention that you're still blindly using $_GET['id'] in your queries, even after being told to validate and sanitize it. You need to do something to it - is_numeric, ctype_digit, test it against a regular expression, pass it through a sanitize filter - to ensure that: A. It's safe B. It's the kind of data you expect

Eh, most Transformers were just repackaged Diaclone toys. The Japanese designation fits.

I don't think it's worth it. Hot or not sites haven't been popular for years. Think about it: Since the site's sole purpose is to objectify people, you have to ask who its audience would be. Most people don't want to be oogled at and/or insulted for their looks. And that's on top of there being no way to verify that the pics are of the people posting them, and having to handle disgusting picture spam. Make something fun or useful, not something that highlights the worst of the internet.

Because they both have annoyingly long syntax. Then write a wrapper?

Why reinvent the wheel? Look at: mysqli pdo

Use GET when retrieving data, POST when inserting or updating data.

Brackets are necessary when you want to have the value of an array element be interpolated directly in a string. It basically says "Whatever is inside the brackets should be interpolated." I hate dropping in and out of a string to print an array value. To me, this: echo "Some db data: " . $row['id'] . " -- " . $row['title']; Looks ugly. echo "Some db data: {$row['id']} -- {$row['title']}"; Looks better, is simpler to write (fewer characters), and saves me from keeping track of all the .'s in my string.

Ah, don't worry about those. They were used to ensure that array_filter successfully removed array values that would be considered false. Just test data on my end, so feel free to remove them.

Easier to just: <?php echo "$city, $full_state $zip"; ?> Placing variables in double-quoted strings will echo their values.

That's fine.

You should check to see that $_POST['id'] is, in fact, an integer (assuming that's what you want).

You could always re-read this thread. I'm partial to reply #3.

Can you show the class code? Easier to diagnose with actual code.

Part of the problem is that array_filter keeps the initial keys of the array, so it makes it hard to find the last element. You can't simply write something like: $a[count($a) - 1] = "and {$a[count($a) -1]}"; I suggest simply making a new array. Working example: $a = array("pigs", "horses", "cows", "chickens", null, "dogs", ""); $a = array_filter($a); $b = array(); foreach($a as $v) { $b[] = $v; } $b[count($b) - 1] = "and {$b[count($b) - 1]}"; echo implode(", ", $b);

Stop. Just stop. You're throwing a bunch of code at the wall hoping that something will stick. What is it you're trying to do? What's your data, and what is the desired result? Because right now you've over-engineered whatever you want to do to the point of gibberish.

There's never a need to use 'global'. Argument lists exist for a reason. It's especially egregious to use 'global' in an OOP setting, as it creates a hidden link to an outside context, thereby coupling the object to its environment. Simply put, if you're using 'global', you're doing it wrong. I'm sorry to bring this topic back again but, do you really mean that "global" shouldn't be used in OOP methods? Sometimes I need a lot of global variables, if I pass them as arguments it would make my class look ugly, (20+ arguments for one method)... Usually I need the $database, $template, $language, $settings variables which are elementary for many classes... "global" makes it a lot easier, can you please tell me why it's not a good thing to use "global" in OOP methods? Because even in PHP documentation, they use that : http://php.net/manual/en/language.variables.scope.php Thank you 'global' ties a particular function/method to a particular context. That's the antithesis of modularity. How? By creating a hidden requirement for that function/method. One of the core tenants of OOP is 'code to an interface'. All objects have an interface - their publicly accessible methods. Moreover, every method has a signature: their name, argument list, and return value. This allows methods to behave as black boxes, whereby certain things (what's in the argument list) are passed into the box (the method itself), and something comes out the other side (return value). How the internals of the box work are immaterial so long as the signature is known. 'global' throws a monkey wrench into the whole thing because it's not part of a method's signature. This creates an implicit requirement, known primarily only by the method itself. That, in turn, requires whatever code is trying to invoke that method to have to know about the innards of the method. That creates a tight bond between the method and its calling environment. Then there's the issue of scope. Objects are supposed to be encapsulated - distinct entities with clear boundaries, where the only thing the public knows about them are their interfaces. 'global' kills encapsulation in two ways: 1. As I said above, it makes it necessary for external code to know something about the guts of the object in order to use it. 2. Since global variables are always available, the object's boundaries crumble. Anything can enter an object from anywhere, at any time. Keep in mind, the same arguments can be made for using 'global' with regular old functions. If you're looking to write modular, reusable code, 'global' is the wrong way to go. Yes, using 'global' is easy. It's a crutch, and all it does is introduce bad habits that lead to spaghetti code. And, if you'll note, the link you provided merely illustrates how scope works in PHP. It's not endorsing the use of 'global'. The vast majority of code examples on the PHP site do NOT use 'global'. Finally, if you have 20+ parameters for a method, that's a sign that your design is critically flawed. Can you show an example?

Yes. Like I said above, they're WYSIWYG - What You See Is What You Get. Back in the day, Geocities had one. It sucked. What? Hackers write scripts that point to another domain. It's not hard. And no, they don't point-and-click their way to success. Someone must still code that first program that generates the dynamic code. Nothing simply springs into existence fully formed. But, really, the problem here is that you don't understand how computers, software, or the web actually work. No WYSIWYG program can account for all possible actions a website may have to execute. Even industry leading solutions like Dreamweaver simply contain a list of snippets that address common problems. Anything more involved always requires getting your hands dirty and writing code. Especially if it's something more complicated than, say, a blog. Try getting your hands on a good WYSIWYG program, or search for a web-based one. Take note of their similarities and shortfalls.

Probably. Still, the critique is valid, IMO.

That header graphic is horrid. Looks like the woman's picture was taken on a whim in an office hallway one random afternoon, and the rest is bad fonts on top of clip art. It just screams amateur/10 minutes of work. Also, are your 165 prospects supposed to know who Sheila Griffin and Jo Evans are? What are their qualifications and experience? I mean, right now the page is saying "Two random women want you to pay them $21 for health tips of unknown quality." That isn't really going to entice anyone to shell out cash.

#2 is more widely used. You also seem to have some confusion about how the HTTP request cycle works. Disregarding caching, there's no difference between requesting a new page or the same page. A HTTP request is made to the server, and a new page is served to the browser. The process is exactly the same. You're not saving ANYTHING in either option. In option #1, your external validation file will still be executed every time the form is submitted. In option #2, you're requesting a new copy of the current page, which is functionality the same as sending the data to a separate file. The ONLY difference between the two - assuming #2 is structured properly - is an if-conditional that runs the form processing code if the page was accessed via POST. Which is, of course, negligible.

What are you having trouble with, specifically? I ask because you simply need to be able to understand example 2 from: http://www.php.net/manual/en/features.file-upload.post-method.php and know how to write and execute an INSERT statement. Do you have any code for us to look at?

What? The use of the 'var' keyword is deprecated. It's a PHP 4 construct.

What you really want to do is create a WYSIWYG site editor/builder. Here's the thing, though - they have limits, too, because it's impossible to take into account every possible thing a user would want to do on their site. They tend to be 'dumb' out of necessity. They'll never be able to make something as good as what a professional does if they can't/don't want to touch code.

Ah. Basically, it would be: JavaScript click event -> asynchronous call to PHP script -> PHP-to-service call* -> service processes the data* -> service-to-PHP* -> PHP-to-JavaScript I'm not sure if what I listed with * will work the way you want. It depends on what you mean for 'waits for a response.' Also, depending on what the service expects, you may need to use cURL to send the data from PHP to it.