Customizing the User Registration Notification eMails

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


From: myBlog (
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>



From: myBlog (
Subject: [myBlog] New User Registration

New user registration on your site myBlog:

Username: new_user


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 (
Subject: [myBlog] New user new_user registered.

new_user ( 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 <> \n\r cc: Admin 2 <>";

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.

Create your own bulk actions

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' );

Continue reading …

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:
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.