kusanagi– tag –

アドレス変更があるので、 Search-Replace-DB-master でデータベース内の置換をおこなう The script encountered an error while running an AJAX reques うんぬんのエラーがでる どうも、データが多すぎると、エラーになるようだ

[KUSANAGI] > [翻訳アクセラレーター] で、「高速化を有効にする」にチェックが入っており、「サイトに表示される翻訳された文章」の設定が、「翻訳を停止」となっているようでしたら、「キャッシュを使用」に変更してみてください。

サーバーの移転作業があり 今回、KUSANAGIをつかうことにした

[KUSANAGI] > [翻訳アクセラレーター] で、「高速化を有効にする」にチェックが入っており、「サイトに表示される翻訳された文章」の設定が、「翻訳を停止」となっているようでしたら、「キャッシュを使用」に変更してみてください。

アドレス変更があるので、 Search-Replace-DB-master でデータベース内の置換をおこなう The script encountered an error while running an AJAX reques うんぬんのエラーがでる どうも、データが多すぎると、エラーになるようだ

kusanagiのキャッシュ設定をしていて、fcacheとbcacheをつかうとどれくらい効果があるのかってことの記事がよくでてきた。そして、結論は、いづれも有効にすべしという結論だった。TTFBはinsightで見ることができるけど、アクセスが少ないと出てこない。また、insightの推奨をすすめていくと、テーマの使用に制限がでたりしてくる。でも表示は目視で違いが判らない程度。まぁ、いいっか。まずはテーマを存分につかってみようとおちついた。

DBの移行、wp-contentの移行、nginxと.htaccessを注意して移行してうまくいった。

kusanagi+nginxでwordpressをやっている。マルチサイトにする時は、apacheでは.htaccessに記述していたが、nginxではconfファイルに記載するようだ

たまに、wwwなしのアドレスと、ｗｗｗありのアドレスが違うことがある。大概はdns管理者がうちでない場合そうなる。このとき、kusanagiコマンドでsslをonにすると、letsencryptにwwwなしでも取得しようとするので失敗する

kusanagi9がバージョンアップして、管理画面にログインするにbasic認証がついてきた。このアップを境に混乱する。まず、これまで使っていたサイトは、basic認証なしでログインできる。あたらしいprovisionでサイトを追加した。ここでbasic認証がでてきた。ユーザー名パスワードは設定していない。この場合、htpasswdコマンドでログインできるユーザーを追加しなくてはいけないらしい。はじめて作る時は、-cオプションをつける

サイト移転でしばらく、アクセスログ、エラーログをリアルライム監視していたら、xmlrpc.phpにアクセスが頻発していることが分かった。調べると、そういった攻撃があるらしく、KUSANAGIでもxmlrpc.phpを停止する方法など多数あった。これを停止したら、IFTTTでおこなっている新規投稿通知がエラーーになる。xmlrpc.phpで新規投稿をチェックしているらしい。IFTTTからのソースを許可することにした。

同じドメインで、wordpressマルチサイト。kusanagiサーバーでキャッシュを設定している。サイトのうち、一つは公開、もう一つは、サイトを制限する。fcacheとbcacheを使っている。

サイト自体をパスワード保護する必要あったのですが、キャッシュを使うと、これが有効にならないのでした。cookieやwordpressのログインでkusanagiのキャッシュを有効にならないようになっているようだけど、ログインしていない状態でのパスワード保護が効かなくなるようでした。

wordpressのサイトはKUSANAGIで運用してます。wordpressに特化を売りにしてるので早いんだと思います。体感もはやい。それが最近サーバーからエラーログでてまして、

Centos7で動かしてるkusanagiのアップデートでエラーが出始めた。記憶に残っているのは2回目。前回は、アップデート後数時間するとサーバー停止していた。監視し、再起動させるスクリプトで対処したけど、今回はどうなんだ。