がんばって、筋を抑えつつかなり抜粋しました。
これが理解できれば、WordPressについてだいぶ迷うことなく探しものができると思います(html/css/httpなどは別ですが）。

実行フロー

全体の流れ

起動からの流れは

環境変数設定

→コアファイル読込→コアライブラリ読込→プラグイン初期化→テーマ初期化

→ページ作成の事前準備（wp())

→出力処理（テンプレートの活用）となっています。

全体の処理のフロー図

 

表記 ~WB: WordPressインストールディレクトリ

固定表示   ↓ ↓ WordPressが呼ばれる（ケースによって)wordpress内 実行フロー
click !!

---

この実行フローから
Web作成のアプリケーションフレームワーク(WordPressの設計思想)を学んでいきます。

 

４つの設計観点

• ページのパターンを作れる：効率よいページ作成と多様性を可能にしたテンプレート
• 初期化処理
• 深いレベルの機能面の拡張性：プラグイン
• ページごとの表面的な拡張性：カスタマイズ

まず、テンプレートを使うことで、記事のコンテンツに意識してWebページを作成できるようにしつつ、柔軟なレイアウトを設定できるようになっています。またレイアウトはテンプレートでまとめて行うようになっていて、いろいろ準備が終わった最後にそれが実行されています。テンプレートも、動的なページ・固定的なページだけでなく、色々な切り口で並べる（日付、カテゴリ）ようにできていたり、あとからカテゴリを変えても、ページ管理の手間が極力掛からないような構成になっています。

環境変数は最初に設定することで、無駄な処理をせず初期化できます。

プラグイン読み込む前に、コアファイルを読み込むことでより柔軟で拡張性のあるページ作成ができるようになっています。

初期化や読込が終わって（ユーザに initフックなどで明確に利用させつつ）、テンプレート処理の前に wp()クラスで、リクエストの処理の実際を開始します。

WordPress開発者の意図

使用上のタイミング

システムが大きくなると初期化の順番が一見ややこしいように見えますが、WordPressでは、どのように使ってもらいたいかその意図が見えます。 一旦初期化を行いその後 initなどのフックで最初の処理を行います。

テーマやプラグインを読み込むときは、コアファイルや標準ライブラリは一応読み込まれた状態ですが、ページとしては 例えばテーマファイル等を読み込んでいないため、それを処理するような処理は読み込まれるタイミングではできません。（もしテーマファイルを先に読み込んでプラグイン読み込み時に処理させようとしても、テーマファイル読み込み時にプラグインのフックが効かせられないですね。その両方を考えた時どちらが良いかを考えて、実際 テーマファイルが最後の方になっています。）

コアの処理、プラグイン、テーマの読込が完了したあと、実際ページ作成に向けて、フック関数で処理するように心がければ、WordPressが使いこなせるようになります。

例えば、テーマのfunctions.phpやプラグインのメインファイルでは、読み込む処理だけをして実際の操作は、後のフック関数で処理するように意識して使います。

補足：テンプレート階層について

個別投稿記事用のページやフロントページ、404ページなどの
いろいろなページ向けテンプレート（ページタイプごとのレイアウトの雛形）の
処理優先順位のことです。
（いわゆるthemeのsingle.phpなどが呼ばれる。
カテゴリー系であれば WordPressループが呼ばれる。）

ページタイプの例

• アーカイブページ
• 個別ページ > 個別投稿ページ(single.php)や固定ページ(page.php)
• スタートページ(home.php)

 

より詳細・特殊なケースのテンプレートが見つからなければ、
もう少し上の包括的・抽象的なテンプレートが選ばれます。
例えばcategory.phpよりも category-3.phpのほうが先に呼ばれます。
 最後まで候補を辿って行ってマッチするテンプレートがない場合
index.phpが選ばれます。詳細：テンプレート階層

詳細については

詳細はソース見る感じになると思いますが、
少しだけソースレベルで概要を解説しているページがあるので紹介します。
WordPress Initialization | Digital Fellows Tutorials - 

WordPressの拡張性

テンプレートとプラグインが拡張性をサポートしているようです。
そのテンプレート（テンプレートのセットはテーマとして主に見た目をまとめています）
とプラグインについてもう少し深堀します。

1. ヘッダー
2. コンテンツ
3. サイドバー
4. フッター

①ヘッダー
②コンテンツ	③サイドバー
④フッター

アーカイブ(archive???.php)の場合

コンテンツの部分がカテゴリ（タグやカテゴリを選択されたり、日付で選択されたり、検索された時の複数表示)の時、コンテンツ部分で、WordPressループ処理が入り、複数の記事が対象の場合、①ページあたりの最大記事になるまで、例えば抜粋形式で表示されます。 

つまり、WordPressのループは アーカイブでかつ、テンプレート読込の 各記事ループの時に機能することになります。

ループ - WordPress Codex 日本語版 

管理者ページの場合

~WP/wp-admin/post-new.php    、 ~WP/wp-admin/plugins.php、 ~WP/wp-admin/admin.phpなど 呼ばれて処理されます。

プラグイン

同様ににプラグインの役割を整理してみます。

プラグインリストの時は

WordPressはプラグインサブディレクトリ直下（1段階）の全".php"のヘッダを見ます。
そこで.phpの中のファイルヘッダに、Name フィールドがあればそれをプラグインとみなします。
このように認識されれば管理画面で、有効化できます。

例：~WB/wp-content/plugins/addquicktag

WP_Plugins_List_Table | Class | WordPress Developer Resources

wp_get_active_and_valid_plugins() | Function | WordPress Developer Resources

ファイルヘッダは標準のファイルヘッダ取得ライブラリ(get_file_data())を使って各フィールドを取得しています。

つまり、プラグインフォルダのサブサブフォルダ（ユニークなディレクトリ）の.phpファイルに ファイルヘッダを書くだけでプラグインとして認識してくれます。

補足すると、ディレクトリ直下にあるphpが全てプラグイン対象になるわけでもないですし、各プラグインのさらにサブディレクトリまで調べるわけでもなく、逆に対象は１ファイルとは限らず、nameがあれば同じディレクトリでも複数プラグイン対象として見られます。

有効化したら

optionの active_plugins にプラグイン名が保存されています。
DBで optionテーブルの active_pluginsに、有効化されているプラグイン名のリストとして、全て入ってます。
i:0;s:27:"addquicktag/addquicktag.php"

初期化でプラグイン名で、ファイルをすべて読み込み(include @wp-setting.php)ます。

Function Reference/get plugins « WordPress Codex

Function Reference/get plugin data « WordPress Codex

 

プラグインのヘッダ

上記に書いたことが、プラグイン一覧画面で表示されます。有効化/無効化/編集/削除/Pluginのリンクなど含めて表示されます。ただ設定リンクなどは別で行います。

プラグインのメインphpの全体の構成と設計思想

php,やjavascriptでよくあることですが、グローバルスコープであるため他のプラグインやコアライブラリと被らないユニークな名前が必要になります。ディレクトリ名、ファイル名、クラス名、データを保存したりDBを使うなら接頭辞（wp＿みたいなもの）も考えておきます。

ファイル内の関数は考えるのが大変になったりするので、クラス化（オブジェクト化）して、外に出る関数だけユニークにして考えたり整理しやすくします。

いろいろなコスト削減のためになるべくメインphpはミニマムにします。メインのphpは基本的にフック関数だけ登録し、フックで呼びだされた時だけ最低限の部分をincludeします。そのため、どの画面で呼ばれるか大きく分けて整理しておくと良いです（編集画面で呼ばれるのか、ウィジェット画面で呼ばれるのか、投稿画面で呼ばれるのか、ショートコードで対応するのかなど）。

使用されるケースに合わせて、起動トリガ（フック関数やメニュー）を登録します。設定メニューからプラグインの設定画面(ごりごりHTMLで書く）を処理（表示・登録等）させたり、single（投稿記事の中身を編集させたり）、ログインや、記事を投稿するときだけ起動させるためフック登録させたりなどします。

フックについては、プラグイン作成者でなくてもカスタマイズしたことがある人などは調べたことがあると思います。管理メニュー(admin_bar)は 管理メニューの追加 を参考にしてください。 設定ページの中や、外観メニューの下、ダッシュボードメニューの下など、どこにでも追加できます。

あと忘れがちなのがセキュリティと権限です。誰が操作できるかという権限（後述）に注意してください。

プラグインのライフサイクル

ステータスの遷移図

          ↓

アンインストール（削除)

 

状態	お作法
インストール	ファイルやオプションデータ、テーブル等の初期化を行います。
削除	インストール時や起動時に作成したデータを消去します。このお作法がないプラグインは多数あります。 register_uninstall_hook
有効	あまりすることはないかもしれませんが、データの最初期化などに使うかもしれません。register_activation_hook
無効	register_deactivation_hook
起動	初期化から、ケースによる実行方法の遷移をコントロールします。（設定画面、ウィジェット設定画面、投稿内容のフック処理など）

公式へのプラグインの登録はgitを使って登録します。zip化もちょっとした準備で対応できます。プラグインのページは markdownで書いて、画像を保存するだけです。ちょっとだけWordPress用の作法がある。以降VersionUpすると各ユーザに自動的に通知が連携されます。

その他：多言語化、オプションデータ、ウィジェット

多言語化

多言語化はmoファイルを作成し、textdomainで処理します。

__()関数で文字列を変換したり、 _e()関数で出力します。

オプションデータ

オプションは get_option() , save_option() 、delete_option()関数が WordPressに用意されていて、簡単にDBに値を保存することができます。 一般的には管理画面等を利用すると思います。

ウィジェット

ウィジェットは 便利なクラスが有ります。WP_Widgetクラスを継承して、以下のメソッドをオーバライドするだけで、データもウィジェットごとに確保されるようになります。

WordPress ウィジェット API - WordPress Codex 日本語版

 

ウィジェット動作ケース	対応するオーバーライドメソッド
ウィジェット出力表示	widget( $args, $instance) 値($instance)を処理して$before_titleやら$after_titleと一緒にhtmlをごりごりと出力します。
管理用のオプションのフォームを出力	form( $instance )  get_field_name()で適切にフォームにnameを設定しておくと、データが保存できます。実際の値は $instanceに連想配列でアクセスできます。
ウィジェットオプションの保存処理	update( $new_instance, $old_instance ) 省略も可能だが、ユーザからの入力はセキュリティや、誤動作を防ぐためサニタイズします。

ウィジェットの登録は widgets_init フックを使いregister_widget（）で登録します。

全体概要から離れてきたので、詳しくは以下のページを参考にしてください。

プラグイン API - WordPress Codex 日本語版
プラグインの作成 - WordPress Codex 日本語版

権限

普通は管理者だけで運営している人が多いと思います。

購読者は、記事を読める人でなく、記事投稿などをする人のプロファイルを読める人らしいです。使ったことはありませんが。

権限グループの概要
特権管理者 - サイトネットワーク管理機能や他のすべての機能へアクセスできるユーザー。「ネットワークの作成」を参照してください。
管理者 - シングルサイト内のすべての管理機能にアクセスできるユーザー
編集者 - 他のユーザーの投稿を含むすべての投稿を発行、管理できるユーザー
投稿者 - 自身の投稿を発行、管理できるユーザー
寄稿者 - 自身の投稿を編集、管理できるが、発行はできないユーザー
購読者 - プロファイル管理のみを実行できるユーザー