[RFC] profile_update hook

[Jhong]

Name: hook_profile_update
Rationale: Third-party components can be notified whenever the user updates their profile, or an admin updates a user's profile, and take actions accordingly.
Placement: Currently, this needs to occur in several places:

For updating after a profile change:
In ucp_profile.php, after:

Code: Select all

// Update Custom Fields

For updating after an avatar change:
In ucp_profile.php, after:

Code: Select all

			if (isset($sql_ary['user_avatar']))
			{
				$userdata = ($custom_userdata === false) ? $user->data : $custom_userdata;

For updating after an admin changes are user's profile:

In includes/acp/acp_users.php, after:

Code: Select all

						add_log('admin', 'LOG_USER_USER_UPDATE', $data['username']);	

And also in includes/acp/acp_users.php, after:

Code: Select all

						// Update Custom Fields

However, I have to do it this way right now in order to intercept the appropriate profile information. Ideally you could simplify the attach point.

Input arguments:

string $update_type: whether this is an avatar update, a profile update, etc.
integer $user_id: the user ID
array $before_update: an array of all profile fields before update
array $after_update: an array of all profile fields after update

Output arguments: void.

Related: If the mod wants to modify the profile fields, there should be an additional hook, hook_pre_pfofile_update, that would inject data and return the $after_update array.

[gn#36]

I'll post the same thing here: It would also be nice if the "before" hook were able to deny changes alltogether (or reject parts of the changes). A GEO Mod might check the entered location for example, or one might wish to restrict the Homepages to some special domains.

[EXreaction]

This would be nice for anti-spam modifications if it could reject changes to the profile if certain requirements are not met (like it fails an anti-spam content validation check)

[Danielx64]

There any update on this?

[rxu]

The problem implementing this request is that ucp_profile.php doesn't hold 'before_update' data but just 'after_update' which users table is updated with.
Actually, 'before_update' data can be obtained within the listener if we place an event before the 'UPDATE' sql query execution.

[roelandaernoudts]

Brilliant, exactly what I was looking for

[Tomba]

Adding my vote on this one.
I have a simple plugin where I check for spamwords in signatures and profile fields when a user tries to update his profile. Changes are allowed, but when spam is detected, my plugin deactivates the account.
I think this event would cover that nicely!

Note that I also activate my code in ucp_activate on line 108, which equals activation of a user (but this may be better as a separate event > viewtopic.php?f=111&t=44941&p=258873#p258873 ).

[Pony99CA]

Deactivating an account due to a "spam" word seems a bit harsh. Why not just block the update?

For example, depending on how aggressive your checks are, if you block "Cialis" and I say that I'm an "IT specialist" (emphasis added), you'd deactivate my account.

Steve

[Tomba]

While the reasons for my spamfilter are off-topic here, it's tried and tested.
Blocking the update is totally pointless, as spammers often just paste decent text to post while all spam information is in their signatures.
We've got numerous of these occurrences, sometimes the post is just a half copy of another post by a valid user.
Words have been carefully selected and tested, including detection for cyrillic chars and things like that.

In any case, I'd really like to see this event being added!

[Pony99CA]

While the reasons for my spamfilter are off-topic here, it's tried and tested.

It's not off-topic if you're justifying the event creation by what I think is a poor use.

Blocking the update is totally pointless, as spammers often just paste decent text to post while all spam information is in their signatures.

I'm not talking about just blocking updates to posts; I'm talking about blocking updates to signatures (or any other profile field), too. Instead of deactivating the user, just prevent the profile update from being made. If this event can help block spammy profile updates, I'm all for it.

Steve