Customizing the User Registration Notification eMails

If a new user registers at a WordPress site the new user and the administrator receive notification mails:

User:

From: myBlog (info@myBlog.com)
Subject: [myBlog] Your username and password info

Username: new_user

To set your password, visit the following address:<http://myblog/wp-login.php?action=rp&key=3oCJkevP1ZSSb0P8DlOW&login=new_user>

http://myblog/wp-login.php

Admin:

From: myBlog (info@myBlog.com)
Subject: [myBlog] New User Registration

New user registration on your site myBlog:

Username: new_user

Email: new_user@myblog.com

Until version 4.8 the content of the mail was hard coded.The only way to alter the mails was to hook into wp_mail() or even phpmailer.

WordPress v4.9 now offers the ability to easily customize these mails by using the following filters:

The filters fire after the user has been added to the database.

The filters for the user’s and the admin's email follow the same logic, just the filter and the variable names differ:

$wp_new_user_notification_email_admin = apply_filters( 'wp_new_user_notification_email_admin', $wp_new_user_notification_email_admin, $user, $blogname )

The parameters contain the following values:

  • $wp_new_user_notification_email_admin: Associative array with the keys to, subject, message, headers.
  • $user: A WP_User object of the registered user.
  • $blogname: A string containing the name of the blog the user registered to.

With these values at hand it’s easy to create your customized mail:

add_action( 'login_init', 'my_wp_new_user_notification_email_admin_init' );

function my_wp_new_user_notification_email_admin_init() {
    add_filter( 'wp_new_user_notification_email_admin', 'my_wp_new_user_notification_email_admin', 10, 3 );
}

function my_wp_new_user_notification_email_admin( $wp_new_user_notification_email, $user, $blogname ) {
    $wp_new_user_notification_email['subject'] = sprintf( '[%s] New user %s registered.', $blogname, $user->user_login );
    $wp_new_user_notification_email['message'] = sprintf( "%s ( %s ) has registerd to your blog %s.", $user->user_login, $user->user_email, $blogname );

    return $wp_new_user_notification_email;

}

(As always for filters: do not forget to return the altered variable.)  The mail now looks like this:

From: myBlog (MyBlog@myblog.com)
Subject: [myBlog] New user new_user registered.

new_user (new_user@user.com) has registerd to your blog myBlog.

Of course, you can insert more data than provided by the filter. E.g., you can tell the admin, how many registered users the blog already has:

function my_wp_new_user_notification_email_admin($wp_new_user_notification_email, $user, $blogname) {

    $user_count = count_users();

    $wp_new_user_notification_email['subject'] = sprintf('[%s] New user %s registered.',
$blogname, $user->user_login);
    $wp_new_user_notification_email['message'] =
    sprintf( "%s has registerd to your blog %s.", $user->user_login, $blogname) .
"\n\n\r" . sprintf("This is your %d. user!", $user_count['total_users']);

    return $wp_new_user_notification_email;

}

The parameter headers can be used to easily change some header information:

$wp_new_user_notification_email['headers'] = "From: myBlog <myblog@myblog.com> \n\r cc: Admin 2 <admin2@mblog.com>";

In this example the From information of the mail is changed and the user admin2@myblog is added as an additional recipient. As you can see, multiple headers entries are separated by "\n\r" (return and linefeed).

As said before this all could already be done by using wp_mail() and phpmailer but the new filters are way more convenient.

Download older plugin versions from wordpress.org

There's a simple way to get hold of previous versions of your WordPress plugins, for example if a current version breaks your setup.

On the right side of the plugin's page there a link called "Advanced View", which should better be called "Version View":

Very, very (very) far at the end of the page there a dropdown box where you can select the desired version and click "Download" the get the desired version:

Create your own bulk actions

2016-10-21_13-46-04
Including version 4.6 it was quite difficult to add custom bulk actions to the WordPress admin pages. In version 4.7 a hook is added that simplifies the task a lot:

add_action('bulk_actions-{screen_id}', 'my_bulk_action');

Defining the hook

As an example we’ll use the post page, the variables are named accordingly.

add_filter( 'bulk_actions-edit-post', 'register_my_bulk_actions' );

Definig the hook

function register_my_bulk_actions($bulk_actions) {
  $bulk_actions['my_bulk_action'] = __( 'My Bulk Action', 'domain');
  $bulk_actions['my_other_bulk_action'] = __( 'My Other Bulk Action', 'domain');
  return $bulk_actions;
}

You can define more than one bulk action in this function because it merely adds an additional element to the array $bulk_actions. You simply have to take care that you use different names for the element keys and, logically, for the display texts.

The screen ids

The screen id of an admin page can be displayed this code snippet:

$screen = get_current_screen();
var_dump($screen);

This table shows the ids for some admin pages:

Page $screen_id File
Media Library upload upload.php
Comments edit-comments edit-comments.php
Tags edit-post_tag edit-tags.php
Plugins plugins plugins.php
Links link-manager link-manager.php
Users users users.php
Posts edit-post edit.php
Pages edit-page edit.php
Edit Site: Themes site-themes-network network/site-themes.php
Themes themes-network network/themes
Users users-network network/users
Edit Site: Users site-users-network network/site-users
Sites sites-network network/sites

Defining the callback function

Here’s an overview of the whole function:

add_filter( 'handle_bulk_actions-edit-post', 'my_bulk_action_handler', 10, 3 );

function my_bulk_action_handler( $redirect_to, $action_name, $post_ids ) { 
  if ( 'my_bulk_action' === $action_name ) { 
    foreach ( $post_ids as $post_id ) { 
      $post = get_post($post_id); 
      // process $post wp_update_post($post); 
    } 
    $redirect_to = add_query_arg( 'bulk_posts_processed', count( $post_ids ), $redirect_to ); 
    return $redirect_to; 
  } 

  elseif ( 'my_other_bulk_action' === $action_name ) { 
    foreach ( $post_ids as $post_id ) { 
      $post_meta = get_post_meta( $post_id ); 
      // process $post_meta update_post_meta( $post_meta ); 
    } 
    $redirect_to = add_query_arg( 'other_bulk_posts_precessed', count( $post_ids ), $redirect_to );
    return $redirect_to; 
  } 
  
  else 
    return $redirect_to; } 

As mentioned above you can define more than one custom bulk action but only a single callback function. So you first have to test which bulk action has been selected (lines 4 and 13).

Next the posts are processed in a foreach loop (lines 5 and 14). In this loop you can load the post with get_post or the post meta with get_post_meta() and process the data. Next the changed data is written back to the database with wp_update_post() or update_post_meta().

The variable $redirect_to (lines 9 and 18) is used to define the URL the browser will change to after the bulk actions have been completed, in our case it is set to .../wp-admin/edit.php?paged=1. We do not want to change the location but to use the variable to pass a value to the page the browser is redirected to.
With the function add_query_arg() we add an argument to the URL that specifies the number of processed posts: /wp-admin/edit.php?paged=1&bulk_posts_processed=1.

Display a success notification

After completing processing all posts you can display an admin notice using the action admin_notices(). The second parameter of the function call needs to contain the text string we have defined in our filter bulk_actions-{screen-id}:

function my_bulk_action_admin_notice() { 
  if ( ! empty( $_REQUEST['bulk_posts_processed'] ) ) { 
    $posts_count = intval( $_REQUEST['bulk_posts_processed'] ); printf( '
' . _n( 'Processed %s post.', 'Processed %s posts.', $posts_count, 'domain' ) . ' ', $posts_count ); 
  } 
} 

Trivia

A little fun fact at the end: The corresponding ticket (#16031) was opened six years ago, 2010, in that times we used WordPress v3.0.

Inform user about automatic comment closing time

To prevent spammers from flooding old articles with useless comments you can set WordPress to close comments after a certain number of days:
close-comments
It might be surprising for some users if the comments are closed automatically so it might be a good idea to inform them about the remaining time.

add_action( 'comment_form_top', 'topic_closes_in' );

function topic_closes_in() {
    global $post;
    if ($post->comment_status == 'open') {
        $close_comments_days_old = get_option( 'close_comments_days_old' );
        $expires = strtotime( "{$post->post_date_gmt} GMT" ) +  $close_comments_days_old * DAY_IN_SECONDS;
        printf( __( '(This topic will automatically close in %s. )', 'domain' ),  human_time_diff( $expires ));
    }
}

While the code should be almost self explanatory there is an interesting function not every WordPress developer might know: human_time_diff(). This function is hidden in the .../wp-includes/formatting.php file. It is originally planned to be used in themes to provide a more “human” touch to the date/time a post was written. Since the function does not care if the date is in the past or in the future we can use it for our needs.

close comment example

Escaping the maintenance mode trap

WordPress makes upgrading very easy . You simply click “Update now”, wait for a minute or two and your system is up to date. If, well if everything works fine.
The most common problem during an upgrade is the Internet connection to drop unexpectedly or the user to shut down the browser unintentionally. In both situations the upgrade will stop instantly.
If you try to log in to your backend again you will receive the message

“Briefly unavailable for scheduled maintenance. Check back in a minute.”

This message is useful to keep users away from your blog during the upgrade but right now it’s keeping you from restarting the upgrade. To solve this problem we have to take a look at how WordPress determines that it’s in maintenance mode.

WordPress is looking for a possible maintenance mode very early to prevent the system dying from any fatal error. So it using a very simple method by writing a file called .maintenance to the WordPress root directory. If the blog or backend is accessed it will check for the file and stop if it’s present.

Knowing this the solution to our problem is quite simple: access your WordPress system via FTP and delete the file .maintenance.

If you’re not able to log in to your server via FTP for some reason there is a second method for escaping from maintenance mode: simply wait 10 minutes!
The file .maintenance contains a timestamp of the time the file was created. If this time is less than 10 minutes ago WordPress will go into maintenance mode otherwise it will continue to work as usual and enable you to restart the upgrade unless something worse keeps it from starting.

New hooks in WordPress 3.8

WordPress 3.8 introduced one new action and five new filters:

  • automatic_updates_complete
    Action triggered after all automatic updates have run.
    (wp-admin/includes/class-wp-upgrader.php)

  • automatic_updates_debug_email
    Filter the debug email that can be sent following an automatic background core update.
    (wp-admin/includes/class-wp-upgrader.php)
  • comment_notification_notify_author
    Filter whether to notify comment authors of their comments on their own posts.
    (wp-includes/pluggable.php)
  • dashboard_glance_items
    Include additional elements in the ‘At a Glance’ dashboard widget. This widget was previously ‘Right Now’.
    (wp-admin/includes/dashboard.php)
  • user_{$name}_label
    Filter a user contactmethod label.
    (wp-admin/user-edit.php)
  • wp_prepare_themes_for_js
    Filter the themes prepared for JavaScript, for themes.php. Could be useful for changing the order, which is by name by default.
    (wp-admin/includes/theme.php)
  • A list of all new hooks can you also find in the hot list of WP Seek.