セキュリティ
なぜWord Pressが危ないと言われる？
- ユーザが多くなっているから
- WordPressに起因するセキュリティ事件が多発
- プラグイン・テーマの脆弱性が見つかる
Word Press の安全への取り組み
- 本体のセキュリティアップデート
- セキュリティプラグインが登場
- セキュリティ関連の情報が増加
余談
どのCMSでも問題はある！
→みんなでセキュリティに取り組むことが重要！
攻撃の種類
よく来る攻撃
- ID・パスワードに対する攻撃
- プラグインとテーマに対する攻撃
- サーバの設定上の問題に対する攻撃
ID・パスワードに対する攻撃
パスワードに対する総当たり攻撃（1000 ~ 10000件ほど）定期的にツールによって来る
パスワードの攻撃傾向
- admin
- administrator
- admin123
- ドメイン名(小文字)
- 123456 etc...
プラグインとテーマに対する攻撃
継続的に攻撃が来る
サーバに対する攻撃
- ファイルのパーミッション設定の問題
- サーバ認証(SSH)の不備
- FTPにを利用すること
運用者側の注意
- 使っているものは最新版に保つようにしておく →使えるならば自動アップデート機能
- アカウントの管理をしっかりする
- テーマ・プラグインの選定をする →メンテナンス頻度が高いものを選ぶ
開発者の注意
- ファイルのアップロード機能に注意
- HTTPパラメータでファイル名を指定している場合、ディレクトリトラバーサルができる
- XSS・SQLインジェクション・CSRFを防ぐ関数・メソッドが存在するのできちんと使用する
初心者の注意（※民間療法込み）
- ローマ字でパスワードを設定する
- 大体一年以内に更新されているもの・ユーザー数がある程度多いもの（有料・無料はほぼ関係なし）
- レンタルサーバを利用して、WPを使う
安全のお供に
公式テーマディレクトリ登録に挑んだ話
ギャラリーサイト向けのWPテーマ
- レスポンシブ
- 二つのファイルだけで構成する
テーマレビュアーって？
目視でコードを読み、テーマをレビューするボランティアの方
→興味がある方はぜひ！
リモート&非同期作業で開発するためにやったこと
- ワイヤー作成とデザイン作成は最短の時間・最小の手戻りで。
- エディターのセッティングの統一化（.editorconfig）
- GitHubのコードを自動でglupを使ってコンパイルする
- issueをもとにGitHub-Flow っぱい開発を行った
- コンポーネントごとにscssファイルを分けておいた
- メンテナンスしやすい
- チーム開発でのコンフリクトが起きにくい
チーム開発をする上で起きた問題
問題
- issue多すぎてどれがどれだかわからん
- 全体の進捗具合がわからん
- どれがやってるのかわからん
とりあえずの解決
→タグやマイルストーンを設定した。
→しかし、種類が多い・人それぞれの度合いでつけていた問題が起きた
解決法の反省点
- タグ・マイルストーンのルールを周知し、厳密に運用すればよかった
- マイルストーンに具体的な日付を入れればよかった
- Assigneeを使えばよかった
まとめ
ディレクター
- リーダーシップ大事
- メンバーを引っ張りまわせばよかった
- 設計段階でもっと話を詰めればよかった
デザイナー・環境構築
- WPの構造を熟知しておけばよかった
- チームの担当者のフローをきちんと考えておけばよかった
デベロッパー
- 普段と異なる職域の仕事は時間があるときに
- リーダーシップをとる人はきちんと決めておけばよかった
PHPのトレンド(関西PHPUG)
PHP 7.0.0
コア言語エンジンが変わると、メジャーアップデートされる
使用感
- ローレベルなテクニック回り・拡張回りに差が出る程度
- ほとんどのツールが継続して利用できる
PHPStorm
- Vim/Emacsの利用者がIDEに移行していっている
- FTPでのファイル同期が簡単にできる
- 手元で書き換えたファイルとサーバーで書き換わったファイルの差分を簡単に見ることができる
PSR-0/1/2
オープンソースPHPのライブラリが互いに仲良くすることを目的にするPHP-FIGが策定している基準
WordPressは未加入
アメリカとEUみたいな感じでもともと大きなWordpressのコミュニティがあるので、加入していない
Composer
- PHPパッケージ管理ツール
- PSR-0/4に準拠すればrequire_once不要
- Packgist
- wp-cliよりも冪等性が高い
PSR-7 (RESTful API)
- RESTful APIとマイクロサーバを定義する基準
Codeception
- 自動フレームワーク
- 受け入れテスト・昨日テスト・単体テスト
- WPは単体テストが難しい
→とても読みやすいテストプログラム作成ツール
WP対応がよくされている
受け入れテストのコツ
正常バージョンのテストだけをメインでやり、べつの複雑な部分は他のものでテストすればよい
WordPressのDockerize(Docker化)
仮想化とDockerの違い
- 仮想化ではOSの起動など、重量な部分があるが、DockerならDocker
Dockerを使うための方法
Vagrant & VBox
Vagrantって？
VirtualBox のコントローラー的な位置づけ
（DockerはネイティブでMac/Windowsに対応していないため、VBoxなどを使ってLinuxを使う必要がある）
おすすめのLinux OS
- Boot2Doocker
- RancherOS
- Barge OS
DockerTool
- KiteMatic
- Docker GUI
- Docker Hub
- GitHubのようなWebサービス
Docker for Mac/Windows
オープンベータ状態のネイティブに近い Mac/Windows 用Docker
※ある程度新しいものでないと対応していないため注意
Dockerが走るまで
- Dockerファイルを書き出す ↓
- Docker Imageを作る（タイ焼きの型） ↓
- Docker Containerを作る（タイ焼き）
Dockerファイルのベストプラクティス
- .dockerIgnoreファイルを使う
- 不必要なパッケージは入れない etc
Dockerは過去にビルドした部分をキャッシュする
以前にビルドした内容はキャッシュに残り、新たに実行・追加されたものだけビルドされる。
WordPress RESTful API & Amazon API Gateway (Twitter @shimy_net)
REST APIって？
RESTのREsouse(リソース)はURIで表現し、アクセスできる形にしたリソースのこと。また、APIを使ってそれにアクセスできるサービスのこと
外部データをWPに表示
都合のよいAPIがない
お天気情報があるが、地図情報がないetc
APIを新規作成・保守するのは大変
- バージョン管理
- APIキーの管理
- トラフィック管理 etc...
そこでAWS API Gateway
- バージョンの管理
- APIのキー管理
- サーバーレスな環境
- DinamoDBやLambda（AWS内のサービス）でラッピングすることができる
3rd Party APIを集約・ラッピングできる
WP REST APIをキャッシュ・スロットリングができる
AWS+WordPress.SkeletonでスケーラブルなWordPressサイトをつくる
WordPressサイト複数台運用の課題
メディアファイル・プラグイン更新などが片方にしか適用されない
AWS と WP.skeletonで問題解決
メディアファイルが片方にしか保存されない
AWSのS3に画像を転送し、そこにアクセスさせる。
プラグイン更新が適用されない
WP.Skeletonディレクトリ構成テンプレート
Composerでパッケージ管理させる
Blue-Green Deployment
コアの更新時やComposer update時には全サーバ同時に行う必要があるので、サイトが停止してしまう。
→現在の構成と同じものを作成し、作成した方の準備ができてからアクセス先を切り替える手法
それでも残る課題
- コアのDBマイグレーション
- wp-cli update-dbで実施可能
- WPプラグインのDBマイグレーション
- 言語ファイルのダウンロード（Composerで管理できない）