msio

$user = get_userdata(ユーザーID番号（数字）)
$user->user_email
するだけですよー。

• この返信は8年、 2ヶ月前にmsioが編集しました。

私も部分的になってしまうのですが、とりいそぎご利用中の状態を鑑みてこれ以上自力で進むべきかどうかを判断いただけたらと思います。
まず解決すべきとしている問題はおそらくほとんどの比重をJavascriptに置くものではないかと思います。
即時反映、枠の意味するところが理解できておりませんが、フォームの動作を読み込みなしに別の要素に反映させたいという意図で選択されたものかなと思っております。

そこで、現状をたしなめるだけになってしまいますがご紹介いたします情報について理解が先に進める様であれば別途Javascriptについてご研鑽を積まれてみるのもよいのではと思います。

まず要素の指定なのですが、どこのデータをどこに入れるかということをはっきりさせるため名前づけをするのですがタグは
ID と　NAME のプロパティがあります。IDは絶対的なものでページに一つである必要があります。複数あると動作しません。
NAME はグループ化することができグループ化したものは配列として取得することができます。ラジオボタンは同グループ内で一つしかチェックできないなどの
動作を自動化することもできます。
ここで、NAMEは配列が可能なので @latobeam さんの仰られている配列構造になるのですが、配列の指定で[]は存在する要素に追加していく指定方法になります。
インテグサを必要とせずインクリメントしていくので、すでに配列に３つ要素のはいっている変数に 変数[]=”A” とすると四つ目の要素がAになります。
順序などを気にせずなんでも配列構造に代入したいときに使います。

この時点でご注意いただきたいのですが、引き渡したい要素は数量が変更になる（テキストボックスの個数がユーザーの都合によって増減する）ことがあるものでしょうか。
固定の数量であるならばIDを利用して絶対的な要素に引き渡した方が確実かと思います。

そしてそのNAMEとIDの要素なのですが、これを指定するのに document 要素内から　IDの要素を探す　という命令　getElementById をご利用の様子ですが
これで探せるのは IDで名づけられた要素です。　NAME に同じ名前があってもなくても見つけられません。

ここまでで、POSTする要素を構成する団体はID で自由気ままに組んで、最終NAME　で整形してPOSTするとよいのでは、とお考えになられたら次に進まれるとよいかと思います。

進まれる折、お気づきになられれば幸いなのですが getElementById　があるということはgetElementByNameやgetElementsByClassNameもあるのではないかと、そうなんです。
それぞれの配列になる、指示側からみて１対多であるから発信はできても受信はできなさそうだな、と連想いただけるとなおありがたいのですが、用途と特徴がことなります。
今回およびその他多く使われる「代入動作の補助」としての指定には IDが適しており今回もIDで的中だと思います。

繰り返しになりますが例として「色」という項目について条件が４色といった分岐になるとき、色プロパティの色素要素の指定となればNAMEで色配列に各色データをいれて
ON/OFFをプロパティづけする必要がでてきて、これにはNAMEが適だろうと思います。

ここまでは大丈夫でしょうか。

そこでJSコードについてなのですが


//searchform という名前のフォームを丸ごとオブジェクト化して取得 msio
var $formObject = document.getElementById( "searchform" );
//取得した要素の個数を上限にiを加算ループ msio
for( var $i = 0; $i < $formObject.length; $i++ ) {
//フォームの中にある要素全部にアクションを付与 msio これはちょっと無茶じゃないかと…個人の感想です
//ほんとに全部の全要素にアクションが必要でしょうか msio
$formObject.elements[$i].onkeyup = function(){
getValue();
};
$formObject.elements[$i].onchange = function(){
getValue();
};
}
};



//OutputText という要素の「タグ内（innerHTML）」にデータを挿入 msio
//.value（テキスト要素のvalueデータ）ではなくタグの起点と終点の間の情報にデータを挿入しています msio
//innerHTML はspan　でくくられた中身を入れ替えたりするのには有用ですがテキストなどの
//valueレセプタが準備できるものにはvalueで入れるものかと思います。
document.getElementById( "OutputText" ).innerHTML = $formObject.s.value;

document.getElementById( "Output_lang" ).innerHTML = ''; //いったん中身を削除
for(var $i = 0; $i<$formObject.post_tag_language.length;$i++) { //複数checkedされていることもあるので、forでまわす（まわさないと1番目のしか取れない）
//フォーム内の全部の要素についてチェックのONを確認されていますが
//フォーム要素のなかにあるものは全部チェック要素でしょうか
//仮にテキストボックスやボタンがあれば「checked」プロパティが取得できませんので
//エラー回避にプロパティが取得できなかったときという分岐が必要になります
if($formObject.post_tag_language[$i].checked) {
//ここでもタグにはさまれた中身を置き換えています
document.getElementById( "Output_lang" ).innerHTML += $formObject.post_tag_language[$i].value + ' ';
}
}
}



//valueに入る
<input type="text" id="sample" name="samplename" value="---A---" class="sampleclass">
document.getElementById( "Output_lang" ).value="---A---"

//ボタンで誘導し制約をかけていますが動作は値の代入です
<input type="radio" name="sample" value="1">
<input type="radio" name="sample" value="2" selected>
<input type="radio" name="sample" value="3">
document.getElementByName( "sample" ).value = "2"


ちょっと正しい記述か確認とほかにもまだまだ色々な書き方がありますがとりあえずWordpressかどうかといわれると
全く関係ないところになってしまいますので割愛をご容赦くださいませ。

とりいそぎJSの動作概要を把握いただいて、動作の経路について導線が重複しない想定ができてから、はじめてWordpressの
「なにをうけとり、なにをわたすか」に至るのが効率的にもよいかとおもいますのでご検討いただけますと幸いです。

ちょうど新しく権限の作成をするところだったので確認してみました。
私は本をもっていないので　follow_developer_activities　という「権限機能」はないようなので
チェックがついているという状況がわかりませんでした。
ロールの機能を紹介させていただきますと、
名称ときめてその名称に権限としての機能を追加するものです。
その権限の機能は準備されていて、そこに追加する構造が私にはわかりませんでした。
add_role( ‘follower’, ‘Follower’, array( ‘read’ => true ) );
こちらのコードで　Follower　と表示されている権限には　read　機能しか与えられておらずそれ以上はないかと思います。
ほかの機能を追加する場合はこちらのサイトが参考になるかと思います。
Codex日本語版　ユーザーの種類と権限
add_role 三番目のケイパビリティというパラメータが、どういう機能をするものを追加するか、という部分なので
この指示名が違っているのではないかと思います。
follow_developer_activities　というロールセットを準備して　これはフォロワーが制作作業をどうにかする的なことに必要な権限を許可されるセットとしてくまれているのであれば追加されてしかるべきかと思いますが
私は地味に「書き込み可能、読み取りのみ可能、削除可能、変更不可能」といった具合に地味に追加して「フォロワー」というロールを作成するものなのではないかと思います。
いまちょうどさわっただけなのでつたない考察になりますがご参考いただけると幸いです。

<?php
/*
  Plugin Name: WPWA User Manager
  Plugin URI:
  Description: User management module for the portfolio management application.
  Author: Rakhitha Nimesh
  Version: 1.0
  Author URI: http://www.innovativephp.com/
*/

//クラス宣言　★追加注釈
class WPWA_User_Manager {
//コンストラクタ　クラス初期化時に実行されるコード群　★追加注釈
//以降の動作に初期値が必要なものはここで宣言しておくもの　★追加注釈
  public function __construct() {
    // 初期化コード
    register_activation_hook( __FILE__ , array( $this, 'add_application_user_roles' ) );
    register_activation_hook( __FILE__, array( $this, 'remove_application_user_roles' ) );
    register_activation_hook( __FILE__, array( $this, 'add_application_user_capabilities' ) );
  }

  // フォロワー、開発者、メンバー 3種類のユーザーロール
  public function add_application_user_roles() {
//add_role( '権限名（機械で処理するため半角ローマ字）', '権限表示名（日本語でおｋ）', array( 追加する権限機能 ) );★追加注釈
      add_role( 'follower', 'Follower', array( 'read' => true ) );
      add_role( 'developer', 'Developer', array( 'read' => true ) );
      add_role( 'member', 'Member', array( 'read' => true ) );
  }

  // 既存のユーザーロールを削除する
  public function remove_application_user_roles() {
      remove_role( 'author' );
      remove_role( 'editor' );
      remove_role( 'contributor' );
      remove_role( 'subscriber' );
  }

  // フォロワーの最初の権限を与える
  public function add_application_user_capabilities() {
//フォロワーという権限を読み出す★追加注釈
      $role = get_role( 'follower' );
//読みだした権限に機能を付与する★追加注釈
//-------------ここで付与する権限機能がCodexページで見た中に存在していませんがどうなのでしょうか-----------★追加注釈
      $role->add_cap( 'follow_developer_activities' );
  }
}

$user_manage = new WPWA_User_Manager();

メディアファイルの大きさが大きいのではないですか？
軽量化した画像ファイルをサムネイルとして表示するなどしてみてはいかがでしょうか。
動画であれば再生を開始してから読み込みを開始するなど。

なるほど！
マルチサイトの権限グループなのですね。経験値がないため思考が及ばず管理者と同一視しておりました。勉強になります。

現状ではマルチサイトの運用をしておりませんので検証はできておりませんが
ワードプレスの機能を利用せず直接データベースの情報を書き換えること自体が仕様にそぐわないので
リレーションに関する部分は連携記述を全部手で書き換えるか、特別に不可領域も書き換える可能な仕様を準備するかになると思います。

ユーザー名の変更、というか一般に広く運用されている最初に設定した「アカウント文字列」を変更できない仕様は
メリットよりもデメリットが大きいので導入されていないものなので
先述後者の仕様が導入されることは期待が低く、「ワードプレスの仕様」という事でよいかと思います。
おそらく他のログイン機能をもつサイトも「ログインアカウント文字列の変更」はできないものが多いと思います。

私には解決方法が見つかりませんでしたので、先のお話をいたしました経緯をお伝えいたします。
どこかに解決の糸口があることを願って。

条件
・権限はユーザーのIDから_usermeta テーブルを参照して _user_level _capabilities などに記載があるけれども
　連結にはIDを使用しているのでユーザー名変更に関わらない。
・テーブルに対し直接データの変更を行うとユーザー名、メールアドレスの重複は許容される。
・参照方法によっては同名アカウント、同メールアドレスでログインした際、希望したアカウントではないほうでログインされる可能性がある。
　（ログインできてしまう：パスワードの重複も前提になります）

状態
・メタ情報に関する部分など、アカウント以外には変更をおこなっていない。
・ログインはメールアドレスではなく変更したユーザー名でおこなっている。
・確認はユーザー情報のroles[0]などで呼び出し確認または設定画面のユーザー権限に対する動作で確認している。
　（個人で設定した”管理者であれば表示するはずの設定”がない、などではなくワードプレスの機能にて）

これらから考えてログインできたユーザーのログイン名が変更されるに伴い権限が変更されたとワードプレスが判断を下すことは、同じ名前で別ユーザーが動作している以外ないと考えたのでした。
なんのお力にもなれませんでしたが解決された折にはきっと私をふくめこれからの問題解決に有益な情報となるかと思いますので陰ながら解決を祈りしております。

表現されている内容に私の理解がついていかない部分がいくつかありますが

user_login　の情報だけをを変更すると　設定された権限ではなくなる

ということのみについて

新しく設定するログイン名は
もしかして他に存在するログイン名と同じになっていないでしょうか。

あと細かいことなんですが結果を渡す先を指示するまではわかるにしてもなぜ配列なのか、については巻数にパラメータをはじめから三つ、ひとつはもしかしたら外部変数へのリフレクションかもしくは使わない盲腸のようなパラメータを用意するよりは二つで運用して二つ目が「is_array」判定されたらレスポンスを指定のオブジェクトへ返す仕様のほうがスマートだからではないかと思います。
もうひとつ、クラスとグローバルの範囲についてなのですがイメージとしては「声が届く範囲がそのプロセスのグローバル」であり「声がとどかない距離、または近距離でも厚いへだたりを超えて作業をしている状態」がクラス、みたいに言うとよけいにわかりにくいでしょうか。どうでしょうか。
距離が近くて声がとどかないなんてありえない、と想像されるようなきがするのですがたとえば「冷蔵庫」というへだたりは温度の維持を内と外、それぞれに有益な状態をたもっていますが厚い隔たりで「同じプロセス上に置けない」ものだと思います。
仮に、スパゲッティプログラムという全部グローバルで同じプロセスで組むというのは「冷蔵庫にガスコンロがある状態、レスポンスも早く最小で最速の結果を得られる」ものですが、それをとりまく環境をひたすら汚染することが想像できるのではないでしょうか。
いかがでしょうか。