先週の土曜日はSaCSS Special11:WordPress特集に参加してきました。
普段はMovable Typeばかり触っているので、WordPressは過去に数回程度しか構築した経験がありませんでした。
セキュリティ部分は個人的に気になっていたので、参加してみました。
WordPress「超」スピードアップ術 ～のろまなカメと呼ばれないために～
WordPressのスピードアップするポイントについてのセッションでした。
ハード面のチューニング・WordPressの実装チューニング・実案件でのチューニング例・ボトルネックとなっている部分の見つけ方などを紹介してくれました。
ハードウェアによるスピードアップ
- サーバスペックの選択（CPUの選択）
- サーバの記憶媒体（HDD→SSD）
PHP実行環境によるスピードアップ
- PHP7の採用
- 中間コードキャッシュ
データベースによるスピードアップ
innodb_buffer_pool_sizeやquery_cache_sizeの設定の見直しを行うと良いそうです。
この辺は、WordPress限らずデータベースを扱うものに関しては行うべきかと思いました。
- データベースのリクエスト自体を少なくする
- リクエストあたりの処理自体の短縮させる
Transients APIの利用
Transients API この API はキャッシュされるデータを一時的にデータベースへ保存するためのシンプルで標準化された方法を提供
データ・コード・コードの実行を一定時間再利用する機能で、この機能でコードを再利用することで本来のコード実行時間を短縮することが可能になるようです。
WEB API取得や処理が重たいPHPのコードを実行する時に有効のようです。
実装する際は、Transients APIは頭にいれておきたいところですね。
保存時
<?php set_transient( $transient, $value, $expiration ); ?>- $transientは識別子（他と被らないように注意が必要）
- $valueは保存するデータ
- $expirationは有効期間
取得時
<?php $value = get_transient( $transient ); ?>- Transientの取得結果が入る
- 無い場合は、falseを返す
ボトルネックの見つけ方
処理時間を表示させる
処理時間を表示させるコードを埋め込むことで、どこの処理で時間がかかっているのかを把握できるように
実装中・テスト時には設定しておくことも良いそうです。
<?php echo __LINE__ . ' | '; timer_stop(1); echo "Yn"; ?>__LINE__コードを書き込んだ行- timer_stop(1); コードを書き込んだ時点でのWordPressの処理時間
- echo “Yn”; 改行コード
上記のコードをテンプレートの区間（ヘッダーやフッターやサイドなど）に設定しボトルネックとなる部分を見つける。
原因となっている部分・そうでない部分の切り分けすることで、改修や調整が必要な部分にフォーカスして対応が可能になるようです。
小川流！わかりやすいテーマの作り方
わかりやすいテーマ作りについてのセッションでした。
CMS全般に言えますが、作業者が変わってもスムーズに渡せるような理解しやすいテーマ作りは大切だと改めて思いました。
セッションで話された極力さけなければいけない条件分岐の複雑化・テンプレート数のまとめ方などがあげられました。
WordPressのテンプレートの構成って理解していない部分が多いので、なんとなくでメモしておきました。（笑）
テンプレートを増やしすぎないように注意する
テンプレート数が多くなると、ファイル管理が大変になるため似たような処理はまとめて1テンプレートになるよう構築する。
- 引数ありのパーツテンプレートをfunction.phpに記述する
- $wp_query->query_vasを介してテンプレートファイルや変数の受け渡しをする
- カスタムフィールドを使って trueかfalseを判別させる
Movable Typeでも設定configテンプレートモジュールやSetVarTemplateなどを使って処理をまとめておき、必要に応じて出し分けをする手法をとったりしています。
似たようなことは、当たり前ですがWordPressで実装していたりするのですね〜という印象でした。
複雑すぎる条件分岐をしてはいけない
条件ブロックコードが多くなると、見通しが悪くなる上に違う作業者も理解するのが大変になります。
そういったことにならないように、条件分岐の見直しが必要になります。
Movable Typeでもmt:Ifってあるのですが、テンプレートで条件分岐したり値の判別とかで使われたりしています。
これが複雑になると、エラーやテストした際にどこが原因で問題が起きているか判断しずらくなります。
index.phpを404ページとして活用する
テンプレートの構成とかよく理解していないですが、index.phpは必要なファイルですが、実際はファイルがあるだけで何も記述されていないことが多いようです。（トップページはhome.php）
このあたりは、なぜindexが必要かあとで調べようと思いました。
セッションでは、この実際なにも記述しないindex.phpを404として使う方法があげられていました。
理由としては以下になります。
- 想定外のページにアクセスがあっても404を表示させることが可能
- 404.phpを作る必要がなくなる
ここから始めよう！WordPressのセキュリティ
WordPressのセキュリティについてのセッションでした。
前職でもWordPressの保守（主にアップデート）対応が多く大変だった印象を持っている自分だったので、どういった対策が必要なのかを改めて聞いてました。
利用者が多くプラグイン数もたくさん出ているため、他のCMSより脆弱性の情報が他のCMSより多く出てしまいます。
最近では、REST APIの脆弱性出たりと大きな話題になりましたが、WordPress自身の脆弱性自体は、そんなに多くはないようです。
メンテナンスされていないプラグインやプラグイン実装者のセキュリティ知識の差で起きたりすることが多いようです。
どのCMSも言えることだと思いますが、利用者が多いという点では出て来る情報は多いと思います。
使う側としては、プラグインがアップデートや脆弱性に対応できているかきちんと選んで利用することが大切かと思います。
セッションでは、最低限のWordPressの設定などの方法や「SiteGuard WP Plugin」の紹介の内容でした。
脆弱性対策
- 最新バージョンを使用する（コアだけでなく、テーマやプラグインも同様）
- 脆弱性を悪用した攻撃の検出、防御するソリューションを活用する（WAFなど）
- 自動アップデートを有効活用する
不正ログイン対策
- ログインパスワードを強固にする
- ログインページを保護する（アクセス制限やセキュリティプラグイン）
全体を通して
WordPress触っていない自分としては、Movable Typeではこうするかなって部分と照らしながら聞いていました。
今後、WordPress構築も仕事になった場合は、覚えておきたいセッションでした。