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 …

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.

WordPress Pulse? – Heartbeat API

With WordPress 3.6, there will be a new API - Heartbeat. On Ticket 23216 in Trac all discussions and information be gathered together. Because Heartbeat may also have influences for users, here are some words and clues. Heartbeat is introduced to various activities, such as Autosave, locks of articles and to handle logon and logoff notifications. In parallel, the API can also be used for own developments.
Continue reading …

WordPress Theme Customizer Custom Controls

The Customizer is a relatively new way of WordPress Themes to provide you with options. Here is the visuality important, arrange the options directly in frontend for the Theme, play and save the settings.

We show you how to create your own classes to extend the controls, since not all fields and requests are in the core already. You can access existing solutions of the community or create your own classes. The first step is therefore a brief introduction for new classes and following an overview of some classes. Please extend this list via the comment form.
Continue reading …

How recent is “recently”?

If you deactivate plugins you can access them some time under the "Recently active" link in the plugin list table.


"Recently" is not a very specific statement. So how long are deactivated plugins assumed to be "recent"? To find this out we have to take a look at the source code. In wp-admin/plugins.php line 166 the option "recently_activated" gets updated if a plugin is deactivated:

if ( ! is_network_admin() )
  update_option( 'recently_activated', array( $plugin => time() ) + 
  (array) get_option( 'recently_activated' ) );

The option contains an associative array containing the path to the main file of the plugin as the key and the time the plugins have been deactivated (as a unix timestamp) stored as a serialized value:

183 recently_activated a:1:{s:21:"hello-dolly/hello.php";i:1357900255;}

Before the plugin table is created the time stamp is used to determine the "recently active" plugins (wp-admin/includes/class-wp-plugins-list-table.php line 76):

$recently_activated = get_option( 'recently_activated', array() );

foreach ( $recently_activated as $key => $time )
  if ( $time + WEEK_IN_SECONDS < time() )
    unset( $recently_activated[$key] );
update_option( 'recently_activated', $recently_activated );

The code is walking through all plugin names stored in "recently_activated" and removes those which are older than one week and saves the others back in the options table.

So the answer to the question is: WordPress defines "recently" as one week.