1. $current_user = wp_get_current_user();
2. $current_user_role = ($current_user->roles);

I've recently started working on a custom module in Drupal 6 and i really disliked the idea to use built in functions for tables and/or to use embedded html into my module.

if you want to change all files owned by an user to be owned by a different user, there is a trick. figure our old owner id. for example with

ls -n

this will list you numeric ids of the owner. use the id with the command bellow

find /path/ -uid numeric_uid -exec chown newgroup.newuser '{}' ';'

In case you wanted for eg: change all your innodb tables into myisam, and you didn't want to go over the tables one by one, you can do the following queries.

1. USE information_schema;
2. SELECT TABLE_SCHEMA, TABLE_NAME FROM TABLES WHERE TABLE_SCHEMA = "your_table_name";

If it returns what you need ?

1. SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA,"`.`", TABLE_NAME, "` ENGINE = MYISAM; ") as MySQLCMD FROM TABLES WHERE TABLE_SCHEMA = "your_table_name";

webmin and centos will usually default to bind-chroot installation and webmin will have the chroot paths set for named.conf
for some reason, in my centos 6.2 setup there was a folder permission issue which prevented the pid file from being created.
chmod 770 /var/named/chroot/etc/
and then it started

one more thing to pay attention to. if you setup virtualmin and use the local named for your domains, then you have to set 127.0.0.1 as the first entry in /etc/resolv.conf

After some digging, it appears that mailbox_size_limit and message_size_limit variables are stored as int.
So even if you set them correctly make sure they're not over the int limit (2147483647)

Daniel wrote a nice article on phpfreaks.com describing why it's bad practice to use "or die()" in your php code.

Reasons such as:

1. It's not a very nice way to present the user with an error message.
2. Using for instance the mysql_error() call with it, as many people do, exposes information that should never get output in a production environment
3. You cannot catch the error in any way.
4. You cannot log the error.
5. You cannot control whether it should be output to the screen or not. It's okay to do that in a development environment, but certainly not in a production environment.
6. It prevents you from doing any sort of cleanup. It just ends the script abruptly.