5丁目通信(仮称)

とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。

タグ: プラグイン

  • WordPressでウィジェットの編集をしようとしたら「ブロックはエラーの影響を受けており、正しく機能しない可能性があります。」が出た話し

    本サイトはWordPressで運用してますが、フッタの表示を変更しようとウィジェットの編集をしようとしたら、赤いエラーメッセージがたくさん出てきました。こんな表示です。

    何でも、新しいWordPressのブロックエディタであるGutenbergに対応していないテーマだと、こんなエラーが出るそうな。

    しかし、これはおかしい。

    現在のテーマは、Wordpress純正のTwenty Twenty-Oneテーマの子テーマを使っています。念のために、素のTwenty Twenty-Oneテーマに切り替えても同じエラーが表示されてしまいます。

    もう仕方ないので、Gutenbergに対応していないテーマがこのエラーが出ないように、指示通りにClassic Widgetsプラグインをインストールしたら解決しました。これでウィジェットの編集ができるようになりました。

    Twenty Twenty-Oneテーマなのにどうしてだろう? Twenty Twenty-Oneテーマを使っている他のサイトでは、Classic Widgetsプラグインを使わなくてもエラーメッセージなしにウィジェットの編集ができます。

    何が違うのかな? よくWordPressはわからない。

    追記(2022年4月18日)

    現在はウィジェットを使うのをやめてClassic Widgetsプラグインは削除しました。なるべくプラグインを使わないようにしたほうがベター。

  • あなたのサイトは、本当にWordPressで作る必要がありますか? という話し

    WordPressでの仕事が増えてきました。最近ですとWordpressをサイト構築のプラットフォームで利用するという考えが一般的になりましたが、現状はこんな感じです。

    1. ユーザーがサイトの更新をしたくない。
    2. 固定ページが中心でブログページがない。
    3. コンテンツの作成にグーテンベルクのブロックエディタではなくクラッシックエディタを使いたがる。
    4. 記事本文にHTMLタグをそのまま書いている。

    1.は、せっかくWordressで簡単にページの更新ができるのに、結局は制作した会社におまかせするなんてもったいない。だけど、更新を制作会社に破格な安さで丸投げするなん勘弁してください。

    2.は目的のサイトがブログサイトではなかったら仕方ないかもしれません。でも、日頃コンテンツを追加していった方がいろいろと幸せになるかもしれません。

    3.は、最新のブロックエディタは嫌われているようですが、グーテンベルクは使ってみると便利なものです。ブロックエディタがお望みのレイアウトにハマれば、サイトの更新が楽ちんになるはずです。

    4.は致命的です。もっとレイアウトとかデザインを凝りたいとユーザーに言われて、divタグなどでレイアウトの設定をしてしまって、コンテンツの中身がどんどん複雑になってしまいます。そうすると1.のユーザーが更新できなくなるという負のスパイラルに嵌まっていきます。固定ページの中身を見てみたら、divタグがとんでもなくネストしていたら私だったら怒りを覚えます。

    WordPressを使う理由としては、出来合いのテーマを使って簡単に最初から綺麗なサイトを作れるとか、希望の機能があるブラグインが使えるとか、ページの有効無効などの管理が楽であることでしょうか。そんな凝ったサイトではないとか、どうせユーザーが更新やメンテナンスをしないのであれば、素のHTMLで書いた方が幸せになるかと思ったりします。Wordpressやプラグインをアタックされて大変な目に遭うなんてなくなります。

    そろそろ本当にWordpressで作る必要があるのか、考えたほうがいいかもしれません。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

  • WordPressのGoogle Site Kitで”The response is not a valid JSON response.”が出ても諦めずにF5を押せという話し

    WordPressのプラグインにGoogle Site Kitというプラグインがあります。このプラグインのダッシュボードや、ページの詳細に初回でアクセスすると

    • Data error in Search Console
    • Data error in アナリティクス

    で、

    The response is not a valid JSON response.

    でエラーが出ることが頻繁にあります。画面はこんな感じです。

    大抵はこれであきらめますが、懲りずに何回かF5でブラウザの再読み込みをすると、正しく表示してくれることがあります。

    ここからGoogle AdSenseについての余計な話しです。

    ただ、いくらGoogle様謹製のプラグインであっても信用してはいけません。AdSenseの通貨単位が円であるはずであるのところドルであったり、微妙におかしなところがあります。

    そもそも、AdSenseのデータがこの数ヶ月増えないのは信じていいのでしょうか? たまに数円増えても数日後に戻るとか、おかしな動きをしています。どれだけ不正な広告アクセスとして判定しているのでしょうか? 所詮、AdSenseの収益なんてGoogle様の胸先三寸なのです。おっと、Google様を批判してしまった・・・。

    これではAdSenseで収入を得るなんて難しいかもしれません。本サイトでは、まったく広告の収入はあてにしてません。そもそも、今のAdSenseの広告表示内容では、本当にクリックしてくれるか疑問の品質が低い広告が点在しているのが気になります。クリックせずに単に表示しているだけの広告では、広告主にはメリットがありそうですが、広告を配置させているサイト主にはメリットはありません。もっとサイト主の収入となるクリックしてくれそうな広告を配信していただけるような広告の品質を望みます。

    追記(2022年9月2日)

    こちらのGoogle Site Kitのレスポンスエラーになるのは、さくらインターネットのサーバーの問題でした。サーバーがアップデートされたようで、現在はF5を幼くても表示してくれます。ただし、非常に表示してくるのが遅いですけど。

  • WordPressのバックアッププラグインBackWPupでwp-contentフォルダがバックアップできないことを対処した話し

    WordPressのサイトのバックアップをBackWPupプラグインで行っています。

    たまたまお客さんのサイトバックアップファイルを覗いてみたら、どういう訳かwp-contentフォルダがバックアップされていませんでした。

    BackWPupプラグインのファイル設定を見てましたが、特にwp-contentが除外されているということもありません。一度BackWPupプラグインを無効にして再度有効にしても現象は変わりません。次にBackWPupプラグインを一旦削除して再度インストールしてもかわりません。新しくジョブを作り直しても変わりません。

    これで手詰まりかと思って、今度は正常にwp-contentフォルダをバックアップとれている本サイトと設定を比べてみました。最大スクリプト実行時間を0にしましたが、これもだめで現象は変わりません。

    次の違いは、バックアップのアーカイブ形式がTar GZipになっていました。これをZipにしたところ、今度はwp-contentフォルダを含めてバックアップができるようになりました。

    でも、バックアップファイルを生成前にwp-contentフォルダを含めるかどうかで、そのあとアーカイブしますので、アーカイブ形式は関係ないかと思っていました。これは不思議な現象です。

    とりあえず、無事にバックアップができるようになったのでよしとしましょう。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2022年9月21日)

    最近、またBackWPupでエラーが出ています。

    ログを調べてみると、アーカイブまではうまく行っているのですが、DropBoxにアップデートをしているときに、エラーが何回が起こして停まっているようです。

    こういうときには、DropBoxの認証を削除して、再度認証しておきます。

    これで無事にバックアップができるようになりました。たまにDropBoxの認証を再実行してあげないといけないようです。

  • DreamweaverをいつでもやめてもいいようにVisual Studio Codeの環境を作ってみた話し。でも、まだDreamweaverはやめないけどね。

    いつでもDreamweaverをやめてもいいように、その替わりにVisual Studio Codeにできるように環境を作ってみた。でもまだDreamweaverは便利だからやめないけどね。

    現在作業しているサイト更新の案件では、大まかには以下のような流れで利用している。

    1. Redmineでチケットを発行する。
    2. git-flowのブランチで作業開始する。
    3. Dreamweaverで作業する。
    4. テストサイトにアップする。
    5. テストサイトでお客さんに確認してもらう。
    6. git-flowのブランチで作業完了する。
    7. 本番サイトにアップする。

    Redmineは普通にブラウザで行って本番アップも今まで通り、あとはVS Codeで完結したい。今まではDreamweaverのテンプレート機能に依存している作業があったが、それがなくなったのでDreamweaverを使わなくても作業ができるようになった。次の通りにVisual Studioの拡張機能を使ってDreamweaverでの作業の替わりの設定をしてみる。

    Gitは、コマンドを使わずに今までSourceTreeで行っていた。GItはあらかじめVS Codeで用意されているが、もっと便利にGitを使うためにも、以下の拡張機能をインストールしておく。

    ただし、いまメンテナンスをしているサイトのHTMLファイルは、文字コードがUTF-8ではなくシフトJISなのでGitで差分を見ると文字化けしてしまう。これは昔からやっているサイトなのでどうしようもない。UTF-8にしようと提案したけど、あえなく却下された。だってページがとても多いからコストがかかるからだってさ。

    git-flowも簡単に行うために次の拡張機能を利用する。同じ名前の拡張機能がいくつかあるので注意。

    結局はSource Treeのほうがわかりやすくて便利なことが確かである。Gitの作業はどれでやってもやることは同じなのであまり気にしないようにする。本当に難しい作業は、Gitのコマンドを叩かなければいけない。

    DreamweaverでもリアルタイムにプレビューしながらHTMLファイルを作成していくので、次の拡張機能をインストールしておく。

    HTMLファイルのプレビューの拡張機能はたくさんあるけど、こちらがよさそうだった。ただし、作業しているサイトのHTMLファイルは、共通のヘッダやメニュー、フッダにSSIを使っているので、SSIをサポートされていないので完璧にはプレビューできない。何か他によいプレビューの拡張機能があったら紹介して欲しい。でも、いまどきSSIで作っているという、とても古いサイトなのである。

    テストサイトのアップは、次のSFTPの拡張機能を使っている。

    Dreamweaverに合わせてアップロードのショートカットキーは、Ctrl+Shift+uに設定しておく。ショートカットキーを揃えるのは、マクロキーボードを使っているからである。このショートカットをキー一つに登録できるマクロキーボードは便利である。

    テストサイトにアップした後、すぐにテストサイトをプレビューできるように以下の拡張機能をインストールしておく。テストサイトのページのURLをお客さんに伝える必要あるので、すぐにテストサイトにアクセスできてアドレスをコピペできることが重要である。この拡張機能が見つからなかったら、自分で作るしかないかと思っていた。Visual Studio Codeの拡張機能はたくさんあるので目的のものはあるもんだなと思った。

    こちらもブラウザプレビューのショートカットキーとしてDreamweaverにあわせてF12にしておく。設定ファイルを次のようにすると、HTMLファイルの編集ウィンドウでF12を押せばChromeが起動して、テストサーバーにアップされたページが表示される。HTML Previewでできなかった細かい確認はここで行う。Chromeのアドレスに表示されたテストページのURLをお客さんに伝えて確認してもらう。

    {
      "open-php-html-js-in-browser.selectedBrowser": "Chrome",
      "open-php-html-js-in-browser.urlToOpen": "custom",
      "open-php-html-js-in-browser.documentRootFolder": "C:/<ドキュメントルート>",
      "open-php-html-js-in-browser.customUrlToOpen": "https://<テストサイトのドメイン>/${relativeDirnameDocumentRoot}/${fileBasename}"
    }

    以上で、Dreamweaverの代替でVS Codeで使うようにする設定は完了。

    しかし、Dreamweaverは、まだまだHTMLファイルの作成にとても楽だから、まだまだ使っていくつもりである。リンクのアドレスとか、テーブルの処理とか、最終更新日の自動記入とか、まだまだ細かいHTMLは断然Dreamweaverのほうが使い勝手がよい。この辺りのHTMLエディタとしては、Visual Studio Codeは頑張っても勝てない。

    アドビ税とかアンチでDreamweaverを嫌っている尖った人たちが何だが多いけど、便利なものはお金を支払っても使っていこうと思う。ちなみに、Dreamweaverは単体で契約している。あとPhotoShopも単体で契約している。

    追記(2021年5月11日)

    DreamweaverとPhotoshopを単体で契約していたけど、アマゾンでAdobe Creative Cloud コンプリートが安かったので買ってしまった。単体と200円も毎月違わなかったから即買いだった。

    追記(2021年6月3日)

    SFTPでファイルのアップロードがNo such fileのエラーでできなくなっていた。対処方法を調べてみると、行き当たったのはこちらのサイト。

    このサイトの記事通りにsftp.jsに一行追加したらアップロードできるようになった。

  • 致命的なエラーになるので、とりあえずWordPressのAMPプラグインを無効にしておいた話し

    Google Search Consoleのエラーをチェックしていたら、WordpressのAMPプラグインを有効にしてサイトにアクセスしたときに ?amp=1 を付けると、次のような致命的なエラーとなっていた。

    Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0

    この件をGoogleさんに聞いても解決策が見つからないので、とりあえずAMPプラグインを無効にしておいた。AMP対応は一旦停止となります。

    今までAMPプラグインで対応できていたけど、Wordpress本体かプラグインのバージョンアップで不具合が出たのかしらね。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

  • さくらインターネットのサーバーかWordPressが原因かわからないけど、再利用ブロックが原因不明でGutenbergで呼び出しができなくなってしまっている話し

    以前でも再利用ブロックがGutenbergが呼び出しができなくなってしまったと書きましたが、再度この障害が出ています。自分のところだけの問題でしょうか? それとも、調子に乗って、たくさん再利用ブロックを作成してのが悪いのでしょうか?

    プラグインをすべて無効にしても、テーマを純粋のTwentyTwenty-Oneに戻してみても、何をやっても変わりありません。最近、Gutengergプラグインが何回か短期間に繰り返しアップデートになっていたので、それが原因かもしれません。

    あと怪しいのは、現在運用しているさくらインターネットのレンタルサーバーです。こちらは別のサーバーで、このWordpressのブログサイトを動かしてみて切り分けてみる必要があるかもしれません。他に500のサーバーエラーが出やすくなっているとか、たまに記事を公開すると

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    で失敗するとか、さくらインターネットのサーバーがおかしな挙動をしているので、さくらインターネットのサーバーから別のサーバーに移行しなければいけないかもです。さくらインターネットのサーバーでWordpressサイトを動かすと遅いという噂(本当かな?)がありますので、どこが原因なのかは、まだ未確定です。

    いずれにしても、さくらインターネッのサーバーから別のサーバーに移行するするのは大変で、できるならやりたくないのです。メールアドレスをレンタルサーバーに設定してしまっていますので、メール専用のサーバーに設定しておけばよかったと後悔するばかりです。

    そして気になるのは、Chromeのコンソールで見ると、以下のWordpressのREST APIのURLにアクセスしているようですが、

    https://www.5cho-me.com/wp-json/wp/v2/blocks?per_page=100&context=edit&_locale=user

    結果が、次のようなエラーになっていることでしょうか。

    {
      code: "rest_forbidden_context",
      message: "この投稿タイプの投稿を編集する権限がありません。",
      data: {
        status: 401
      }
    }

    権限と言われても、再利用ブロックの一覧表示以外は正常に動いていますので、何だかわかりません。Wordpressをやめて他のCMSに移行することも考えましたが、何せ数千の記事を作ってしまいましたので、ちょっとやそっとではWordpressから離れられません。

    今のところ、Gutenbergから再利用ブロックを選択して挿入できないので、

    <!-- wp:block {"ref":xxxxx} -->

    という再利用ブロックのHTMLコード(xxxxはブロックのID)を貼り付ける方法くらいしか思い付きません。でも、この方法はちょっと面倒です。Gutenbergが正常に対応してくれること望みます。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2021年2月6日)

    Gutenbergが昨日9.9.0に更新されたせいかはわかりませんが、たまに再利用ブロックの一覧を表示できるようになりました。たまに表示できるくらいですので、今も半分くらいは表示ができません。もし再利用ブロックの一覧が表示できない場合は、ブラウザの更新を実行すると表示してくれることがあります。それと

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    もたまに出ます。

    相変わらず、よくわかりません。

    続きはこちらから

    今回の不具合が一挙に解決した話しはこちらから。

  • さくらインターネットのレンタルサーバーでInternal Server Errorが出る件は、All in One SEO Packを削除したら直ったかも、でもまだ直っていないかも、どちらなの、という話し

    ずっと本ブログサイトで出ていたInternal Server Errorが出る件は、ようやく落ち着いてきました。原因は、All in One SEO Packプラグインのようでした。

    “ようでした”というのは、All in One SEO Packを削除してから、Internal Server Errorが出なくなくなったというだけで、本当にAll in One SEO Packが原因がどうかはわかりません。単純にInternal Server Errorが出るからって、All in One SEO Packを削除すればいいとは限りません。

    どうしてAll in One SEO Packを何でインストールしたかというと、Bing Webmaster Toolsでたくさん

    説明がページのヘッド セクションにありません。

    と怒られたせいで、それで<meta name=’description’ を付けようということになって、面倒なのでAll in One SEO Packプラグインでやってしまえ、ということでインストールしました。後は、キレイにTwitterに投稿した記事を共有できるということです。

    All in One SEO Packプラグインを削除することにすると、<meta name=’description’ を違う方法で付けてあげなければいけません。Twitterの共有については、共有できていればいいだけですので放っておきます。descriptionのほうは、以下のサイトを参考に、Wordpressのfunction.phpでプログラムで生成してあげるようにします。

    そのまま利用するのではなく、適当に本ブログで必要なcontent=””を生成しています。

    しかしながら、All in One SEO Packは重いプラグインと言いながら、これでInternal Server Errorを出すようなさくらインターネットのレンタルサーバーはいかがながものでしょうか?

    さくらインターネットのレンタルサーバは、WordpressのAll in One SEO PackプラグインでSEOをバリバリやるのであれば、使わないほうがいいような気がします。自分のような、適当なブログサイトなら問題ないかもしれません。

    でも、そんなことを言うのなら、もっと金を払ってスペックの高いサーバーを契約しろ、というところでしょうか。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2020年12月22日)

    相変わらず、まだInternal Server Errorはたまに出ています。All in One SEO Packプラグインが原因ではないのかな? たまにエラーが出るくらいなので、サイトの運用には問題ないレベルだから、放っておいてもいいレベルなのかな?

    その他、WordpressのテーマをTwentyTwenty-oneにしたりキャッシュのプラグインを見直したりで、アクセスがだいぶ速くなったし、よくわからない。さくらインターネットのレンタルサーバーで共有している他のユーザーのサイトに、アクセスが集中しているのだったらしょうがないな。

    昔のことを思い出したけど、Wordpressはさくらインターネットのレンタルサーバーの機能を使ってインストールした覚えがある。これでWordpressのインストールや設定がしくじっているとかだと辛いかもな。

    さくらインターネットから別のレンタルサーバーに移行するのも面倒だし、どうしてものやら・・・。

    続きはこちらから

  • 【解決】WordPressのBackWPupプラグインでまたエラーが出る話し

    WordPressのBackWPupプラグインでまたエラーが出る件、解決した。

    バックアップ先をDropboxにしていたけど、認証を削除して再度認証したら正常にバックアップできるようになった。

    以上、解決。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記

    Dropboxにバックアップができないと思っていたら、バックアップ先のフォルダがBackWPupでなくInpsydeBackWPupというフォルダに変わっていた。

  • WordPressの不要なプラグインは無効ではなくて削除するのです、という話し

    借りているサーバーに負荷が高かったの原因を調べてみたら、postfixのバウンズメールが原因だった。ほとんど使っていないドメインからのアドレスから送信していた。しかも、メールアドレスも知らないアドレスだった。スパムメールの踏み台にされていた。

    postfixを停止させても、メッセージキューにどんどん溜まっていく。postfixは送信専用にしているから受信はしていない。リレーされている訳ではないようだ。何かやられて不正なプログラムを起動しているかと思っても、cronの設定も変なところがない。

    送信しているアドレスのドメインが設定されているApacheのログを見てみると、外部からプラグインの下にあるプログラムを実行しようとアクセスしていた。IPアドレスを調べると中南米からだった。

    実行されているプラグインは、WordPress Automatic Upgradeという今はメンテナンスもしていないプラグインの中からだった。こちらは無効にしてただけど仕込まれたプログラムが実行されていた。

    WordPress Automatic Upgradeプラグインを削除しておく。すると今度はメッセージキューが溜まらなくなった。念のため、そのWordPressのサイトはメンテナンスにしてmod_writeでエラーページを出すようにしておく。Apacheのアクセスログを見ていると、いまだにしつこくアクセスをしている。今度はTinyMCSのプラグインを不正にアクセスしている。

    今回は更新もしていない、ほぼ休止中のWordPressのサイトだったけど、WordPress本体とプラグインは定期的にはアップデートをかけていた。しかし、WordPressのプラグインは、必要なくなったら無効にではなくて削除すること。インストールするプラグインも何かあったらアップデートしてくれるような新鮮なプラグインで、必要最低限をインストールしないと危ない。ただでさえもWordPressのサイトは狙われやすいですから。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。