hideishi
Forum Replies Created
-
Posts
-
無効にできていないようですね。
optimized_wp_settings.php が残っていたら手で削除してみてください。
また、wp-config.phpを以下のように修正してください。/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');本来ならば
/** Sets up WordPress vars and included files. */
if ( file_exists( ABSPATH . 'optimized_wp_settings.php' ) && ( ! defined( 'WP_CLI' ) || constant( 'WP_CLI' ) !== true ) ) {
require_once(ABSPATH . 'optimized_wp_settings.php');
} else {
require_once(ABSPATH . 'wp-settings.php');
}にあるように optimized_wp_settings.php か wp-settings.php のどちらかしか読み込まれないはずなのですが、
プラグインかテーマか何かが干渉しているのか、media.phpが二重に読み込まれているのがエラーの原因です。kuorda さん、こんにちは。
wp-settings.phpの最適化はかなりピーキーな最適化を行うオプションです。
プラグインやテーマによっては動作しない場合がありますので、
もしも表示に問題が出るならば無効にするようにしてください。PHP 8.0以降で採用されているJITコンパイラによる最適化をできるだけ受けられるように
optimized_wp_settings.phpを生成します。
ただ、このファイルの生成は管理画面で有効化したときにのみに行われるので、
WordPressのアップデートやプラグイン、テーマの更新があっても更新されず、
このファイルを削除して再生成する必要があります。
有効にしてからしばらく時間が空いている場合は、これが原因の可能性が高いです。なお、PHP8.0以前の場合はあまり改善効果は見込めません。
アップデートの際には注意事項がある場合があります。
リリース情報も確認ください。モジュールのアップデートについては、以下のコマンドで適用可能です。
# yum update --enablerepo=remi,remi-php56
php8を使用している場合は以下のコマンドで再起動してください。
# kusanagi php8
以下を見てください。
Q5. yum のアップデートを実行すると、エラーが出力されてアップデートできません。
A5-2. 以下のようなメッセージが出力された場合、パッケージ依存性の処理において remi パッケージを必要とすることがあります。
エラー表示の例
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigestkusanagi 9 init ができないです。
コマンドは以下、init自体はよくやるやつなので、問題はないはずなのですがそのinitに失敗しています。
おそらくはnginxのインストールが完了していないと思います。
kusanagi statusを見るとnginxがいないのではないでしょうか。kusanagi initをした際のログを貼っていただけますか？
nginxのインストールが失敗している場合、
kusanagi nginx --use nginx121 などでnginxだけ入れ直すと解決します。こんにちは
kusanagi-php7のアップデートでは --enablerepo=remi が必要です。
`
# yum update kusanagi-php7 --enablerepo=remi
# kusanagi php7
# yum update kusanagi
`こんにちは
kusanagi init に --ruby26 を指定したときに、phpが正しくインストールされないのが原因だと分かりました。
今は動作していると思いますが、一応以下のコマンドを実行しておいてください。
phpインストール時の行うはずの処理を実行します。kusanagi phpこんにちは。
モジュールが最新になっているか確認いただけますか？
dnf update -y特にkusanagi-openldapが最新になっていない可能性が高いです。
最新は以下です。dnf list --installed | grep kusanagi-openldap kusanagi-openldap.x86_64 2.5.7-1.el8 @kusanagiこんにちは。
PST ManagerからURLを指定してdelayから除外する方法はなさそうです。力技になってしまいますが、pst.config.yamlのファイルを直接編集する方法ならあります。
試しに1つ何か「/wp-content/cache/autoptimize/css/ほげほげ.css」を除外して、本番化してみてください。
そうすると、pst.config.yamlにそのURLがあるはずです。(shorten urlで _wt になっているかもしれません)
そこを「/wp-content/cache/autoptimize/css/.+.css」と正規表現に置き換えることで、『/wp-content/cache/autoptimize/css/ に含まれるファイル』という条件と実現できます。
ただし、手動で編集するとPST Managerからはマニュアルモードと見なされて、PST Managerから編集できなくなってしまうのでご注意を。ちなみに、Autoptimizeの機能はWEXALの機能と重複する部分が多くあります。
デザインが崩れるのもその影響と思います。
WEXALを使うならば、Autoptimizeをoffにするのがいいと思います。LEONさん
有料版では、初回起動時にkusanagi init相当のことが行われていますので、kusanagi initは不要です。
kusanagi_htmlに変えて別のプロファイルをプロビジョニングしたいのであれば、
LEONさんの書かれたとおり、「3. 初期設定画面でWordPressの起動設定」をやらずに
kusanagi init, kusanagi provision profile名, kusanagi target profile名を実行でよいと思います。「3. 初期設定画面でWordPressの起動設定」の手順でセットアップした後であっても、
kusanagi remove -y kusanagi_htmlでデフォルトのプロファイルを削除して、
kusanagi provision profile名、kusanagi target profile名で作成することもできます。KUSANAGI for AWS Premium Editionをデプロイした場合、
起動時に自動的に初期設定とプロファイルのセットアップが行われますので
kusanagi initとkusanagi provisionの操作は不要です。
(2つ目以降のプロファイルを作成する時はkusanagi provisionをします)もう一度kusanagi initしてしまうと、初回起動で作られた設定を上書きしてしまいます。
その結果、設定に不整合が発生してtargetの切り替えができなくなったのだと思います。一度EC2インスタンスを破棄して再度デプロイし直すのが早いです。
しっかりと見られていませんが、Themify.meの中にengagement delayしてはいけないスクリプトがあるのだと思います。
何度もリロードするとengagementが上がるので、スクリプトがdelayされなくなり、結果的に想定通りに動作したのでしょう。
WEXAL managerで高速化戦略モードをリソースヒントに切り替えて、Themify.meのスクリプトをengagement delayの適用から外してみてはどうでしょうか。epelのonigurumaが更新された影響ですね。
今すぐkusanagiのアップデートが必要な場合は、以下のコマンドで回避してみてください。
`yum update --exclude=oniguruma
他にonigurumaに依存してエラーが出るものがあったら、それもカンマ区切りでexcludeに追加してください。
