scootstah

You can achieve this functionality by catching errors in error handlers, but I don't know of any other way to do it.

Here's the thing though: every time you run that function you are opening/closing a database connection, which is just unnecessary overhead and a waste of resources. Establish the database connection in a single, static location and then at the very least pass the connection resource in global's. Although it's still bad practice, it is better than opening/closing the connection each time a query is run. Yes.

From your example I think your HTML & CSS both look clean. The other way doesn't look clean in either regard. I think his whole thing is that .news-header is faster than .news > header, although he provides no facts to back this up or illustrate the difference in speed.

You can also use http_post_data if you have the HTTP PECL package installed.

Not entirely accurate. FS access doesn't imply root access. Besides that, it's definitely more secure than persisting the values in variables in your code. You mean keeping the login credentials in local variables? Soo... best to keep the login credentials in non-global variables, yes? Like I said, barring a ridiculously foolish mistake the only way the credentials will get out is if someone gains access to the file system - in which case it doesn't matter anyway.

No PHP errors cause HTTP 500, they all send HTTP 200.

global $db_host; global $db_user; global $db_pass; global $db_name; First of all, don't do that. Bad bad bad. You should be connecting to the database in a single, static location - then just include that file when you need a connection. You will have to pass the mysqli object to your functions to work with it, or use some form of dependency injection, or at the very least a Singleton wrapper. All of these are better than what you're currently doing. Secondly your function has far too many responsibilities but beyond that, it doesn't make a whole lot of sense. You are going to be writing the query out to use the function anyway so you can't even argue that it is a query-builder function. I don't really see a purpose to it. With that out of the way, you are using call_user_func_array incorrectly. I haven't tested this but I think the following will work for dynamic parameter-binding. Note that this is a little easier in PDO since you don't need to supply types. // loop through the parameters to figure out the types $types = ''; foreach($parameters as $parameter) { if (is_int($parameter)) { $types .= 'i'; } else if (is_float($parameter)) { $types .= 'd'; } else { $types .= 's'; } } // add the types to the beginning of the parameters array array_unshift($parameters, $types); call_user_func_array(array($stmt, 'bind_param'), $parameters);

I think you misunderstood me. If you have file system access you can upload a script that can manipulate the database. It doesn't matter where you define the connection, because if a connection exists any script in the file system can utilize it. So while you may not actually be able to see the credentials, you can still do anything you want to the database since you have an active connection. For this reason alone, the location of the credentials is irrelevant. If they are stored in a .php file an attacker requires file system access to view the .php file and get the credentials - which is completely moot because if they have file system access you are already screwed.

Is that before or after hosting/bandwidth costs?

What are you talking about? These changes are made once, not every time someone uploads files.

You are missing the point here. Let's break it down: 1. Rename existing "uploads" folder to "uploads.old". 2. Use PHP to create a new "uploads" folder; mkdir('uploads'); 3. Use PHP to CHMOD the newly created "uploads" folder; chmod('uploads', 0755); 4. Copy the contents from "uploads.old" to "uploads". 5. Delete "uploads.old". Whenever someone uploads something in the future, it will go to the newly-created "uploads" folder - you don't have to do anything.

Not entirely accurate. FS access doesn't imply root access. Besides that, it's definitely more secure than persisting the values in variables in your code. But they can still upload a script to manipulate the database. EDIT: And how is it more secure? The only way anyone will ever see the credentials if you store them in variables is: - by accessing the file system - you echo'ing them You could argue that you might have a security hole where the credentials get echo'd...but that would be a ridiculously amateur thing to happen, so the only real threat here is gaining access to the file system. And assuming someone does somehow manage to get your credentials, your database server should only be accepting a local connection anyway - therefore nobody can connect remotely, and in fact the only way to manipulate the database would be, again, access to your file system.

Huh?

I tend to do things like this as well. Granted, it may be easier to quickly figure out what goes where if you used separate classes, or even multiple classes (the generic .author class and then more specific ones like published-by-author, comment-author)... but it still seems like more work to me. EDIT: Just curious, is there any specific reason for using OL over UL for breadcrumbs?

But there are many T_ tokens. If you conclude that the T stands for "type" in a token that happens to reference a type (in this case "string"), then what does the T stand for in things like T_EXIT, T_PRIVATE, T_NAMESPACE, etc? None of these are types. It is only logical that it means token.

This should work too: echo implode(' ', $pers['Steve']); Yeah, in that case that will work just as well, but you might want to be careful. In general associative arrays aren't required to have an associated order. With PHP order will be maintained in associative arrays since they're implemented as essentially being hash tables, but you shouldn't assume this in general. For example, if you want to achieve associative array functionality in JavaScript you're going to have to use objects (which aren't "real" associative arrays for other reasons but that's besides the point in this example) which are an unordered set of name/value pairs, so it's not guaranteed that order will be preserved. So imagine that this array was coming from JSON data, you have no real way of ensuring the order is going to be what you expect, so the output might not be in the order you were after. Very true, thanks for pointing that out.

Keep in mind that if someone gains access to your file system, setting the username/password in the php.ini is completely irrelevant.

No, but why would you want it to be? Are you really going to have a UL nav in one spot and an OL nav in another spot? That seems weird to me. I get the whole "global object" thing but I don't necessarily see a strong use-case here. I mean, not every class needs that functionality. Sometimes you do, sometimes you don't. I really don't think there is an end-all solution here, which is sort of the vibe I got from the article.

This should work too: echo implode(' ', $pers['Steve']);

You are passing bind_param a single parameter. You can't just pass in a comma-separated string and expect to have multiple parameters, it doesn't work that way. It should be like this: $stmt->bind_param('iiisis', $user_id, 1, 0, $lang, 1, $newLink); You can however use call_user_func_array to call the bind_param method, but IIRC it is a pretty sloppy-looking alternative.

Why not alter the structure slightly by grouping the request and response classes under a Http namespace..? You still have well organised classes, but remove the need for generic names. I agree, that looks a lot neater.

I feel that he is breaking CSS down to be as simplified as possible. The resulting code would look like someone who knew only how to use ID and class selectors. Maybe I am talking out of my ass but I really doubt there is a significant difference between ul.nav{} and .nav{}. EDIT: Also, I feel that you are really limiting what CSS can accomplish this way. You are going out of your way to avoid using descendant selectors and such, which just seems sloppy. Unless someone can show me that descendant selectors are dramatically slower I will continue using them. To me, this just looks like the micro-optimizations that are common in PHP. Like only using single quotes instead of double quotes, or if (!$var) instead of if (is_null($var)). Technically it's faster, but the difference is likely immeasurable in most situations.

Just to be different... if (in_array($nr, range(5,50)))

I believe the function is supposed to be a general purpose function, not limited to just this snippet.

empty() will return true if there is a value of 0. So, if you want to allow the value "0" you can't rely on empty(). Although since there is no strict comparison to 0, it is still flawed... since empty == 0. It should be: empty($_POST[$requried_fields]) && $_POST[$requried_fields] !== 0)