WordPress Webサイトの表示を行う場合の順序

  1. ブートストラップ(wp-load.php)をロードし、WordPressを起動。
     → WordPressの起動と初期化
  2. wp関数はHTTPリクエストのクエリ文字列をWordPressクエリに変換し、それをデータベースのSQLクエリに変換しページ表示に必要なデータを取得
     → WordPressクエリの実行
  3. テンプレートローダー(template-loader.php)がテーマの中から適用すべきテンプレートファイルを決定する
     → テーマの適用

※wp-blog-header.phpの構造

WordPressコア

WordPressコアはWordPressの基本機能を提供するWordPressの構成要素です。
ファイル上はwp-contentディレクトリ(テーマ、プラグイン、アップロードファイル)とwp-config.phpファイル(設定ファイル)以外は全てWordPressコアです。

関数ファイルやクラスファイルなどの共通ライブラリとしてのPHPファイルはwp-includesディレクトリにまとめられています。
WordPress実行時には、Webサイトの表示であっても管理画面の表示であっても、その他であってもwp-includesディレクトリの多くのファイルが共通ライブラリとしてロードされます。

(1)Webサイト表示の場合
ルートディレクトリ直下のindex.phpがフロントコントローラーとして機能し、WordPressコア(WordPressの実行)がスタートします。

(2)管理画面の場合
wp-adminディレクトリ内の各PHPファイルがページコントローラーとして機能し、WordPressコア(WordPressの実行)がスタートします。
=機能ごとに最初にアクセスされ、実行されるファイルが異なる。
例)wp-admin/index.php・・・ダッシュボードページのページコントローラー
  wp-admin/upload.php・・・メディアライブラリページのページコントローラー

管理画面内で共通して利用される関数ファイルやクラスファイルなどのPHPファイルはwp-admin/includesディレクトリ内にまとめられています。実行領域にかかわらずロードされるwp-includesディレクトリ内の共通ファイブラリをロードした後に追加してロードされます。

※wp-adminディレクトリ内のPHPファイルのうちwp-admin/admin-ajax.phpのみはログインの有無を問わず実行される

(3)その他の領域
管理画面同様、WordPressコアはページコントローラー方式で起動します。

WordPressの構成要素

WordPressは以下の6つの構成要素によって成り立っています。

  1. WordPressコア
  2. プラグイン
  3. データベース
  4. 設定ファイル(wp-config.php)
  5. アップロードデータ
  6. テーマ

このうち、データベースを除く5つの構成要素の実態は通常のファイルやディレクトリです。

WordPressの実行領域

WordPressの実行領域

主としてWordPressが最初にHTTPリクエストを受け取る領域。
ブラウザからアクセスされる領域で、多くの場合はHTTPリクエスト。
以下の3つの領域に分けられる

  1. Webサイトの表示
  2. 管理画面
  3. その他

1.Webサイトの表示

Webサイトのトップページや個別ページなどのWebサイトそのものの領域。
WordPressはフロントコントローラー方式で起動。
※index.phpの実行=WordPressの実行

2.管理画面

記事を投稿したりWordPressを設定したりする管理領域。
WordPressはページコントローラー方式で起動。
※wp-adminディレクトリ内に個別に設定されている各機能ごとのPHPファイルの実行=WordPressの実行

3.その他

Webサイトの表示と管理画面以外の領域。(ログインページやAjaxページなど)
ページコントローラー方式で起動。

HTTPリクエストとHTTPレスポンス

HTTPリクエスト

ブラウザからwebサーバーへの要求メッセージ

response

1.リクエストライン・・・1行目
2.HTTPリクエストヘッダ・・・2行目から次の空行まで
3.HTTPリクエストボディ・・・その次以降
の3パートからなる。

※リクエストラインに記載されるリクエストメソッドがGETの場合はリクエストボディはなし。
 (POSTメソッドの場合ボディ部にPOSTデータが格納される)

HTTPレスポンス

Webサーバーからブラウザへの応答メッセージ

request

1.ステータスライン・・・1行目
2.HTTPレスポンスヘッダ・・・2行目から次の空行まで
3.HTTPレスポンスボディ・・・その次以降
の3パートからなる。

詳解WordPress 用語の定義集

A

ABSPATH

WordPressをインストールしたディレクトリのサーバー上の絶対パスを示す定数。
※P23、102
詳細はこちら

add_action関数

特定のアクションにフックする関数。
アクションはWordPressコアがdo_action()を呼び出すときにトリガーされる。

D

do_action関数

指定されたアクションフックに付けられた関数を実行する関数。
add_action()を使って関数をアクションフックへ付けることができます。

E

EXPLAIN

EXPLAINはSELECTステートメントの実行プランに関する情報を提供します。つまりSQLの実行計画、「mysqlが作成したクエリをどのように判断して実行したのか」というものが
見れるようなものです。
※P56、57
詳細はこちら

H

HTTPリクエスト

ブラウザからwebサーバーへの要求メッセージ
※P5
詳細はこちら

HTTPレスポンス

Webサーバーからブラウザへの応答メッセージ
※P5
詳細はこちら

S

SHORTINIT

WordPressの初期化処理を短縮するかどうかを示す定数。
※P25、105
詳細はこちら

SQLクエリ

SQLサーバーに格納されているデータに対する要求

W

WordPressクエリ

特定のページで必要なデータをデータベースから抽出するWordPress上のクエリ(要求)のこと

wp-blog-header.php

index.phpの次に読みこまれるファイル。
その構造は
・ブートストラップのロード
・wp関数の実行
・テンプレートローダーのロード
P19

wp-load.php

ブートストラップ(WordPressを起動して利用可能な状態になるまで自動的に実行する処理)として、WordPressの起動を実質的に制御し、WordPressを初期化する起点となる。
どのコントローラーからWordPressの実行が始まっても必ずインクルードされるファイル。
P17

フロントコントローラー方式

URLに関係なく、全て同一のファイルに一回全てのリクエストを受け、振り分ける仕組み。(クライアントからの値クエストを一箇所で受け付ける仕組み)。
※どんなURLが来ても実行されるのはフロントコントローラーでその後、各ファイルに割り振る(ルーティングする)。
WordPressの場合、Webサイトの表示においてはindex.phpがフロントコントローラーとなっている。
P7、13

ページコントローラー方式

役割ごとに別個のファイルが実行の起点となり、共通のコアライブラリを同じような順序で読み込み同じ仕組みでプロセスを実行するもの。
役割ごとのコントロールは別個のファイルがコントローラーとして機能する方式。
例)
管理画面の投稿編集・・・wp-admin/post.php
ダッシュボードの表示・・・wp-admin/index.php
P9、13

SHORTINIT

説明

WordPressの初期化処理を短縮するかどうかを示す定数。標準ではfalse(短縮しない)となる。
※trueに設定するとWordPressの起動プロセスを短縮させる。

例(wp-include/defualt-contents.php)

上記の例でSHORTINITをtrueに設定すると、wp-config.phpからロードされるwp-setting.phpの中盤で、データベースに接続したあとで、処理を停止して制御をコントローラーに戻します。

注意事項

主にバッチ処理などでデータベースを直接コントロールするための処理などの場合に用いる。利点は初期化処理を簡略化し、初期化処理を高速化することです。
この定数はwp-config.phpに記述することもの可能ですが、通常のWebサイトとして動作しているWordPressの場合には、表示が行われなくなりますので注意が必要です。

 

Microsoft AzureのVM DEPOTに仮想イメージを追加する

すでに作成されている仮想イメージをVM DEPOTに追加する方法についてまとめます。

自身のローカル上にある仮想マシンのパスを確認

この際、併せてそのマシンがシャットダウンしていることを確認します。

ひもづけるストレージを作成

自身のMicrosoft Azure管理ポータルにて、追加する仮想マシン用のストレージを作成します。

  1. 左メニュー「ストレージ」をクリック
  2. 新規 「DATA SERVICES」→「ストレージ」→「簡易作成」
    => URLなどの情報を設定し、アカウントを作成します。
  3. 追加したストレージをクリック
  4. 「コンテナー」をクリック
  5. 「コンテナーを作成する」をクリック
  6. 名前を入力し、「パブリックBLOB」を選択

仮想マシンをローカルから自身のMicrosoft Azure管理ポータルへ転送する

Azure Power Shellを使って仮想マシンを自身のMicrosoft Azure管理ポータルへ転送します

  1. Azure Power Shellをひらく
  2. アカウントへログイン

    と入力すると、Microsoft Azureのログイン画面が表示されます。ユーザー名とパスワードを入力しサインインします。
    サインインが完了するとPower Shell画面へ戻ります。
  3. VHDファイルをストレージアカウントに追加する(転送する)
    下記のように入力します。

    (※1)自身のローカル上にある仮想マシンのパス
    (※2)追加作成したストレージコンテナーのURL/作成するvhd名

  4. 自動で内容のチェックがスタートします

VM DEPOTへの登録

  1. VM DEPOTにアクセスし、ログインします。
  2. 右上部の「PUBLISH」をクリック
  3. フォームに必要な情報(最低限必須情報)を入力します。
    (1)Image name欄に当該仮想マシンイメージ名を入力します。
    (2)Image description欄に簡単な説明文を入力します。
    (3)「URL of the VHD file to publish」欄には先ほど転送追加したVHDファイルのURLを入力します。Microsoft Azureの管理ポータルで追加したストレージのコンテナーを開き、当該コンテナーの名前をクリックします。
    追加登録したVHDファイルが表示されますので、URLをコピーしてフォームへ入力して下さい。
    この際にURLはhttpとすることに注意します
    (4)Regions欄は適当なエリアを選択します。
    (5)Platform欄ではCentOSを選択します
    (6)EndPoints欄では80(http)と22(ssh)を設定します
    (7) I agree to the terms of use.*にチェックを入れます
    (8)PUBLISHボタンをクリックします

以上で完了です。VM DEPOTに登録されるには少しタイムラグがあります。

関数を利用して特殊文字をHTMLエンティティに変換する

ブラウザにソースコードを表示する基本的な考え方で特殊文字をエンティティ化する処理について書きました。

今回はその処理を手動ではなくプログラムで出力する方法について考えます。
htmlspecialchars関数を利用することにより、特殊文字をHTMLエンティティに変換する事ができます。

関数を利用して出力された文字列をコピーして、本ブログに貼り付け(テキストモード)て、適切な文字列として表示されることを目標にします。
今回は以下の3つの方法で実施してみます。

1.フォームに入力した文字列がエンティティ化されてブラウザに出力される

まず簡単なフォームを作ります。フォームに入力し「送信」をクリックすると入力した文字列が当該ページに出力されます。
http://www.yoshihiro.asia/test/test.php
※この時点ではまだエンティティ化を行っていません。

「hogehoge」と入力すると当該ページにそのまま「hogehoge」と表示されます。
次に「<strong>strongタグは強調します</strong>」という文字列を表示させたい際に、この文字列を入力し送信をクリックする、文字列がそのまま出力されるのではなく「strongタグは強調します」のように表示されます。入力した「<strong>strongタグは強調します</strong>」の「<strong></strong>」タグがhtmlタグとして認識されているからです。

入力した文字列がそのままの文字列として出力されるようエンティティ化する処理を加えます。
htmlspecialchars関数を利用することにより、特殊文字をHTMLエンティティに変換する事ができます。

※参考:http://php.net/manual/ja/function.htmlspecialchars.php

今回はhtmlspecialchars( $hoge );をechoの前に加え、入力した文字列$hogeのエンティティ化された値を出力するようにします。
http://www.yoshihiro.asia/test/test2.php

この処理により「<strong>strongタグは強調します</strong>」という文字列を入力した場合も、そのままの「<strong>strongタグは強調します</strong>」という文字列で出力されるようになります。
変換処理された結果ページのソースをみると「&lt;strong&gt;strongタグは強調します&lt;/strong&gt;」とエンティティ化されています。

またhtmlspecialchars関数は、デフォルトではシングルクオートの変換が除外されています。シングルクオートも変換したいので第2引数にENT_QUOTESを設定しました。これによりシングルクオートも変換されるようになりました。
※「”hogehoge”」を入力すると出力された文字列ソースでは「&quot;hogehoge&quot;」、「’hogehoge’」を入力すると出力された文字列ソースでは「&amp#039;hogehoge&amp#039;」とエンティティ化された結果が出力されています。

さらに<code>タグで囲むことでソースコードであることを示せ、<pre>タグで囲むことで「整形済みテキスト」として改行やスペースを書いたとおりに示すことができます。
変換し出力した文字列が<pre><code><strong>strongタグは強調します</strong></code></pre>のように出力される設定します。
http://www.yoshihiro.asia/test/test2A.php

出力された内容のソースコードを見ると「<pre><code>&lt;strong&gt;strongタグは強調します&lt;/strong&gt;</code></pre>」のように、エンティティ化された内容が<pre>タグ、<code>タグで囲まれています。
これを本ブログのhtmlにそのまま貼り付けると

のようにソースコードを記載することができました。

2.シェルで入力した内容を標準出力で表示させる

$argvを用いてスクリプトに渡された引数の配列を出力させます。
※$argvについては別途まとめます

まず新たに作成したtest3.phpファイルに以下のように記載します。

1で示したとおり、このままだと特殊文字をHTMLエンティティ化されていないので、htmlspecialcharsを追加します。(このままだと構文エラーとなってしまう)
またソースコードであることを示すため<pre><code>タグで囲んで出力するようにします。

このファイルを利用し、シェルに変換したい文字列を入力し、エンティティ化させて出力させます。
例えばシェルに下記のコマンドを入力すると、

下記のように標準出力されます。

これをそのままこのブログに貼り付けると、下記のようにソースコードとして表示されるようになりました。

3.別ファイルの内容を読み込み、エンティティ化した内容をブラウザに出力する

hogehoge.txtにあらかじめ出力させたい文字列を書いておき、そのファイルを読み込みエンティティ化させてブラウザに出力する方法を考えます。
まずはhogehoge.txtの内容を読み込むためfile_get_contents関数を利用して、test4.phpファイルを作成します。

エンティティ化を行っていいないので、「hogehoge」という文字列はそのまま出力されますが、「<strong>hogehoge</strong>」はhtmlの記述として処理されるので「hogehoge」に表示されます。
「<strong>hogehoge</strong>」をそのままの文字列として出力したいので、htmlspecialcharsを追加します。またソースコードであることを示すため<pre><code>タグで囲んで出力するようにします。

http://www.yoshihiro.asia/test/test5.php
出力された文字列はエンティティ化されているので、そのソースコードコピーして貼り付けると下記のように表示することができました。

パラメーターを引き回す

HTTPには「状態」という考え方がなく接続はWebページごとに切れてしまう

Webアクセスに使うHTTPプロトコルはブラウザからのリクエストとサーバーからのレスポンスの1往復のメッセージのやりとりで処理が完結するステートレス(クライアントとサーバーの接続の現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式)なプロトコルです。

Webブラウザは取得するWebページをHTTPリクエストでWebサーバに要求し、WebサーバーはHTTPレスポンスでWebページヘ返送します。
HTTPの接続はこの1往復のWebページ単位で切れるのが原則です。
※複数の画面をまたがることをもともと想定していない。

そこで複数のWebページをまたいだ一連の通信としてセッションという仕組みが考案されました。

セッション管理

複数のWebページにまたがった通信を認識するため、WebサイトがWebブラウザとの間のセッションを把握し、処理の状態を把握するためのセッション管理の仕組みが必要となります。

セッションの認識はセッションID(※)のやりとりで実現します。
(※)セッションIDとはアクセス中のユーザーの識別やセッション管理のために付与される固有の識別情報です。
WebサイトはセッションIDを発行し、Webブラウザへ送信します。Webブラウザから一連のアクセスで同じセッションIDが送信されればWebサイトは同一のセッションIDとして認識します。

セッションIDのやりとり

Webブラウザからリクエストを受けたWebサイトはページを生成すると同時に、セッションを識別するセッションIDを生成します。同時にセッション用データを格納するセッション・オブジェクトを作り、セッションの状態を保存しておきます。
その上でWebサイトは応答するWebページと一緒に生成したセッションIDをWebブラウザへ送信します。

セッションIDを受け取ったブラウザはそのサイトの一連のアクセスのときに(2回目以降のアクセスのときに)HTTPリクエストにWebページの要求とともにセッションIDをつけて送信します。
同一セッションであれば同じセッションIDが送られてくるので、WebサイトはそのセッションIDがに対応するセッション・オブジェクトを参照し、なかに書かれた状態情報をもとに処理を進めます。

セッションIDの受け渡しかた

WebブラウザとWebサイトはどのような手段でセッションIDをやりとりするのでしょうか。
主に3つのやり方があります。

1.Cookieを使う

CookieはWebサイトがWebブラウザに一時的にデータを書き込んで保存させる仕組みです。WebサイトがWebブラウザにCookieを送り、次回以降のアクセスで送り返してもらうという仕組みです。

Cookieを使うWebサイトはWebブラウザに送るHTTPレスポンスの拡張ヘッダにCookieとしてのセッションIDを書き込んで送ります。Cookieを受け取ったブラウザはそのCookieを保持し、そのWebサイトへの一覧のアクセスのときにHTTPリクエストの拡張ヘッダにCookieをつけて送信します。
Webサイトは受けとったCookieに含まれるセッションIDを見てセッションを識別します。

2.GETメソッドによるパラメーター渡し

Webブラウザの設定でCookieを禁止している場合など、CookieでセッションIDをやりとりできない場合があります。
そのような場合にはWebページ内に埋め込むURLにセッションIDを付けGETメソッドでサーバーにセッションIDを渡すことができます。
セッションID付与されたURLが埋め込まれたWebページのボタンやリンクをユーザーがクリックすると,埋め込まれたURLがHTTPリクエストによってWebサイトに送られます。
送られたHTTPリクエストからWebサイトはセッションIDを受け取ります。

GETメソッドの方法を使うWebサイトはURLの後ろに「ssid=12345」のようなセッションIDをパラメータとして付けます。そのパラメータが付与された「http://www.example.com/?ssid=12345」のようなURLをWebサイトへ送ります。
Webサイトはパラメータとして「ssid=12345」というセッションIDを受け取ります。

この際、要求するセッションIDがWebブラウザのアドレス・バーに表示されます。

3.POSTメソッドによるパラメーター渡し

Webページに入力したデータをWebサイトに送るための機能であるフォームを使ってセッションIDをやりとりするには,Webページを記述するHTMLデータの中のフォーム・データにセッションIDを埋め込んでおきWebアクセスでフォーム・データの一部としてセッションIDを送信することができます。
POSTメソッドで送ることで、データはHTTPリクエストのボディ部として送信されるため、URLにセッションIDは表示されません。