Basically, this is a programming pattern for namespacing code within a WordPress plugin. Typically, you can only have one function called init() in a program, but more than one author will try to use that name. Placing function names in a class is a way around this limitation.
For example:
class Towfiq_Person {
static function on_load() { }
static function init() { }
static function profile_update() { }
}
Rather than calling these directly, you invoke them with the class name as well. So:
Towfiq_Person::on_load();
Towfiq_Person::init();
Towfiq_Person::profile_update();
The section of code you included in your question is the bootstrapper for this class. At the very bottom of the linked PHP file is Towfiq_Person::on_load(), which tells WordPress to execute the static on_load() function of the Towfiq_Person class.
This function wires up various events and filters within WordPress. When WordPress fires it’s init action, it will also call Towfiq_Person::init(). When WordPress inserts a post and fires its wp_insert_post action, it will also call Towfiq_Person::wp_insert_post().
Each line you listed above ties a specific function in the class to a specific event fired by WordPress.
I recommend you read up a bit on Actions and Filters to understand exactly what’s going on, but this is a basic overview.
Update
Based on your further request for information …
We can’t define every function for you. You should really contact the original developer and ask for documentation. But here’s a quick overview.
The get_email_key() function applies a WordPress filter against the string “_email” Essentially, it takes “_email” and passes it through any function that’s tied to that filter before returning it to the user. If you were to call get_email_key() right now, you’d be given back “_email”
The profile_update() function is bound to the profile_update and user_register actions within WordPress. When either of these actions are triggered, WordPress will call your function and pass in the ID of the user being changed and (optionally) the data that was changed.
Your function then does the following:
// Reference the global database object so we can run queries later
global $wpdb;
// We're assuming this is an existing record for now. This will be updated elsewhere
// if necessary.
$is_new_person = false;
// Get data for the user passed in by WordPress
$user = get_userdata($user_id);
// If we have old user data, get the user's email from it. If not, get the user's email
// from the $user object created above.
$user_email = ($old_user_data ? $old_user_data->user_email : $user->user_email);
// Get the email key. Typically this will be "_email"
$email_key = self::get_email_key();
// Get the ID of the person we're working with from the database. We're searching for
// the ID of a post that has meta information matching the email key from above and
// the email address of the user.
$person_id = $wpdb->get_var($wpdb->prepare("SELECT post_id FROM {$wpdb->postmeta} WHERE meta_key='%s' AND meta_value="%s"",$email_key,$user_email));
// If we didn't find a user ID (the ID passed back is null or "false"), then we
// insert a new custom post type "towfiq-person" with the data we need. The title is
// the user's name, the status is published, and we set post meta information so we can
// find it again with the above query.
if (!is_numeric($person_id)) {
$person_id = $is_new_person = wp_insert_post(array(
'post_type' => 'towfiq-person',
'post_status' => 'publish', // Maybe this should be pending or draft?
'post_title' => $user->display_name,
));
}
// Update the user's meta info to map to the new custom post type
update_user_meta($user_id,'_person_id',$person_id);
// Update the custom post type's meta info to map to the user
update_post_meta($person_id,'_user_id',$user_id);
if ($is_new_person || ($old_user_data && $user->user_email!=$old_user_data- >user_email)) {
// Update the custom post type's meta info to map to the user's email
update_post_meta($person_id,$email_key,$user->user_email);
}