フォーラムへの返信
-
投稿
-
キャッシュデータ自体は、有効期限が切れた時にクリアしているわけではなく期限切れの古いデータとしてキャッシュデータのテーブルに残っています
有効期限が切れた次の同じURLアクセスの時にキャッシュを使わない通常の WordPress の出力を行い、その出力データと新たな有効期限データを古いキャッシュデータに対して上書き更新します
一方、キャッシュクリアボタンは内部で使用しているSQLiteデータベースのキャッシュデータテーブル自体を一回消して再生成するので、キャッシュデータが消されて初期のキャッシュデータテーブル状態に戻ります
従って、重くなる原因がキャッシュデータのサイズに関連していると仮定すると、同じような状況になった場合は、手動でキャッシュクリアを行ってください。
また、WordPress の設定値や、プラグインやテーマの設定変更、追加、削除等を行った時には手動でキャッシュクリアする必要がありますので忘れずに実行してください
データベースが破損しているかどうかは、データベースファイルを直接調べてみないとなんともいえません。
ただ、20日たって再現したというのはデータベースファイルのサイズが大きくなってきたときに何か問題があるのかも知れません
ちなみにサイトで公開している記事数はどのぐらいでしょうか？
仮にサイトで500記事あるとすると、キャッシュデータとしては各記事毎に１つというわけではなくて、このキャッシュプラグインでは1つの記事に対してアクセスしてきたURLを元にキーコードを生成して保存しています
どういうことかというと 通常のパーマリンクによるアクセスやショートURLによるアクセス、あるいは post?=xx というような形式のアクセス、AMPサポートしているなら ?amp=1 というようにクエリーを含めたURLをキーとして保存するので一つの記事に対してキャッシュデータは4個ぐらいは普通に生成されます
従って５００記事だと2000-3000程度のキャッシュデータが作られているかも知れません
本来なら記事数なんて日々何十本も増えていかないと思うので日にちが立ったからといってデータベースのサイズが特別大きくなるわけではないのですが、このような方式でキャッシュを保存している関係上URLに不必要なクエリーが付いている場合（不正アクセスの場合が結構ある）に WordPress がそれを 404(ページがありません)と判断せずに何らかのページアクセスとして表示してしまうとそれをキャッシュとして保存するので必要以上にキャッシュファイルが大きくなる場合もあります
キャッシュクリアを実行すれば、SQL操作としてはキャッシュデータテーブルを一旦消してから再生成していますので、対策としては、定期的にキャッシュクリアを行っていただくしかありません
ちなみに Ver1.4.5 では、キャッシュクリア時や記事更新画面でキャッシュの有無を判断する時に使っていたSQLで SELECT * というように本来判断には不要なデータまで取得して判定しようとしていたので（このためにおそらく前回報告のあったメモリーエラーが発生）、ここを SELECT key と必要なデータだけ取得するように変更したので、動作が重くなった場合は、アンインストールー＞インストールしなくてもキャッシュクリアの実行だけでいけると思います
また、Ver1.4.5 で追加した CSS, JS の小さなファイルのインライン埋め込み機能はキャッシュデータが大きくなるので使わないほうが良いかもしれません
以上
いろいろ想像しながらお答えしましたが的外れかも知れません
他の方で同じような症状になる方がいましたら情報をお寄せください m(__)m
開発側の都合により amp / url filter が旧バージョンと互換がなくなってしまったので再設定してください m(__)m
エキスパート用URLフィルタ（url filter for expert）の AMPキーワード設定欄に amp と設定していただくと表示されるようになります
表示ずれはフォントサイズがちょっと大きかったみたいで amp を設定しないとずれて見えますが、設定していただければ気にならなくなると思います (^_^;)
更新内容については下記記事で紹介しています
Plugin Load Filter Ver3.0 公開
WordPress のパフォーマンスをちょっとアップする Plugin Load Filter Ver3.0 を公開しました。YASAKANI Cache プラグインと併用すれば超高速なサイトが構築できます (^^)
セルティスラボこれの関連ですね
管理画面の投稿ページが重い
ホーム › フォーラム一覧 › YASAKANI Cache フォーラム › 管理画面の投稿ページが重い このトピックには9件の返信、2人の参加者があり、最後にe… セルティスラボあの後も新規投稿画面にてプラグインを動作させないようにしているのですが、それでもWordPressの自動下書き保存プログラム（admin-ajax.php）のリクエストの際、YASAKANI Cacheを有効化していると保存に20秒以上時間がかかります。
既存ページの更新時に以前行った対策が効かず時間がかかっているということでしょうか
同じ状況を再現できればいいのですが、現時点では原因不明なので対応が難しい状況です m(__)m
jQueryの ajax のタイムアウトとの関連も不明です
メモリに関しては どの程度必要かは一概には言えませんが、512M で足りないというのは考えにくいです
YASAKANIキャッシュのデータベースが何らかの原因で破損している可能性もありますので、一度、プラグインをアンインストールして（この時に /wp-content/yasakani-cache/yasakani_cache.db ファイルが自動的に削除されます）から、再度、プラグインをインストールして症状が改善するか試してみて下さい
※設定値や修正コードクリアされます
いえいえ、まだまだ利用者が少ないプラグインなのでいろいろなケースで不具合が残っているかもしれません。どのような情報でもありがたいです
wordpress 設定の一般の WordPress アドレスとサイトアドレスのURL が同じなら恐らく問題ないと思うのですが、異なっているときの処理がちょっと足りないかなという気がしています
異なるアドレスの場合のアクセスをいろいろ検証して、対策の必要有無を含め判断したいと考えています
解決出来たようでよかったです
結局どのような設定が原因だったのかよくはわかりませんが、post branch utility は全く関係していなくて .htaccess の設定により不具合が生じていたということで了解しました
サイト名は除いて比較しているのですがおかしいですね
ダイレクトアクセス拒否から除くphpを、yasakaniの設定画面で指定し直す必要があります。
現状（/wp-signup.php）
⇒変更（ドメインＡのドキュメントルート/wp-signup.php）みたいにです。自動的に設定されるはずの /index.php、/wp-login.php も、同じくyasakaniの設定画面でドキュメントルート付きに設定し直すことができます
wordpress 設定の一般にある WordPress アドレスとサイトアドレスのURLはどのような設定となっていますか？
リクエストされてきたURLからそこに設定しているURL部を除き、ダイレクトアクセス拒否から除外するPHPを照合しているのでドキュメントルート部は除外して問題ないはずなんですが
もしかしたら WordPress アドレスとサイトアドレスが違っている時に、比較すべきアドレスを取り違えてるのかも？
新規テスト環境を作り wordpress 4.9.4, PHP7.2.2, パーマリンク /news/%post_id/% でもう一度確認してみました
コピー元
パーマリンク：http://localhost/wordpress/news/4/
プレビューボタンのリンク先：http://localhost/wordpress/news/4/?preview=true => 表示される
コピーブランチしたもの
パーマリンク：http://localhost/wordpress/?p=12&preview=true
プレビューボタンのリンク先: http://localhost/wordpress/?p=12&preview=true => 表示される
Wordpress をサブディレクトリにインストールしたのでURL内に /wordpress が入っていますがどちらも問題なく表示されます
現象としては ?p=xxx の表示が出来なくなっているように見えます
どこかで ?p=xxx のようなURLに対するアクセスを禁止していませんか？
何かのプラグインを導入して禁止されたままの状態が残っているのかも知れません
おおー 良く調べましたね (^^)
.usr.ini 知らなかったです
調べたところ .htaccess の代わりに活用できるみたいです。Apache 以外でも使えるので大元の php.ini に書くより使いやすいかも知れませんね
注意点としては
- PHP 5.3 以降
- PHP CGI/FastCGI SAPI の場合のみ
- ユーザー INI ファイルの再読込頻度 は user_ini.cache_ttl で指定可. 未指定時のデフォルト5分 なので .usr.ini 設定変更時の反映に時間かかる
ちょっとすぐに確認できる環境が用意できないので実際に動作確認はしていませんが、問題なく .usr.ini を設置したサイト毎に各々エキスパートモードにすることが可能と思われます
エキスパートモードの一番の特徴は、PHPスクリプトゼロデイ攻撃の防御機能なので実は高速化は副産物のようなものです
設定オプションの “PHPスクリプトゼロデイ攻撃” をチェックしてから、サイトのプラグインのPHPを直接アクセスしてみて下さい。例えば (サイト名)/wp-content/plugins/yasakani-cache.php など。
通常ではお探しのページが見つかりませんなどと表示されるのが、代わりにアクセスが拒否されればエキスパートモードのPHPスクリプトゼロデイ攻撃の防御が働いているのがわかります
※WAF等でセキュリティ対策をしている場合は様子がかわるかも知れません
貴重な情報ありがとうございました
動作確認してみましたが、私の環境では問題なくプレビュー出来ています
プラグインかテーマの影響の可能性が高いと思いますので以下の手順で確認してみて下さい
１．テーマを公式の Twenty Seventeen 等に変更して確認
これでプレビュー出来た場合は、テーマに何らかの問題があります
２．Celtispack 以外のプラグインを停止
これでプレビュー出来れば停止したプラグインの何れかに問題がありますので、一つずつ有効にしていきどのプラグインが問題かを確定させてください
３．これでもプレビューできない場合は、WordPress や PHPのバージョンの違い、JavaScriptでエラーが起きていたり等が考えられます
症状からするとYASAKANIキャッシュに何かしら問題ありそうですが、原因が特定できません
プラグインの先頭に「if ( is_admin() && ( $pagenow ～～」のコードを追加することで（投稿ページで読み込ませなくすることで）、今の時間は新規投稿ページの読み込み速度が0.7秒台で安定しています
ただ、これと同じ対策をしてしまうとキャッシュから除外する機能が使えなくなってしまうので出来ません
何かわかったら対策ということで様子見とさせてください m(__)m
ドメインAとドメインBが別々の php.ini 設定を行えるなら問題ありませんが、同一サーバーの同じPHP環境で php.ini ファイルが共通に使われる場合には php.ini を使ったエキスパートモードは問題があります
対策というか、方法としては php.ini でなく各ドメインにおけるドキュメントルートにある .htaccess を使えば別々に指定するすることが可能となります
.htaccess への auto_prepend_file の設定は、環境によっては許可されていない場合もあるのですが、可能ならドキュメントルート下の .htaccess を編集してみてください（許可されていない場合は 500 サーバーエラー等で真っ白画面です）
.htaccess への記述は php.ini とちょっと変わり下記のようになります
php_value "auto_prepend_file" "設定画面に表示されている yasakani-cache-exload.php".htaccess で設定できない場合は、エキスパートモードを使わずにご利用ください
報告ありがとうございます
いくつか確認させてください
マルチサイトでなく、シングルサイトを２つ作成してる状態で、ドメインAのサイトとドメインBのサイトは別々にYASAKANIキャッシュプラグインをインストールして、ドメインA、ドメインB共にエキスパートモードしたら不具合が発生
対策として、ドメインAを通常モード、ドメインBをエキスパートモードにしたら正常化したという認識でよろしいでしょうか
ちょっと想定外というか php.ini の auto_prepend_file を２つのサイトで使用することは考慮していませんでした (^_^;)
対策が可能かどうかも含めて調べてみないと何とも言えません
うーん ダメでしたか (>_<)
振出しに戻ってしまいましたね
今のところ他に思い当たる要因はないんですが…1.6～15秒 ってYASAKANIキャッシュ以外の要因もあるかもしれませんね
実稼働のサイトではお勧めできませんが、テスト用のサイトで同じように状態を再現できるならば Prime Timeline というプラグインがあります
このプラグインを使って、新規作成のページを作るときのログを確認すればどこで時間がかかっているかあたりをつけることが出来るかも知れません
可能ならテスト環境で（実際の運用サイトは止めといてください）どこに時間がかかっているか調べることで YASAKANI キャッシュ以外の原因が見つかる可能性もあります
