wp-config.phpを設定し直していたら出てきた謎設定
何年もWordPressを運営していると…
という
いつ設定したんだかわからない
そもそも使ってるんだかすらも怪しい
そんな謎の過去の遺物が発見される。
今回はその1つ『WP_CACHE』を紹介する。
正体：それは「高速道路への通行許可証」
WordPress本体に「通常の処理をバイパスして、キャッシュファイルを読み込め！」と命じるためのフラグ。
wp-settings.php が読み込まれるより前に、wp-content/advanced-cache.php を強制召喚する。
例えるなら「注文を受けてから作る牛丼屋」が、店頭の「保温棚」から直接渡すモードに切り替わるスイッチ。
鉄則：書く「場所」が命！
wp-config.phpの一番上(<?phpの直後)でなければならない。※鉄則
下の方に書くと、既に「牛丼」を作り始めてしまっているので、保温棚（キャッシュ）を確認する意味がなくなる。
処理ダブりだよね。
実態：プラグインとの「主従関係」
WP_CACHEをtrueにするだけで速くなるわけではない。
これを受け取る 「キャッシュプラグイン（受け皿）」 がいて初めて意味を成す。
例えば『WP Super Cache』『W3 Total Cache』『WP Fastest Cache』『WP Rocket』あたりが、使う代表プラグイン。
他にあるかも知れないけど、知らない。プラグインって数多いし…
プラグインを消したのにWP_CACHEだけ残っていると、存在しないプラグインを探し続けてサイトが重くなる（ゾンビ現象）。
※静かなる怒り
運用：開発環境では「罠」になる
「CSSを直したのに反映されない！」
「PHPを書き換えたのに動かない！」
という時間の無駄は大抵これのせい。
使う場合でも
開発中は falseまたは削除。
本番公開の直前にのみtrueがオススメ。
WP_CACHEに依存しない場合が多いので、混同注意。SQLite環境における「WP_CACHE」
当方WordPress✕SQLite。
やってることは⇩
wordpressをSQLiteで動かそう
その環境においての話。
SQLite環境では、DBもファイル、キャッシュもファイル。
下手に物理キャッシュを重ねると「ファイルの読み書き」が競合するリスクがある。
だからこそ、不要なWP_CACHEはトラブルの元になる。
爆速を狙うなら有効かも知れないけど、無難・安定を狙うなら、まずは「なし」で試した方が安心。
結論：人による
WP_CACHEは、特定のキャッシュプラグインという『相棒』がいる時だけ、それも一番目立つ場所に掲げるべき『合図の旗』である。
相棒がいないのに旗だけ振っているのは、ただの不審者。
つまり、必要かどうかは環境による！
コメント