Tag Archives: office 365

WordPress/BuddyPress registration and the Office 365 email filter

Just tore through the following problem on a client site (independently discovered by Martha Burtis here). WordPress/BuddyPress sites that allow for self-registration send out emails with activation links of the form: http://example.com/activate/?key=12345 (for BuddyPress) and http://example.com/wp-activate.php?key=12345 (for WordPress multisite). This format trips up the link filter that Microsoft’s Office 365 email service uses. After some experimentation, I figured out that the problem is the word ‘key’ in a URL parameter – once this term is removed from the URL, it passes right through the filter.

So, you can fix the problem by changing the URL parameter in the activation emails. That means (a) changing the text of the email, and (b) changing the server-side logic to expect something other than ‘key’. Here’s how to do it in BuddyPress:

[code language=”php”]
function bbg_activation_email_content( $message ) {
return str_replace( ‘?key=’, ‘?activationk=’, $message );
}
add_filter( ‘bp_core_activation_signup_user_notification_message’, ‘bbg_activation_email_content’ );

function bbg_screen_activation() {
global $bp;

if ( !bp_is_current_component( ‘activate’ ) )
return false;

// Check if an activation key has been passed
if ( isset( $_GET[‘activationk’] ) ) {

// Activate the signup
$user = apply_filters( ‘bp_core_activate_account’, bp_core_activate_signup( $_GET[‘activationk’] ) );

// If there were errors, add a message and redirect
if ( !empty( $user->errors ) ) {
bp_core_add_message( $user->get_error_message(), ‘error’ );
bp_core_redirect( trailingslashit( bp_get_root_domain() . ‘/’ . $bp->pages->activate->slug ) );
}

// Check for an uploaded avatar and move that to the correct user folder
if ( is_multisite() )
$hashed_key = wp_hash( $_GET[‘activationk’] );
else
$hashed_key = wp_hash( $user );

// Check if the avatar folder exists. If it does, move rename it, move
// it and delete the signup avatar dir
if ( file_exists( bp_core_avatar_upload_path() . ‘/avatars/signups/’ . $hashed_key ) )
@rename( bp_core_avatar_upload_path() . ‘/avatars/signups/’ . $hashed_key, bp_core_avatar_upload_path() . ‘/avatars/’ . $user );

bp_core_add_message( __( ‘Your account is now active!’, ‘buddypress’ ) );

$bp->activation_complete = true;
}

bp_core_load_template( apply_filters( ‘bp_core_template_activate’, array( ‘activate’, ‘registration/activate’ ) ) );
}
remove_action( ‘bp_screens’, ‘bp_core_screen_activation’ );
add_action( ‘bp_screens’, ‘bbg_screen_activation’ );
[/code]

You’d have to do something in the same spirit when not using BuddyPress. For the email, filter ‘wpmu_signup_user_notification_email’. Catching the request and overriding ‘key’ will be trickier. I haven’t experimented with it, but maybe you can hook to ‘activate_header’, detect the presence of $_GET['activationk'], and then redirect to the ‘key=’ URL that wp-activate.php expects.

Hopefully this is enough to help if you’re having the problem.