Jacques1

Now you're setting the $db variable to null after you've printed the test result. That's a bad idea, because now $db definitely isn't a PDO connection. Remove the assignments and try again.
 
 
 
 
PHP has a password hashing API which hides all the low-level cryptography behind a few simple functions. To hash a password, all you have to do is call password_hash():
<?php // password hash parameters; put this into a separate configuration file const PASSWORD_HASH_ALGO = PASSWORD_BCRYPT; // bcrypt is currently the only choice const PASSWORD_HASH_COST = 14; // adjust this to your own hardware (hashing a password should take roughly one second) const PASSWORD_MAX_LENGTH = 56; // bcrypt has a maximum input length of 56 bytes $test_password = 'zkWMfOmSTPS4wY8C8BzCaG'; // create a hash from the plaintext password if (strlen($test_password) <= PASSWORD_MAX_LENGTH) { $password_hash = password_hash($test_password, PASSWORD_HASH_ALGO, ['cost' => PASSWORD_HASH_COST]); echo 'The password hash is: '.$password_hash; } else { echo 'The password must not be longer than '.PASSWORD_MAX_LENGTH.' bytes.'; } To verify a password against a hash, you just have to call password_verify():
<?php $password_hash = '$2y$14$5ue3w80sIho.B5GjqlppB.nwwnpUL3WN8re5peY3sRJ.w5idlgmKC'; $test_password ='zkWMfOmSTPS4wY8C8BzCaG'; if (password_verify($test_password, $password_hash)) { echo 'The password is correct.'; } else { echo 'The password is incorrect'; }  
Because this function mangles the input in a primitive attempt to remove HTML tags. This is nonsensical and will lead to data corruption. For example, the perfectly valid string “1 < 3” will be truncated to “1 ” just because it happens to contain the “<” character.
 
Never change the user input. Store it as is. When you need to insert the data into a critical context, use escaping (e. g. htmlspecialchars() for HTML contexts).
 
 
 
 
There's no need to clutter your code with try statements and stuff like echo $e->getMessage(), because PHP itself is perfectly capable of printing error messages. Simply enable display_errors in your PHP configuration and set error_reporting to -1. Now all unhandled errors will be printed on the screen. If you want the message to be nicely formatted, you can use the Xdebug extension.
 
When the code goes into production, you turn display_errors off and enable log_errors instead. This is much safer than having to remove tons of try statements, because there's no risk of overlooking one of those debug statements and accidentally revealing information about your server.
 
In general, you should leave exceptions alone and let the PHP error handler do its job. Catching an exception is only needed if you have a specific solution to this specific error, which is rare. Most problems cannot be solved at runtime.

So you're saying that when you var_dump() your $updateid variable, literally copy it into the query string and run the query, you do get results? Are you sure you're accessing the right database? What happens when you hard-code the ID into the PDO query?

PHP code runs on the server, cookies are managed by the client. That means deleting a cookie can only take effect after the code has been executed and the client has received the response.
 
I recommend that you use the developer tools of your browser to see when cookies are set and deleted.

The manual suggests INT UNSIGNED for IPv4. Since IPv4 addresses cover only 32 bits, they fit into an 32-bit integer type. IPv6 addresses cover 128 bits, so they cannot possibly fit into any integer type. Hence my confusion as to what you actually want.
 
It's unclear to me why you'd want to use LONG. This is a special compatibility type for exchanging code between MySQL and a non-MySQL database system. It's also a text type as opposed to a binary type, which means it uses a character encoding and sorts by a character collation. None of this makes sense for purely binary data like a raw IP address.
 
So you'll want the binary type VARBINARY(16). This can store up to 128 bits.

Using absolute paths and then expecting them to somehow be turned into relative paths is a really, really bad idea.
 
The path
/includes/file-name.php is absolute and literally means: “Right below the root filesystem, there's an includes directory with the script file-name.php”.
 
This obviously makes no sense. Maybe your Windows PC interprets the path differently, but all Unix-based servers will see an absolute path.
 
If you want a path to be relative to some base directory, then you actually need a relative path. Use the include_path directive to set the base directory:
// assuming C:/htdocs/ng is in your include_path include 'includes/some-file.php';

Well, “data:image/gif;” certainly isn't valid Base64. So you have to extract the actual image data before you decode it.

You've mixed up two naming styles: $this->allowedTags isn't the same as $this->allowed_tags. If you fix this, you can in fact define the attribute in the class body.
 
Is this the best approach? Well, it's difficult to tell given this very abstract code, but hard-coding the tags inside the class means you won't be able to ever change them (unless you change the class definition, of course). It might make more sense the define the tags outside of the class and pass them through the constructor.

Your code generally doesn't make a lot of sense. What is the query
SELECT password FROM users WHERE password = supposed to do? You take the submitted plaintext password and then try to find the exact same string in your database? Aren't your database passwords hashed?
 
I guess what you actually want is get the password hash(!) for the provided username:
SELECT password FROM users WHERE username = :username It might be a good idea to rename the column "password" to "password_hash" to avoid this confusion in the future.
 
You have a lot of other weird parts in your code, so I strongly recommend you go through this line by line and carefully test each part with var_dump(). Don't just write down one big block of code and test it afterwards, because this makes debugging much harder.

I understand that you have multiple Jabber servers, but that doesn't mean you should have a separate database for each one of them. Or is this a specific requirement of the Jabber implementation you're using?
 
Anyway, if you absolutely need multiple databases, create an array which maps the different servernames to different MySQL connection parameters:
<?php $jabberDatabases = [ 'jabber1.example.com' => [ 'host' => 'localhost', 'user' => 'user1', 'password' => 'pw1', 'database' => 'db1', ], 'jabber2.example.com' => [ 'host' => 'localhost', 'user' => 'user2', 'password' => 'pw2', 'database' => 'db2', ], ]; Given the name of the jabber server, you can select the corresponding parameters for mysql_connect() and mysql_select_db().

That's a bit strange, but there's no rule saying that WP malware can only infect WP-based applications.
 
Anyway, all of the above still applies. If you've written the code yourself, replace “Update your application” with “Learn the basics of PHP security and fix your code accordingly”.

The easiest option is to send the appropriate content type with header() and then show the file content with readfile().
<?php header('Content-Type: application/pdf'); readfile('/path/to/pdf'); A more sophisticated and efficient approach is to delegate the file transfer to the webserver:
mod_xsendfile for Apache X-Accel for nginx

It's difficult to give advice for this extremely abstract scenario.
 
Generally speaking, a method should make sense on its own and not have hidden dependencies all over the place. You should be able to give a clear description of what this particular method does. If you cannot do that, you should refactor it. Maybe you need an additional parameter, maybe you need to break the logic into multiple methods, maybe you have to do a lot more. That depends on the actual problem (which you haven't stated yet).
 
Callbacks do make sense in some special scenarios, but you shouldn't use them as a standard pattern. When you're starting to pile up closures and your requirements are becoming weirder and weirder, it's definitely time to stop.