Because part of the puzzle is in the source code, and if the attacker got the encrypted user table from the common method of SQL injection they don't know the rule which is defined only in the function which checks validation of the pw and generates the pw hash.

What I do similar is,

Pw_hash = hash('f4/$$er3@' + salt + plain_text_pw);

If the attacker only gets the database (which has the hash and the salt) and not the source code they don't have the 'f4/$$er3@' value needed to perform any attacks

There is zero requirement that salts be kept secret in the event of a password database breach. Salts are to prevent users with identical passwords from having identical password hashes, thereby defeating rainbow table attacks (and other attacks involving attackers being able to reuse work from other accounts).

Your approach offers effectively zero additional security; it is trying to add "features" to salting that don't work towards their actual purpose.

Edit: If you want to have something site-wide that an attacker wouldn't have while decrypting an offline password database, the thing you're looking for is an encryption key.

To be honest, there isn't any, when I implemented it I was the tender age of 16 and thought there was some validity in the method, but in itself, once you get to these kind of 30-ish letter long passwords, they become damn near impossible to brute force.

The only redeeming factor I suppose would be that you have to store your random string somewhere anyway, at least this method required code traversal rather than just an SQL field named "password_salt".

well, its a salt, too. just not so random. ;-)