$ValidUser = new VerifyLogin($_POST['username'], $_POST['password']);
if($validUser) //…

First: now that you modified the method to not be a constructor, the construction could should be updated too:
$ValidUser = new VerifyLogin();
//…
Second: you have the variable name starting with different cases: you have $ValidUser assigned to your VerifyLogin instance and you check for $validUser in the conditional.

Third: after you fix the variable name, the condition will always evaluate to true because $ValidUser is an object, and that would impose some very serious security problems :D The condition should be spelled
if($ValidUser->verifyCredentials($_POST['username'], $_POST['password']) //…

Fourth: even the variable name is misleading. After moving the authentication logic from the constructor to the verifyCredentials method $ValidUser does not at all denote a valid user! That name should be changed.

And the last problem is what Dave already mentioned, I will not repeat him. This problem is related to what you write in your recent article (the one about multiple levels of inheritance). The authentication process should be separated from the actual representation of users. The statement VerifyLogin IS A User does not make sense at all!

I would advise that you review your articles more thoroughly. Clueless noobs may find them, and without the same background as seasoned veterans they might take your code or worse your flawed concepts for granted, and replicate it in their designs! I actually found this post through the feed of Planet PHP, and given that popularity is power, the Spiderman principle should apply :)

The real problem is that the OO model you’ve chosen isn’t very sensible. Why should verifyLogin be an object? Personally I would have an AuthenticationHandler which is responsible for maintaining the global state. This could be an interface with site specific implementations but it maps much better to the necesary global state because you can at least make it a singleton.

Art

class DBAuthenticator {
/** @param resource $db The database connection to use, which is a dependency */
public function __construct($db) {}

/**
* @return int User ID
* @throws Exception No such user
* @throws Exception Invalid login
*/
public function authenticate($user, $pass) {}
}

class User {
public $id;
}

// Setup
$user = new User(); // Your model/data structure
$storage = new DBStorage(); // A layer to load and populate your models
$security = new DBAuthenticator($db_connection);

// Wiring
$user->id = $security->authenticate($_POST['user'], $_POST['pass']);
$user = $storage->load($user);

That neatly splits:
* The authentication method (“Are these credentials allowed to access my resources”) from the user profile
* The authentication backend (database) from the user profile model

Changing the security mechanism from DBAuthenticator to MockAuthenticator or LDAPAuthenticator is then trivial, too.

Your point itself though is completely valid and I’d even extend it to say that classes should not use _any_ global variable at all. Everything should be either passed in via a constructor/function or, in the case of cross-object internal data, stored in a static class variable.

Aside of these things what you say is good and correct. Global state is evil. :)