WordPressのBackWPupプラグインでまたエラーが出る件、解決した。
バックアップ先をDropboxにしていたけど、認証を削除して再度認証したら正常にバックアップできるようになった。
以上、解決。
追記
Dropboxにバックアップができないと思っていたら、バックアップ先のフォルダがBackWPupでなくInpsydeBackWPupというフォルダに変わっていた。
タグ: WordPress
WordPressのBackWPupプラグインでまたエラーが出る
WordPressのBackWPupプラグインからエラーの通知がやってきた。
「ステップを中止: 回数が多すぎます。」というエラーメッセージでGoogleさんに聞くと、自分のサイトが出てきた。
同じ障害が出ていたのを忘れていた。たまにある話し。
そのときはPHPのバージョンを上げれば対応したようだけど、現在はさくらインターネットのVPSからただのレンタルサーバーにWordpressのサイトを移している。さくらインターネットのコントロールパネルを見るとPHPのバージョンは7．2だった。これを7．3にバージョンアップする。
結果はエラーは変わらない。他に原因があるようだ。
追記
続きはこちら
WordPressのGutenbergのバグ？ #wordpress
WWordpressの新しいエディタのGutenbergですが、みんな使っているのかな？
ｋ気に入って使ってきたけど、障害というかバグが増えたような気がする。今まで我慢できる位のバグがあったけど。
ｔテキストをコピー＆ペーストをすると、改行されて前後にスペースが入るというのとか、ブロックを書き始めようとしても入力できないとか致命的なバグがあるけど。
い今一番おかしいのは、ブロックを入力し始めると、一番最初のキーが残ってしまうというバグがひど過ぎる。
ｔちなみにこの記事のテキストがおかしいと思うかもしれないけど、こんな感じで最初のキーが二重で入力されてしまう。
ｍもしかしたら、これは私のところのWordpressが原因とか、ATOKで入力しているのがダメだからとか、特定の条件で起こるGutenbergのバグかもしれない。Googleさんに聞いてみても、こんな障害の報告が上がっていないから、私のところでしか発生しない障害かもしれない。
ｔ試しにATOKの日本語入力ではなくて英文のアルファベットを直接入力してみると、
korehatesutodesu.
ｔって正しく入力できるようだから、日本語入力の問題だろうかと疑う。ATOKではなくて、マイクロソフトのIMEで入力しようとしたけど、MS-IMEをアンインストールしてしまったので試すことができない。
げ原因を突き止めるのは山々だけど、ATOKが悪いとなったら、日本語変換が辛いと思うから、Gutenbergをやめて元のクラッシクエディタに戻そうかと思う。
ｓせっかくGutenbergは気に入って使っていたのに、今回のバグは残念である。
どどこにこのGutenbergのバグを報告してものか・・・。
ししかしながら、英文では障害が発生せずに日本語入力でバグが出るっていうのは、開発者には説明しづらいな。
ｋこの記事を読んでみると、とっても読みにくいな。Macでも同じ現象だからOSは関係なさそう。
GGoogle日本語入力でもバグ発生。
kことえりでも障害発生。
kこのサイトだけかもしれないな。
追記
結局のところ、Gutenbergを使うのをやめてクラッシックエディターにしています。あまりにもGutenbergのバグが多くなってしまっています。このままGutenbergを使い続けることを諦めました。
同じようなバグが出てないかGithubのissue調べたら、同じようなバグが報告されてあった。
https://github.com/WordPress/gutenberg/issues/11813
しかし、既に対応済みでClosedになっていた。本当に直っているのかな？ その後に動かないとか報告されていないので、やはり自分のところだけ？
会社のホームページのサーバー移行を行う
会社のホームページを常時SSL化に伴い、サーバーの移行のついでにWordPressからbaserCMSに乗り換えてしまう。ページ数も少ないし手でコピペしてしまう。それにしてもアクセスの少ないサイトである。
周りにはSSLでアクセスさせたほうがいいよと言いながら、自分のところではやっていなかったという、ようやくやってみる。ほぼ会社のホームページは更新してないけど、ホームページがあったでセールス電話がかかってくるくらいなもの。でも、ホームページがなくなると、周りから会社が潰れたと思われるので、簡単なものでもいいから作っておく。
さくらインターネットのVPSにApacheを立てて名前ベースのバーチャルホストで動かしていたが、これを同じくさくらインターネットのレンタルサーバーに移してしまう。ドメインを設定して、/etc/hostsにIPアドレスを追加して、ドメイン名でさくらインターネットのレンタルサーバーにアクセスできるようにしておく。あとは、MySQLの設定やbaserCMSのインストールをごにょごにょやって、ページのコピペ、適当にテーマを変更、DNSを変更、SSLの設定して完了。
と思いきや、以下のさくらインターネットのサポートサイトに書いてあるように.htaccessを追加すると、HTTPにアクセスしたときリダイレクトループが発生する。SさくらインターネットのレンタルサーバーではSNI SSLとか普通のSSLではないようなので、普通にrewriteルールを書いたらダメだそうな。
ブラウザのキャッシュをクリアしたり、別のテーマにしたり、テーマの初期化データを再投入とか、.htaccessを元に戻したりしても、今度は元に戻らなくなった。なにかやってしもうた、感が大きい。
しかしながら、テーマの初期化データを再投入をやると、今まで作っていたページが来てしまったのは辛かった。これをやらないとテーマを変えたらブログ一覧が取得できないとか、原因不明な動きをする。こちらは今回ページ作成で追加されたデータがあるテーブルを、SQLで強引に入れ替えてしまうというこ手段で回避した。テーマの管理に初期データを出力する機能で一旦データを作成して、こちらを初期データとして再投入したけど、元に戻らなくなったのでやめた。
リダイレクトルールの原因は、私のbaserCMSのシステム設定の勘違いだった。WebサイトURLがSSLとなっていないものとSSLと明示されているURLの2つ設定しないといけないが、SSLなっていない方にHTTPを設定してしまっていた。こちらもHTTPSのURLを設定しないといけなかった。なんで2つURLを設定しないといけないかはソースを見てみないとわからない。
その下にSSLのチェックがあるけど、こちらは管理者画面でSSLでアクセスするかの設定だった。このチェックでSSLのURLを自動的にアクセスしてくれるのかと思い込んでいたの大きな間違いだった。
「管理者画面SSL設定」で「SSL通信を利用する」にチェックを入れると、HTTPSで管理者画面にログインできなくなったので外しておいた。これは原因不明。
以上、なんだかんだで当初の目標通り無事にSSL化ができた。しかし、HTTPからのリダイレクトに若干問題あるけど時間があったら対応する。
追記（2018年9月5日）
初期データを投入したからいろいろなところで元に戻ってしまっている。見つけたら直している最中。タイトルが初期データだったのはまずかったな。
さくらインターネットのメールサーバーを移行する
さくらインターネットのメールボックスを設定していると、レンタルサーバーに同じドメインを設定できないようなので、メールボックスをやめてレンタルサーバーにメールを移行する。面倒な仕様だと文句を言いながら作業を始める。
さくらインターネットにDNSゾーン削除依頼をする
メールアドレスを新しくレンタルサーバー側に設定してからメールボックスのドメインを削除する。これでレンタルサーバーにドメインを新規登録できるので、新登録してからお名前.comにあるDNSのMXレコードをレンタルサーバーに設定する。ドメインの新規登録をするときに、確認画面で送信ボタンを押し忘れて、ずっとメールが届かないと悩んでしたのは内緒の話し・・・。
以上の作業で、10～20分ほどでメールサーバーの移行は完了する。テストメールを送ってメールが受信できるか確認しておく。
現在WordPressで会社のサイトを作っているけど、全くプログの更新とかしないサイトだし、次回はbaserCMSでサイトを作ってみようと思う。WordPressからbaserCMSのサイトの移行はどうせできないと思うので、コピペでページを作っていく。サイトデザインをどうするかとかあるけど、最初はbaserCMSで最初に用意しているテーマにしておこうかと思う。
これで当初も目的のLet’s EncryptのSSL証明書を使ったSSL化の第一歩となる。会社のサイトだから、本来ならば実在証明型のSSL証明書にしたほうがいいのだけど、一日10アクセスくらいしかないサイトだから、ドメイン認証型の無料SSL証明書にしておく。
追記（2018年9月3日）
迷惑メールも広告メールも受信できるようになったから、無事にメールサーバーの移行ができたんじゃないかな。
追記2（2018年9月3日）
さくらインターネットのレンタルサーバーのメールアドレス設定で、メールを「転送専用にする」にしていたらfetchmailができなかった。「メールボックスに残す」にしないといけない。 考えてみれば 当たり前だけどな。
Gutenbergが動き出した
今までは保存できないといる障害がありました。一番怪しいのがテーマだと思ってWordPress謹製のテーマに変えてみましたけど、結局同じでした。
ふと設定項目を見てみると、URLがhttp:///www.5cho-me.com/のままでした。先日SSL化したので、https://www.5cho-me.com/にしないといけないのでした。きちんとHTTPSに設定したら、Gutenbergが正常に動き出しました。
そう言えば、プレビューもできなかったし、管理者用のツールバーが表示できないという問題もありました。これらすべてHTTPSのURLを設定していなかったのが原因のようです。
エディタをGutenbergに変えてみたら
ここのWordPressのエディタをGutenbergに変えてみたら、「更新に失敗しました」とかエラーが出て記事が保存できなかった。
別のサイトで試してみるとGutenbergで書いて正常に保存できているので、ここのサイトの問題でしょうな。テーマとかサーバー設定とか、何かが問題なのでしょう。
エラー報告がされているGitHubを覗いてみたら、issuesが溢れていた。Gutenberg本体が安定するか障害の情報がまとまるかまで、Gutenbergは様子見。クラックエディタを有効にしておく。
「Gutenbergが動き出した」へつづく
BackWPupプラグインでエラーが出るので
BackWPupプラグインでエラーの通知が来た。BackWPupはWordPressの自動バックアッププラグイ。実はエラーを出ていても、しばらく放っておいたけど。
エラーが出ていると何か気持ち悪いので対応する。BackWPupの管理画面に入ると、「mysqliがどうしたこうしたと」警告が出ていた。これを手がかりに対応する。
BackWPupのジョブを直接実行すると
「エラー: ステップを中止: 回数が多すぎます」
とエラーメッセージが表示する。こちらを手がかりにしたほうが簡単に対応方法が見つかった。
要はPHPのバージョンが古くてmysqliのPHP拡張モジュールを対応していないからMySQLに接続しようとするとタイムアウトになっているとのことだった（だいぶ意訳）。
このWordPressのサイトはさくらインターネットのレンタルサーバーを使っているけど、最初にPHP7を入れたはずだけどと思ってphp -vを打ってみると5.6だった。つまりPHPのバージョンが古いのが原因だった。
さくらインターネットのサーバーコントロールでPHPのバージョンを7.2に切り替えてみる。実はこれは危険。思いつきで切り替えてはダメ。案の定WordPressのサイトにアクセスすると、画面が真っ白になってしまう。
「ああ、やってもうた・・・」と思ったけど気を取り直して、さくらインターネットのサーバーコントロールからPHPのバージョンを5.6に戻してみる。これは無事にアクセスできて元通り。この辺りはレンタルサーバーの気軽で簡単なところ。もし、専用サーバーだったら、PHPのバージョンを元に戻すは大変だろうな。
おそらくプラグインが悪さしているのだろうと思って、めぼしいプラグインを無効にしておく。PHPを7.2に切り替えると、今度は無事にアクセスできる。
一つづつプラグインを有効にしてみて、PHP7.2に対応していないプラグインを探してみる。インストールしていて対応していていないプラグインは、
- Google+Blog
- spam-byebye
の2つだった。
spam-byebyeは、もう古いしWordPressのJetPackでスパムコメントの対応はできていそうなのでもう必要ない。
痛いのはGoogle+Blogである。こいつはいくらかお金を払ってインストールしたもの。Google+（みなさん使っていないと思うが、実は自分が利用している唯一のSNS）から記事を自動的に取得して投稿してくれる連携プラグインである。このままではGoogle+Blogプラグインを有効にするとサイトにアクセスできなくなるので、したかないけど無効にしておく。Google+Blogプラグインのサポートサイトを見てみると、Error 502になるので、既にサポート終了になってしまっている。WordPressからG+へは自動投稿できているからよしとする。
以上でPHP7.2の対応完了。本件の始まりだったBackWPupプラグインのエラーはなくていた。ジョブを直接実行してみると正常にバックアップができていた。
「完全に保護されていません」と警告された
ずっと無償で面倒を見ているサイトがあって、そろそろSSLに対応してあげないといけないと思い立って実施する。もちろん無償。
さくらインターネットのレンタルサーバー上でWordPressを使って動かしているので設定は簡単。あっという間に設定は完了。しかしながら
「このサイトへの接続は完全には保護されていません」
となる。テーマに埋め込んだSNSのリンクがHTTPになっていたので、面倒だからリンクを削除する。
Chromeでアクセスすると、相変わらず
「このサイトへの接続は完全には保護されていません」
となる。EdgeやFirefoxでは問題なく暗号化されているなっている。
[amazon_link asins=’4908686009,B06XJ88H1G,B06W5QPJCF’ template=’ProductCarousel’ store=’5cho-me-22′ marketplace=’JP’ link_id=’91fa5283-7f51-11e8-baca-5f396bb02c5e’]
ChromeでF12を押して開発者ツールを動かすと、コンソールでHTTPでアクセスしているところがある。よく見てみるとCSSの背景画像の指定だった。相対アドレスで画像ファイルをしているのでおかしいと思って、もっとよく見ているとCSSファイルをキャッシュしていた。そういえば、CSSとかJavaScriptのファイルをキャッシュするWordPressのプラグインを入れていた。プラグインの機能でキャッシュを削除する。
今度はChromeで無事に
「この接続は保護されています。」
となった。これで作業完了。
WordPressのメディアライブラリで新規追加するとHTTP エラー
ここのWordPressのサイトでメディアライブラリから画像ファイルを新規追加するとHTTP エラーが出てしまいました。心当たりは全くありません。
さて、Googleさんに聞くといろいろでてきます。
WordPress の「HTTPエラー。」でメディアアップロードができない、
「HTTPエラー」WordPressでメディアをアップロードできない現象
などなど。
Webサーバーのエラーログを見ましたが、エラーは出ていませんでした。何かfunction.phpが怪しいとのことでしたが、WordPressのテーマのままでした。
とりあえず、別のテーマにしてみると、今度はうまくファイルをアップロードできるようになりました。テーマを元に戻してみると、これも成功しました。
以上、原因不明で解決できてしまいました。結局テーマを一度別のテーマにしたら解決でした。