なぜエラーになってるのかわかりません。wordpressディレクトリに移動し、以下のコマンドを実施してください。正常ならば以下のパーミション、ユーザ、グループになっているはずです。

$ docker-compose exec httpd ls -l /home/kusanagi/wordpress
total 20
drwxr-x---    5 kusanagi www           4096 Apr  6 00:54 DocumentRoot
drwxr-xr-x    2 kusanagi kusanagi      4096 Aug  8  2019 settings
drwxr-xr-x    2 kusanagi kusanagi      4096 Apr  6 00:54 tools
drwxr-xr-x    4 kusanagi kusanagi      4096 Aug  8  2019 wp-config-sample
-r--r-----    1 kusanagi www           3561 Apr  6 00:54 wp-config.php

あとは以下コマンドで、使用しているDockerイメージを更新してみてください。
~/.kusanagi/update_version.sh

PHPの高速化に関しては、PHP8.1 + WordPress 5.9 移行を使用することで解決済みです。

Certbotの使用に関しては、どうしても証明書更新処理をcronなどで実行することになります。docker-compose内ではcronのような運用できないため、どうしてもホスト側での処理が必要になります。
本番環境で docker-compose で必要かという部分が不透明だった(開発時点では、docker-compose の存続状況が危ぶまれていた)ため、その処理の実装を行っていませんでした。要望があるならば、作成してみようと思います。

修正を完了しました。
kusanagi-docker コマンドを更新すると、wp-config.phpにWP_DEBUGが複数含まれる不具合は解消します。
kusanagi-ftpdのバージョンを更新し、正しく起動するように修正しました。

docker-compose.yml を直接修正し、kusanagi-ftpd のバージョンを 1.0.4-r0 に変更してください。

  ftp:
    container_name: wordpress_ftp
    image: primestrategy/kusanagi-ftpd:1.0.4-r0
    restart: always

• This reply was modified 3 years, 2 months ago by satoru.

宮崎と申します。
ご指摘ありがとうございます。

• –admin-passwd</br>ご指摘の通り、--admin-pass が正しいです。ドキュメントおよびヘルプを直します。
• --admin-email</br>ここかのタイミングで間違えて消してしまったようです。追加します。
• –-admin_user</br>ご指摘の通り、--admin-userが正しいです。変更を行います。
• —–END DH PARAMETERS—–‘ may not contains whitespace.</br>Macの改行コードの問題の用です。この現象はdocker-compose down/up しなければ発生しないはずです。こちらも修正します

ご指摘の内容は近いうちに修正したいと思います。何かあれば今後ともご指摘ください。
ありがとうございました。

KUSANAGIで使用できるページキャッシュには、NGINXの機能を使用するfcacheと、KUSANAGI Pluginで実現するbcache があります。
bcache は、WordPressで生成されるページが対象となるため、WordPressのwp-load.phpを読み込んでいないPHPページはキャッシュされません。bcacheをクリアする場合はKUSANAGIプラグイン画面からキャッシュクリアするか、kusanagi bcache clear を実行してください。
一方fcache では、WordPressのwp-load.phpを読み込んでいなくてもキャッシュされます。
fcache を任意のタイミングでクリアする場合は、kusanagi fcache clear を実行してください。

先程リリースした kusanagi-php7-7.0.16-2 でpgsqlおよびpdo_pgsql を追加しました。
もしこのモジュールで問題有りましたら、お知らせ下さい。

自分のConoHaの環境でも激遅になっていたので、調べてみました。
どうやら、ConoHaの1GBメモリのマシンではKUSANAGI標準設定だとswapが頻発していました。
以前はそんなことなかったのですが。

手っ取り早く使用メモリ量を減らすために、以下のようにMySQLの設定(/etc/my.cnf.d/server.cnf)を変更し、MySQLを再起動して下さい。

（変更前）
query_cache_size = 128M
innodb_buffer_pool_size = 384M
（変更後）
query_cache_size = 64M
innodb_buffer_pool_size = 128M

また、4GBメモリのマシンでも変わらないということは、別要因の可能性があります。
以下の情報があると特定がし易いです。

kusanagi status の内容
plugin のリスト(できれば)

HHVMを使用している場合、プラグインによっては遅くなります。
その場合は該当プラグインを停止するか、PHP7を使用することを検討して下さい。