wp_insert_user()は新規利用者の戻り値を確認し既存利用者はwp_update_user()で変更する

wp_insert_user()で新しい利用者を作成したら、戻り値を成功時の利用者IDと失敗時のWP_Errorに分けてください。既存利用者の一部だけを変える場合は、元の値を引き継ぐwp_update_user()を使います。

利用者を登録する処理と、役割や表示名を決める運用は別です。codeが利用者IDを返しても、必要以上の権限を与えてよいことにはなりません。

新規作成では必要な値と役割を先に決める

wp_insert_user()は、利用者情報を配列で受け取ります。新規作成では、少なくともlogin名とpasswordを用意し、業務に必要ならemail addressとroleも明示します。

次は説明用の仮例です。

<?php
$result = wp_insert_user(
    array(
        'user_login' => 'sample_editor',
        'user_pass'  => $initial_password,
        'user_email' => 'sample@example.invalid',
        'role'       => 'editor',
    )
);

if ( is_wp_error( $result ) ) {
    $error_code = $result->get_error_code();
    // 管理者向けに記録し、作成後の処理を止める。
    return;
}

$user_id = (int) $result;
?>

$initial_passwordは、別の処理で安全に用意した初期passwordを表します。codeやlogへ固定passwordを残す例ではありません。実際の通知方法と、最初のlogin後に変更させる手順も別に決めてください。

roleを省くと、サイトに設定されたdefault roleが使われます。作成処理の都合で管理者を指定せず、利用者が行う仕事からroleを選びます。

戻り値はIDかWP_Errorかを分ける

WordPress 4.1.1のuser.phpでは、wp_insert_user()は成功すると利用者ID、作成できない場合はWP_Errorを返します。

たとえば、login名が空になった場合や、同じlogin名がすでにある場合はWP_Errorです。したがって、戻り値をそのまま利用者IDとして保存したり、通知処理へ渡したりしてはいけません。

処理順は次のように分けます。

1. wp_insert_user()を一度呼ぶ
2. is_wp_error()で失敗を先に判定する
3. 失敗ならerror codeを管理者向けに記録し、後続処理を止める
4. 成功なら戻り値を利用者IDとして扱う
5. 作成した利用者のroleと連絡先を管理記録と照合する

利用者向けの画面へdatabaseや内部処理の詳細をそのまま表示する必要はありません。運営担当者が原因を調べられる記録と、申込者へ伝える案内を分けます。

IDを渡すと更新処理になる

wp_insert_user()へIDを含む利用者情報を渡すと、新規作成ではなく既存利用者の更新として処理されます。ただし、同関数へ一部のfieldだけを直接渡す方法は避けてください。user_loginやpasswordなど、更新に必要な既存値まで揃える必要があるためです。

表示名など一部だけを変えるなら、wp_update_user()を使います。

<?php
$result = wp_update_user(
    array(
        'ID'           => $user_id,
        'display_name' => '編集担当',
    )
);

if ( is_wp_error( $result ) ) {
    $error_code = $result->get_error_code();
    return;
}
?>

wp_update_user()は、指定したIDの利用者情報を取得し、新しいfieldを元の情報へ重ねたうえでwp_insert_user()を呼びます。新規作成と部分更新で入口を分ければ、どの値を新しく与え、どの値を保持するかが明確になります。

関数の成功と操作権限を分ける

wp_insert_user()へ配列を渡すだけでは、その処理を要求した人が利用者を作成してよいかという判断は完了しません。独自の管理画面やformから呼ぶ場合は、関数より前で利用者の権限、nonce、入力値、作成を許すroleを確認します。

確認する順を混ぜないでください。

nonceが正しくても、管理者roleを指定してよいとは限りません。反対に、作成権限があっても、重複したlogin名なら関数は失敗します。

作成記録にはpasswordを残さない

利用者作成の記録には、利用者ID、login名、role、作成日時、作成理由、確認担当を残します。初期passwordそのものは、通常のlogや引継ぎ表へ書かないでください。

plugin制作を委託する場合は、利用者を作る入口、許可するrole、errorの記録先、通知方法、削除または停止の手順を受け取ります。作成codeの所有と、利用者accountを棚卸しする責任を分けずに引き継ぎます。

最初の一手は、新規利用者を作る処理を一つ選び、wp_insert_user()の直後にis_wp_error()があるか確認することです。次に、既存利用者の変更へ同じ関数を直接使っていないかを調べ、部分更新ならwp_update_user()へ分けてください。