katakura

Forum Replies Created

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • katakura
    Participant

      katsunakatamisa さん、こんにちは。

      原因は不明ですが、ご指摘のように .bashrc の

      sudo -u kusanagi -- /opt/kusanagi/php/bin/php /opt/kusanagi/bin/wp

      の記載が問題だと思われますので、以下のように書き換えてください。

      alias wp='sudo -u kusanagi -- /opt/kusanagi/php/bin/php /opt/kusanagi/bin/wp'

      この部分に関しては、サーバーやエディションごとに違いなどはありません。

      katakura
      Participant

        masahiroさん。

        ご回答ありがとうございます。

        ご回答を確認したところ、もしかしたらモジュールが最新化されていないかもしれません。
        お手数ですが、再度以下の手順に従ってモジュールの最新化を行ってみて下さい。

        KUSANAGI 9モジュール更新情報

        KUSANAGI 9 バージョンアップ情報 9.0.11-1.el8

        katakura
        Participant

          こんにちは、masahiroさん。

          回答ありがとうございます。

          PHPのバージョンが7.4であれば、wp-config.phpのftpsocketsを変える必要はないので、元に戻してください。

          ログを確認すると、ディレクトリの権限の問題ではないかと思われます。

          kusanagi provision コマンドを実行すると、以下のディレクトリの権限が 777 になります。

          ・DocumentRoot
          ・DocumentRoot/wp-content
          ・DocumentRoot/wp-content/languages
          ・DocumentRoot/wp-content/plugins
          ・DocumentRoot/wp-content/upgrade
          ・DocumentRoot/wp-content/uploads

          そのため、kusanagiのユーザーディレクトリにhttpd/wwwのユーザーが更新できるようになっています。
          以上のディレクトリの権限が 777 であるか確認してみてください。

          可能であれば、導入したプラグインのZion bulderが書き出すディレクトリの権限が、http/www ユーザーで行える権限になっているか、確認してみてください。

          katakura
          Participant

            こんにちは、masahiroさん。

            起きた現象を確認したいと思いますので、以下の情報を教えてください。
            ・PHPのバージョン
            ・KUSANAGIのバージョン
            ・利用しているWebサーバーエンジン(nginx or httpd)
            ・WordPressのバージョン
            ・プラグイン名とそのバージョン
            ・利用しているテンプレート名
            ・/home/kusanagi/(プロファイル名)/log/(利用しているWebサーバーエンジン)/配下の ssl_error.log ファイルと error.log ファイルの内容

            もし、PHPのバージョンが8であれば、ftpsocketに問題がありftpが動作しない現象が確認されています。
            pluginのインストールやテーマの更新などは、ftpを経由するのでこれが原因の可能性が高いです。
            PHPのバージョンが8であれば、以下の方法で解決できます。

            ・KUSANAGIのPHPのバージョンを7.4に落とす
             コマンドは kusanagi php --use php74 です。

            ・wp-config.phpを編集する
             wp-config.php内の以下の記載

            define('FS_METHOD', 'ftpsockets');

             を

            define('FS_METHOD', 'ftpext');

             か

            define('FS_METHOD', 'ssh2');

             に変更します。

            • This reply was modified 3 years, 5 months ago by katakura.
            katakura
            Participant

              こんにちは、tsyk70725さん。

              ご指摘の通り、AWSのKUSANAGI for AWS (WordPress)のインスタンスタイプが最新の状態に対応していませんでしたので、この度、対応のインスタンスタイプを修正いたしました。

              修正内容のは以下になります。

              • GPU instance と FPGA Instances と Machine Learning ASIC Instances は対応外とする。
              • CPU が arm 対応のインスタンスタイプは対応外とする。
              • 上記以外は全て対応とする。

              r5.2xlargeにも対応しましたので、確認してみてください。

              • This reply was modified 3 years, 7 months ago by katakura.
              • This reply was modified 3 years, 7 months ago by katakura.
              in reply to: KUSANAGIとfcacheとCookie #736
              katakura
              Participant

                mr-shiodomeさん。
                上記内容に対して、補足します。

                fcache が適用されないケースは、以下の2通りとなります。

                1. HTTPレスポンスのヘッダに Set-Cookie フィールドが含まれている場合

                http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_valid
                (こちらは fastcgi_cache ですが proxy_cache とほぼ同じ仕組みです)

                > If the header includes the “Set-Cookie” field, such a response will not be cached.

                fastcgi_ignore_headers と fastcgi_hide_headers ディレクティブにより、Set-Cookie を無視させることもできますが、参考URLにもありますようにサーバからの cookie 発行ができなくなり、 WordPress の機能が損なわれますので実質併用できません。

                http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_ignore_headers
                http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_hide_header

                2. KUSANAGI でキャッシュ対象外としている場合

                有効なキャッシュがある場合でも、fcache の対象外となるケースに以下が挙げられます。

                ・リクエストメソッドが POST である
                ・クエリストリングがある
                ・HTTPリクエストに、特定の cookie が含まれる
                コメント、ログイン、パスワード保護
                ・特定のURLへのアクセス
                wp-admin、xmlrpc.php、wp-.*.php、index.php、サイトマップXML

                ※ /etc/nginx/conf.d 内の {プロファイル}_http.conf、{プロファイル}_ssl.conf 内の $do_not_cache が 1 になるケースが無効化されるケースです。

                上記を踏まえ、 Google Analytics と WooCommerce を利用した場合の fcache の影響は以下の通りとなります。

                Google Analytics:
                Google Analytics の cookie は javascript から発行されたものであり HTTP レスポンスでなされたものではないため、 Google Analytics の cookie は fcache に影響しません。
                そのため、 fcache と Google Analytics の併用は可能です。

                WooCommerce:
                WooCommerce のログインは WordPress のログイン機能を用いているため、ログイン時に fcache が適用されないケースにあてはまるので、ログイン後は fcache の適用外となります。
                なお、ログインしていない時は fcache が適用されるため、一定のキャッシュ効果は見込めます。
                そのため、 fcache と WooCommerce の併用は可能です。

                繰り返しになりますが、結果として特別なカスタマイズなどを行わない限り、 Google Analytics と WooCommerce を利用してもデフォルトの設定のまま fcache を利用することは可能です。

                in reply to: KUSANAGIとfcacheとCookie #735
                katakura
                Participant

                  こんにちは、mr-shiodomeさん。

                  当方の環境では最低限、Google AnalyticsとWooCommerceがCookieを用いています。同様の環境で、fcacheを活用する良い方法をご存知の方がいたら、ぜひアイディアを教えてください。

                  KUSANAGIのfcacheは、cookieにWordpressにログインしている値が設定されている場合は無効なります。

                  よって、WooCommerceを利用しているときはWordpressにログインしているユーザになりますのでfcacheは無効になり、Wordpressにログインをしないでアクセスをするユーザ(=Google Analytics)はfcacheが有効になります。

                  katakura
                  Participant

                    こんにちは、hodegimyaさん。

                    ちなみに、ご案内頂いた情報は公式にドキュメント化されているのでしょうか?

                    KUSANAGI から他の環境へのマイグレーション手順のドキュメント化は行っていません。

                    また、非公式な情報ですが、以下の個人ブログではKUSANAGI関連ファイルとして
                    wp-content/advanced-cache.php
                    も削除しているようです。

                    advanced-cache.phpの削除是非について情報をお持ちでしたら
                    ご指導お願い致します。

                    KUSANAGI ではKUSANAGI専用プラグインのページキャッシュの設定にありますように、advanced-cache.phpの生成を行う場合があります。
                    その場合は削除してください。

                    ただ、他のプラグインで生成している場合もありますので、確認した上で削除してください。

                    katakura
                    Participant

                      こんにちは、hodegimyaさん。

                      WordPress自体は存続させ、Kusanagi関連のファイルやデータベースだけを削除するにはどうすればいいでしょうか?

                      KUSANAGI 関連のプラグインについては、wp-content/mu-plugins 内の以下を削除してください。

                      • kusanagi-core ディレクトリ
                      • kusanagi-wp-configure.php
                      • wp-kusanagi.php

                      KUSANAGI 関連のデータベースは、以下4テーブルを削除してください。

                      • wp_site_cache
                      • wp_sitemanager_device
                      • wp_sitemanager_device_group
                      • wp_sitemanager_device_relation

                      加えて、KUSANAGI 関連のデータベースのデータとして、wp_options 内の option_name が以下のレコードも削除してください。

                      • kusanagi-translate-accelerator-settings
                      • site_manager_cache_installed
                      • sitemanager_device_rules
                      • This reply was modified 3 years, 9 months ago by katakura.
                    Viewing 9 posts - 1 through 9 (of 9 total)