2018年10月05日

WordPress の記事保存時のフックについて

とあるサイトで、WordPress で記事を保存したときに独自の処理を行うためにフックを設定しています。

通常の記事を保存したときに処理をさせたいときは publish_post フックを設定しますが、今回はカスタム投稿タイプに対して設定したので publish_news というフックを設定してあります。

とりあえず動作していたのですが、どうも思ったようにフックが動いていないときがあるようで、調べてみたところ「非公開」にチェックを付けて保存したときは publish_news フックが呼ばれないことがわかりました。
(フックの名前に publish と入っているので、「非公開」のときに呼び出されないのは名前を見れば自明かもしれませんが、すぐには気が付きませんでした。。。)

「非公開」として保存されたときをフックするにはどうするかというと、private_news というフックを使用します。WordPress のドキュメントでは {status}_{post_type} と書かれています。ステータスと投稿タイプがn対nで組み合わされるということで、他にもいろいろなパターンがあります。

詳しくは下記のページに書かれています。
投稿ステータスの遷移


posted by はるこち at 19:00| Comment(0) | WordPress | このブログの読者になる | 更新情報をチェックする

2018年08月07日

カスタム投稿タイプで publish_post のアクションフックを使用したいとき

カスタム投稿タイプを保存したときに処理をさせたかったのですが、記事を保存したときに処理をさせるには publish_post というアクションフックを使用すれば良いということがわかったので
add_action('publish_post', 'my_news_func', 10, 1);

と書いてみたのですが、何度保存してみても関数が実行される気配がありませんでした。

正解は、カスタム投稿タイプのタイプ名をフック名に反映させます。例えば「news」というカスタム投稿タイプなら publish_news になります。
add_action('publish_news', 'my_news_func', 10, 1);


参考:
Plugin API/Action Reference/publish post ≪ WordPress Codex
posted by はるこち at 19:00| Comment(0) | WordPress | このブログの読者になる | 更新情報をチェックする

2018年06月13日

超高速WordPress仮想マシン「KUSANAGI」 を ESXi で使ってみた

WordPress を高速化する方法をネットで探しまくっていたら、kusanagi というパッケージを見つけました。
超高速WordPress仮想マシン「KUSANAGI」について – KUSANAGI
kusanagi-banner-1024x3081-1.jpg

KUSANAGIのインストール


仮想サーバにインストールできる仮想マシンとして作られているので、仮想サーバを用意できれば、短時間でWordPressの環境を作ることができます。しかも無料で使えるとのことでしたので、早速 ESXi サーバにインストールしてみました。

「KUSANAGI」は各種仮想環境用のパッケージが用意されているので、「KUSANAGI for VMware」をダウンロードしました。対応する仮想環境の一覧や、詳しいインストール方法についてはホームページに記載されているので、それらを見ながら進めれば難しくないと思います。

ESXi の管理画面から新しい仮想サーバを作成し、OVAファイルのデプロイを行うと仮想サーバが作られます。
kusanagi-001.png
仮想サーバは CentOS7 で作られていて、ある程度のファイルはインストール済みの状態になっていますが、「KUSANAGI」はセットアップされていないので、コンソールから「KUSANAGI」をセットアップします。

KUSANAGIのセットアップ


詳しい手順はホームページに記載されている説明を参照していただくとして、概要は下記のようになります。
1.yum update
必要なパッケージのアップデート
2.kusanagi init
タイムゾーンや言語などの基本設定と、使用するパッケージの選択

使用するパッケージは下記の中から選択できます。

Webサーバ:Apache / Nginx
アプリケーションサーバ:PHP5 / PHP7 / HHVM
Ruby:2.4 ※選択画面は表示されるのですが選択肢は1個だけでした。
RDBMS:PostgreSQL / MySQL ※PostgreSQLが選択肢に表示されましたが実際に動くかどうかは未確認です。

これらは、原則としてインストール後もコマンドラインから切り替えができるのですが、PHP7 → PHP5 への切り替えはできませんでした。
いまどれが選択されているのかは kusanagi status コマンドで確認することができます。

KUSANAGIのプロビジョニング


つぎに「KUSANAGIのプロビジョニング」を行います。使用したいシステムによって内容が異なりますが、WordPress を使いたいので --WordPress オプションを付けました。
# kusanagi provision --WordPress www


また、Lets Encrypt の設定もここで行うことができます。今回は設定しませんでしたが、自動更新の設定もできるようです。

WordPressのインストール


新規にサーバを立ち上げる場合はここでWordPressのインストールを行いますが、今回はすでに稼働しているサーバから引っ越すので、BackWpUpで作成したアーカイブファイルを転送して、それをもとに作成することにしました。

アーカイブファイルは /home/kusanagi/www/DocumentRoot ディレクトリに転送します。
コンソールから下記のコマンドを実行してファイルを取り出します。
# cd /home/kusanagi/www/DocumentRoot
# unzip -x backwpup_xxxxxxxxxx_9999-99-99_00-00-00.zip

ファイルのオーナーが合わないので、全ファイルのオーナーを変更します。
# chown -R httpd.www *

MySQLデータベースのダンプからデータベースを復元します。
# mysql -uwordpress -p www < wordpress.sql


細かい調整


これで一応データの移行はできたのですが、あちこち調整してあげないと動かない箇所があります。
・wp-config.php : データベースのユーザー名とパスワード
・Apacheを使う場合の設定ファイルは /etc/httpd/httpd.conf ※なんかちょっとパス名が変わってました
・Nginxを使う場合、パーマリンクを /$post_id だけにしている場合は下記の設定を 追加
location / {
try_files $uri $uri/ /index.php?$args /index.php?q=$uri&$args;
}

・DocumentRootとか、ホスト名とか、ユーザー名とか。

使用感


コンテンツの偏りがあるかもしれないので参考にならないかとは思いますが、
・ApacheよりはNginxのほうが早く感じました。
・PHP5よりもPHP7のほうが早く感じました。
・PHP7とHHVMはそれほど差を感じませんでした。

移行した結果


今まで使っていたサーバが低スペックだったので単純に比較はできないのですが、それなりの速度向上は得られたと思います。ユーザーごとのコンテンツ制御を行うなどプラグインを大量に使いまくっているサイトですが、ページキャッシュ無しでも1秒未満で表示されるようになりました。ページキャッシュ用プラグインはお払い箱になりました。
反面、ページが読み込まれてからブラウザ上で実行されるJavaScriptの遅さが目立つようになったので、ブラウザ側で実行される処理を軽くする必要が出てきたように感じます。まだ具体的なチューニングはしていませんが、Autoptimize を使用して「HTMLの最適化」と「CSSの最適化」を行うように設定しました。
posted by はるこち at 18:00| Comment(0) | WordPress | このブログの読者になる | 更新情報をチェックする

2018年02月27日

User Access Manager(UAM) が遅いとき

WordPress を使って構築しているサイトで、ログインユーザーごとに見せる情報を制御したかったので、User Access Manager(UAM) プラグインをインストールして設定しました。

設定自体はそれほど問題はなかったのですが、その後、どうもページが表示されるまでの時間が遅くなったような気がしていました。

他にも色々なプラグインをインストールしているので、どのプラグインが原因なのかわからず原因究明できずに居たのですが、PHPのプロファイラを使用して調べたところ、UAM の内部で処理時間が増大していることがわかりました。

その関数名をもとにソースコードを調べてみたところ、どうやら管理者でログインしているときにロックマークを表示させる機能が原因らしいことがわかりました。
20180227-wordpress-uam.png

ソースコード上でコメントアウトして無効にしてみたところページが表示されるまでの時間が大幅に短くなりましたので、管理画面で UAM → その他 → ロックマークを表示させるを「いいえ」にしました。

ブラウザのデベロッパーツールの表示によると、修正前は表示が完了するまで4〜5秒かかっていたのが、2〜3秒になりました。
posted by はるこち at 19:30| Comment(0) | WordPress | このブログの読者になる | 更新情報をチェックする

×

この広告は180日以上新しい記事の投稿がないブログに表示されております。