hideishi
Forum Replies Created
-
Posts
-
こんにちは
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に追加してください。上の
/usr/local/certbot/certbot-auto delete –cert-name 削除したホスト名
は
/usr/local/certbot/certbot-auto delete 「-」「-」cert-name 削除したホスト名
です。(ハイフン2つ)以下のコマンドを実行することで、letsencryptが管理している証明書を表示できます。
/usr/local/certbot/certbot-auto certificates
おそらく、ここに削除したホスト名が残っているということですね。以下のコマンドでletsencryptの管理から削除します。
/usr/local/certbot/certbot-auto delete --cert-name 削除したホスト名再度以下のコマンドを実行して、letsencryptの管理対象から消えたか確認してください。
/usr/local/certbot/certbot-auto certificatestype virtualenvの結果がないので具体的に書けませんが、
/usr/bin/virtualenvの検索順番が先に来るようにPATHを設定します。
以下を参考にしてみてください。
https://qiita.com/ozipi/items/29d7ae0b21e476dd7b8eenvコマンドで一時的に実行することもできます。
例)
env PATH=/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin kusanagi update certエラーメッセージを見るにvirtualenvがOS標準のものから入れ変わってしまっているんじゃないでしょうか。
type virtualenv
→ /usr/bin/virtualenvですか？
もしそうであれば、PATHを直しましょう。virtualenv --version
yum info virtualenv
→ この2つのバージョンは一致しますか？
もし一致しなければ、yum reinstall python-virtualenv で入れ直しましょう。kusanagi-php7が更新されましたね。
ドキュメント通り
yum –enablerepo=remi,remi-php56 update -y
でいけると思います。
